Chet Haase's Blog

Consumer JRE: Leaner, Meaner Java

Coming soon to a Java SE 6 update release near you

Recently, Thorsten Laux and I gave a talk at JavaOne 2007 about where we are and where we're going in Desktop Java. We covered the download numbers (awesome!), statistics on how many PCs have Java installed (excellent!), and highlighted various desktop applications that use our Desktop Java technologies (fantastic!). We then quickly covered some of the larger features that were implemented in the recent Java SE 6 release (which I won't go into here; check out the various blogs and articles on the topic for more on those features). We concluded with the following technical diagram:

Clearly, the combination of growing ubiquity, power of the platform, and features in the latest release means that we are done, right?

Well, perhaps not. There are still some outstanding issues that need to be addressed, as we can see in the following diagram:

The reality is, we have several outstanding issues with Java as a consumer desktop platform, which need to be fixed soon in order to make us competitive now and in the future.

The good news is that we are, in fact, aware of these issues. The better news is that we're working on the problems. The best news is that we are close to solutions and intend to delilver them as an update to the SE 6 release, in a release that we call the Consumer JRE.

What's In It?

The Consumer JRE consists of several important pieces of functionality, some of which are depicted in detail in the above diagram. One of the keys to getting this release out quickly as an update to an existing release is to only make changes that do not affect API. So, for example, we can add functionality to make startup faster without affecting the APIs or functionality that an application is using. But we cannot add a new animation API in an update release. Fortunately, this constraint is not too cumbersome since the major problems we are trying to solve now are below the level of API changes, and are thus completely suitable for this release.

Here are the main items that we are shooting for in this release:

Quickstarter: Radically reduce the startup time for Java applications and applets.

Java Kernel: Reduce the time-to-install-and-launch when the user needs to install the JRE in order to run an application.

Deployment Toolkit: Enable easy detection and installation of the JRE.

Installer Improvements: Improve the user experience of installation.

Windows Graphics Performance: Enable default graphics acceleration for simple and advanced 2D rendering.

Nimbus Look & Feel : Release a new cross-platform look & feel based on Synth.

Quickstarter

This is probably going to be the most popular item in the mix, making the launch of any Java application or applet much faster. This is one of the most serious holdups to further applet development and deployment today, as the launch of the first applet in a browser can take several seconds. Quickstarter will cut down the launch time significantly, vastly improving the first-launch experience for consumer Java applications.

There are actually 2 issues with Java application startup: warm start and cold start. We define warm start as the time that it takes for a Java application to start when you have recently run Java recently on your system. Cold start, on the other hand, refers to the time that it takes to launch the first Java application after a fresh reboot.

Warm start times are reasonable these days, due to plenty of ongoing work on improving performance, in addition to machines simply getting faster over Java's lifetime. A simple application or applet will take 1-2 seconds to start up, which is in the same ballpark as standard web pages and within an acceptable range for the user.

Cold start, on the other hand, continues to take an unreasonably large amount of time. It is not unusual to see an applet take 5-10 seconds, or even longer, to start. While such a delay might be acceptable for a large desktop application, such as an IDE that's going to run all day after cranking it up in the morning, startup times like this for applets are unacceptable and limit applet viability for lightweight consumer content.

The problem turns out to be at the operating system (OS) level. Don't misunderstand me: I'm not saying, "It's not our fault!, " as tempting as that route always is for any hard problem. Instead, I'm saying that the Java platform is running into some basic physical constraints at the OS and hardware level that we must work within. In particular, the files that make up the complete Java platform are, well, large. For example, a recent version of Java SE 6 that I have sports an rt.jar file of over 40 MB alone. If you add in the various other jarfiles, native libraries, and resource files that get touched at startup, regardless of any application-specific code, that's a lot of data that has to be read in.

At the OS level, this means that all of these megabytes (or, rather, tens of megabytes) have to be read from disk, which is a very (to use a technical hardware term) slow operation. Actually, it's the seek time of the disk that's the killer; reading large files sequentially is relatively fast, but seeking the bits that we actually need is not.  So even though we only need a small fraction of the data in these large files for any particular application, the fact that we're seeking all over within the files means that there is plenty of disk activity. No wonder it takes so long for Java to start up, since we are dependent upon the speed of such an inherently slow operation to begin with.

The reason that warm start is so much faster is that once some data has been read off of disk, the OS places it in the disk cache. The next time that memory is needed, the OS can retrieve it from the disk cache, which is a significantly (again, a technical term here) faster operation.

The fix, then, is for us to take advantage of the disk cache to make sure that the memory pages on disk that we must read at startup have already been loaded before we need them. How do we do this? We cannot magically pre-load the pages just prioir to launching; unfortunately, the VM currently lacks the ability to see into the future to detect when the user will be launching Java (we would love to have this feature in the future, but it is not yet present). But we can pre-load at some earlier time, such as Windows boot or login time. And we can keep the pages warm in the disk cache as machine and memory conditions allow.

Note that this approach is not the same as running a full Java VM. That approach would solve some of the same problems, but in a less efficient manner, locking up the memory in a less OS-friendly way. Our approach will work just with the disk cache itself, allowing the operating system to use the system memory and disk cache as it sees fit.

Java Kernel

The Java Kernel project addresses the time-to-launch problem for users that do not have the proper JRE installed. For example, if your application requires the user to hava Java SE 6 and they do not currently have it, then you require that they install that full release prior to launching the application. Given the size of the JRE, and depending on the amount of bandwidth available to the user, the download and installation time can take anywhere from tens of seconds to tens of minutes. The Java Kernel project will cut this time down dramatically, allowing the application to install just what it needs to launch itself.

Just like QuickStarter, the main issue behind the time that download and installation takes is size: Java is large, even when zipped and Pack200 compressed, and there are physical realities to bandwidth and bit copying that we cannot overcome. Of course, one solution would be to simply shrink the platform, but in a world where Java is backward compatible and any Java application compiled to a particular release can expect to run on any release of that version or later, the idea of breaking up the Java runtime into subsets simply doesn't work.

The big idea behind Java Kernel is to take the sub-setting approach, breaking up the monolithic Java platform into discrete chunks of functionality that get downloaded and installed according to what any specific application needs, but to then stream down the rest of the platform in the background. Taking this approach ensures that an application that installs the Java Kernel will have the functionality that it needs with a much faster install and startup, but that any future application can still take advantage of the entire Java platform for that release, since the Java Kernel installation process will ensure that all of the proper bits get installed eventually.

The basic workings of Java Kernel are as follows:

• Download base functionality that every application needs (VM, garbage collector, security, classloader, and enough basic networking functionality to be able to download the rest of the bits)
• Download additional dependencies that this application specifies
• Download any "Class not found" exception culprits as needed
• Download the rest of the JRE in parallel until the entire release exists on the user's system

Work is still ongoing on Java Kernel (Ethan Nicholas is madly cranking away at it), but initial results show that it is possible to cut the download size by over 60% for mid-sized Swing applications. For example, here are [very] preliminary numbers for some sample applications to show how applications-specific bundle sizes compare with the complete size of the JRE:

Comparison of various Swing application download sizes with the full JRE

Deployment Toolkit

Wouldn't it be nice to be able to detect, from the browser, whether the user has Java installed, and what version they have? The Deployment Toolkit feature will make this process much easier, allowing detection of Java from either JavaScript or browser plugins.

To date, the main mechanism for automatic detection of Java on the user's system was the ActiveX control called Auto-Install that we released in J2SE 5.0. This mechanism was necessarily limited to Internet Explorer, and only if the user allowed that ActiveX control to run. Other than that, the process was quite manual and usually involved sending the user off to java.com to optionally install Java, from which adventure they might never return. For an example of how the current system works, check out the article Auto-Install: Easier Launching of Java Web Start Applications.

The Deployment Toolkit project is about enabling a much more powerful and ubiquitous system to run across multiple browsers and platforms, allowing developers to more automatically detect what the user has, what to do about it, and how to launch the application when Java is then installed.

There is still a browser plugin that provides a high level of detection, installation, and launching support, but now that plugin has been ported to also work in Firefox on Windows. But if the plugins can not be used, there is also a JavaScript solution, hosted primarly on Sun's site with a small piece of code that runs on the deployer's site, that can do far more than the current manual approach. The plugins can detect Java versions down to the update release, and can automatically trigger an installation of Java, launching the application when installation completes. The JavaScript solution is not as powerful, but still enables detecting Java versions down to the family level (i.e., J2SE 5.0, Java SE 6, etc.). The JavaScript version also cannot start the Java installer directly, but it can redirect the user to the appropriate download page and then poll in the background, waiting to return to the original page and launch the application when installation is complete.

Installer Improvements

The installation process for a new JRE should be simpler and more user-friendly. Besides the size+time issue that we plan to address with Java Kernel, there needs to be a better overall experience that users have during the installation process. Here are example before and after views of the first installation dialog:

Graphics Performance on Windows

We are re-writing the default graphics pipeline on Windows to take advantage of Direct3D for performing everything from simple rectangular fills and copies, which is what you get now by default, to translucency, gradients, arbitrary transformations, and other more advanced 2D operations. Swing applications simple and complex should benefit from much better runtime performance on Windows as a result.

Swing performs its rendering through Java 2D, and is therefore dependent upon the graphics rendering speed of Java 2D for fast Swing performance. In J2SE 1.4, we started accessing native hardware acceleration through DirectX on Windows, but only for the basic operations of filling and copying rectangular areas and horizontal and vertical lines. These simple primitives end up being quite important for Swing rendering, since much of the UI is comprised of these primitives, and the ability to cache the Swing back buffer as a VRAM image enables very fast double-buffering. But UIs are getting more complicated and the ability to accelerate more advanced operations, such as translucency, anti-aliased text, gradients, and scaling operations, is becoming increasingly important.

We have continued to work on the DirectX rendering pipeline in Java 2D, and have the ability to accelerate a wide variety of operations through the native Direct3D library on Windows. However, we have not been able to enable these performance improvements by default due to a combination of speed and robustness issues. Meanwhile, we have also implemented a parallel OpenGL rendering pipeline for Java 2D with even more advanced capabilities, but once again we cannot enable it due to robustness issues on various platforms.

Now we are finally rewriting the DirectX pipeline to mirror the capabilities that we have with our OpenGL pipeline, with fixes for robustness that make it a more viable default rendering pipeline. We should finally be able to enable this feature by default, exposing Swing to extremely fast hardware acceleration through the graphics processor. This should enable faster performance for current Swing applications, but will also enable much more powerful Swing applications to run fast as well, even those incorporating much richer and more dynamic, animated effects in their GUIs.

Nimbus Look & Feel

The Metal look & feel was good in its day. And Ocean was a decent theme for Metal, especially given the backward-compatible constraint of maintaining the metrics used by the UI components. But these cross-platform look & feels are, frankly, dated, and we need a more modern look for Swing applications. Of course there are other look & feels out there, some quite good, and we encourage developers to look to those products and projects as well for possible usage in their applications. But in the meantime, we also feel that we should provide a decent default for Swing developers in the core platform. Nimbus will be that new look & feel.

Here some samples of the the Nimbus look & feel so far:

Sample Nimbus components

SwingSet2, using the Nimbus look & feel

For more information on the Nimbus project, check out Jasper Pott's blog.

When Will It Ship?

As I mentioned earlier, the Consumer JRE will be an update for Java SE 6, which means that we will be able to deliver it much more quickly than we could if we waited for another major release like Java SE 7. But it's still a lot of work, and we're not done yet. Our best estimates now put the release date in early 2008, although we are trying to pull in the date if at all possible. Given the amount and type of changes in this release (especially Java Kernel), we need to send this release through extensive testing to make sure that it's as solid as you should expect it to be.

We will roll out some features as they are available, so that you don't have to wait for early 2008 to get everything here. For example, the improved installation experience should be out in update 2 of Java SE 6, which is currently set for late June.

The Fine Print

Most of these features are still very much in-development, and are thus apt to change scope or be removed from the release if our goals for them are not reachable. One of the main priorities for the release is getting it out to you as soon as we possibly can, with as much of these features as are doable in that timeframe. So if it looks like any particular feature would stall the release too long, we will have to weigh cutting or changing it in order to still keep our tight timeline. One of the things that is very clear to us is that the features we are providing are not things that would be nice to have in the future; they are necessary pieces of functionality that our developers and users want now. So we hope you'll agree that keeping strict control over the timeline is as important as the functionality of any particular feature we've discussed.

And who knows? Maybe we will also get the chance to add other cool and powerful features along the way, as long as they do not mess with our all-important timeline.

Stay Tuned

I will try to post updates to my blog as we know them, so stay tuned. And look forward, as I will, to a new era of consumer-enabled Desktop Java. In the meantime, check out the slides for the relevant talks at JavaOne when they become available. Some of these items were discussed at our Desktop Java overview, Danny Coward's Java SE: Present and Future, and Ethan's Easy Deployment sessions.

Comments

• Great! Good luck in the work. Let's finally make Java a fast platform for RIAs! What about multimedia support (video codecs + sound recording) is there anything being done?
  Carl Antaki

  Posted by: carcour on May 18, 2007 at 03:29 PM

• Oh no!! Not the dreaded media support question again.

  Posted by: mikeazzi on May 18, 2007 at 03:30 PM

• The media problem may be a really easy one to solve. There exists pure Java codecs for Ogg Vorbis and ogg Theora available under the GPL, this might be a great start .

  Theora and Ogg are great codecs that are patent and royalty free.

  http://www.flumotion.net/cortado/

  Posted by: kedaly on May 18, 2007 at 05:06 PM

• Please reconsider your Nimbus scrollbar. To me, it is confusing - it appears to be very much like a tab with its rounded corners top and bottom - and you click tabs, you don't drag them (typically). A normal scrollbar would visually convey "slidability" - which the Nimbus scrollbar doesn't at all.

  This is your chance to fix things so please hire a really great GUI person to help make this as good as it can possibly be. Please copy the Apple OS X GUI as much as is possible without infringing copyrights.
  

  Posted by: hutchike on May 18, 2007 at 11:34 PM

• 
  Wow, great stuff, Chet! As someone touting running Java DB in the browser and in Internet clients in general, this is great news.

  One more thing I'd like to add to your plate -- although I'm not sure it's possible without API changes. Like Flash, I'd like the ability to store a small amount of data in a specific directory on the local machine without having to sign my applet and where the user doesn't have a security screen flash in their face.

  I know JNLP provides a specialized persistence API, but that doesn't work with Java DB (although somebody's working on a storage engine that uses JNLP persistence). Is there a way to get this to work with standard Java IO?

  Barring that, we should at least make the security popup more friendly and less scary. One look at what we have today and grandma is going to say "no thank you" and that's the end of that.

  Posted by: davidvc on May 18, 2007 at 11:56 PM

• personally I live for the day when the new D3D pipleline is enabled by default....

  Posted by: benloud on May 19, 2007 at 01:27 AM

• If you do all that it will be a good START. I don't know if it will be enough. If all these little things finally add up they might create a great user experience. We'll see that when it is finished. And please remember that you are not trying to please me (a developer) but a much more exigent, non-technical public. These people don't care about the technology. They only care about the experience, the feeling. In that regard, they will benchmark the experience you will give them against their experience with Flash.
  

  Posted by: imjames on May 19, 2007 at 02:07 AM

• Yes, it should also be possible to use Java3D without having to get 'all-permissions' at the JNLP/JWS level. Please, away with these spurious annoying interruptions to the user, and have the run-time vet the calls for safety instead.

  Rgds

  Damon

  Posted by: damonhd on May 19, 2007 at 02:11 AM

• "So even though we only need a small fraction of the data in these large files for any particular application, the fact that we're seeking all over within the files means that there is plenty of disk activity."

  In the case of jar files like rt.jar, can't you just reorder them so that the stuff that is always loaded during startup is collected together at the beginning?

  Posted by: mthornton on May 19, 2007 at 03:40 AM

• I am definitely interested in helping improve the end user installation experience. My team over at Cool Album have managed to get some superb performance out of Java 6, but as the time for our initial 1.0 release comes closer and closer, I am starting to think about how in the world we are going to deploy this poor thing!

  We have a lean application, and so far we are not using anything that is explicitly from Java 6, as I want to maintain Java 5 backwards compatibility as well. The fact that even within my CS department, a fair number of machines are still running on Java 5 makes me hesitant to use anything from Java 6.

  But the end user install experience makes me kind of wonder... how am I going to make an easy to use cross platform install experience that doesn't just up and die if Java 5+ is not installed?

  It is nice to see that Sun is thinking about these same issues, and that work is being done towards resolving them! With the awesome medium-term improvements for Java 7, and the short team improvements for Java 6 that you have outlined, Java keeps looking better and better!

  Posted by: devlinbentley on May 19, 2007 at 05:57 PM

• In the case of jar files like rt.jar, can't you just reorder them so that the stuff that is always loaded during startup is collected together at the beginning?

  Yes, this is done already.

  Dmitri
  

  Posted by: trembovetski on May 19, 2007 at 10:14 PM

• This is great news. I love it! Especially love the new look & feel.

  Posted by: jattardi on May 19, 2007 at 11:34 PM

• Really great news. However I am wondering if these improvements will find their way into Apple's Java 6 VM... Hey we still run a preview version event though it seems to work quite well :(

  Posted by: jmborer on May 20, 2007 at 02:50 AM

• @devlinbentley I'd say, go with Java 6 and JWS, configuring it for explicitly requesting Java 6 and - as further sanity check - put a try / catch (Throwable) in your main, so you can get all the possible ClassNotFoundError etc... and at least give a warning to the user. We know that at the moment there are possibly troubles with the runtime installation of a new runtime, but it's the best we can do now in simply terms. Alternatively there's the IzPack, launch4j, jsmooth stuff...

  Posted by: fabriziogiudici on May 20, 2007 at 08:10 AM

• You forgot another important outstanding issue: memory consumption. Although it has improved it should be improved even further. Almost everyone I know complains about Java's ugly habit of hogging a lot of system memory. It is of particular importance for the Consumer JRE (not so much for the sever side java). People like to run a lot of different application at the same time, doing various tasks: video edditing, blogging, music players, video players, games.. etc. When they run a java app it pretty much hogs a lot of system memory and they are forced to run few of these other apps concurrently. Hence they stay away from Java programs. If this issue can be resolved. It would be perfect.

  Posted by: rizzix on May 20, 2007 at 11:20 AM

• Also note the time spent by antiviruses on some platforms. The jar files are scanned (sometimes more than once) which uses a lot of CPU power and also have a significant impact on the startup time.

  Posted by: tdeleeuw on May 20, 2007 at 06:31 PM

• Why dont you put the default look and feel to be the native L&F of the platform on which the app is running? That seems far more sensible than trying to come up with a gui that may seem foreign to users on a particular platform.

  Posted by: pdeva on May 20, 2007 at 09:21 PM

• I already hate the jusched.exe on my system, I dont need yet another java background job. Quickstart means, make the start quick, it does not mean make it start earlier.

  My notebook already takes too much disk seeks while it is booting, I dont need to page in another 10MB rt.jar files...

  Gee, when do ppl realize that Flash is the better applet...

  Greetings
  Bernd

  Posted by: ecki on May 20, 2007 at 11:11 PM

• tdeleeuw said: "The jar files are scanned (sometimes more than once) which uses a lot of CPU power and also have a significant impact on the startup time."

  I want to add that even if it seems that it is not Java's fault, it is not the user's fault either. The final conclusion for a non-technical person is that Java is slow. You can do something about it (implement something, talk to all antivirus companies in the world, etc...)

  Posted by: imjames on May 20, 2007 at 11:31 PM

• Chet first off I'm glad to see that all our whining and complaining have not gone unheard and sun employees can, at least you, have a humorous approach when talking about it. I am a little fuzzy about one thing, when talking about the JRE are you talking about the "rt.jar" or the complete "Java Platform" that is installed on users systems? If, talking about the "rt.jar" when approaching the user install experience fix, then will the rest of the binaries just get updated or are they just installed next to the current ones during updates the user may download or jusched.exe downloads? I, for one would like to see some sort of diff or patch applied to the native binaries so a user does not end up with 10 slightly different version of the same software clogging their system. This also renders some of the extensions that maybe installed unusable (Java 3D, JAI, add your favorite ext directory items here). So, what I am trying to ask is this problem being addressed and if I totally missed it in this post I apologize.

  Posted by: badapple on May 21, 2007 at 03:57 AM

• "Even better: you don't have to wait for the next major release of the JDK to get these features. "
  Most of our users are still on 1.3, they've been waiting for years to get permission from high up to introduce 1.4 into their environments. So they'll have a LONG time to wait for this :) :( Not that I know many people who use 1.6 at all, unless it came installed on their systems (and most of them upgraded from 1.6 to 1.4 or 1.5 because that's what customers use).

  Posted by: jwenting on May 21, 2007 at 06:40 AM

• "Also note the time spent by antiviruses on some platforms. The jar files are scanned (sometimes more than once) which uses a lot of CPU power and also have a significant impact on the startup time. " Nothing can be done about that. Most virus scanners now scan inside archives and packed executables by default (and rightly so, as many trojans and virusses come in such a form) and jars just happen to be archives.

  Posted by: jwenting on May 21, 2007 at 06:43 AM

• jwenting, If nothing can be done about virus scanners, then Flash wins.
  chet, Don't forget that any improvements to startup time, JNLP handling, and such like are needed on Mac as much as on Windows. Is Java just for Windows and Linux? It used to be just for Windows, but the new licensing might get it onto Linux now, too. Java is _starting_ to become cross-platform. It has some hurdles to jump yet. As for Consumer JRE, please keep this momentum strong inside of Sun. Thanks for the detailed report here.

  Posted by: tompalmer on May 21, 2007 at 08:39 AM

• That Nimbus scroll bar is hideous. The way most of it looks is just bad but, that is just plain ugly.

  Posted by: jmonroe on May 21, 2007 at 08:44 AM

• I agree with the dislike of the Nimbus scroll bar. Other than that, though, it looks good. Ship it.

  Maybe to help with rt.jar scanning and the virus software, rt.jar needs to be converted to a binary file and accessed like a database. Databases bumped into file system limitations a couple of decades ago and solved the problem.

  Your second picture needs a Mac OS X lightening bolt. Apple's poor Java support has certainly contributed to non-proliferation of client-side Java. My current thinking on client-side Java is, if Java is Windows only (which Java 6 pretty much is) and it doesn't provide much in the way of Windows integration, then why shouldn't I go with WPF?

  Posted by: neilweber on May 21, 2007 at 09:03 AM

• Oh, one other thing. Enhance the applet API! It has not changed since, what, 1997. Like with WebStart, it should be easy to store data across applet sessions.

  Posted by: neilweber on May 21, 2007 at 09:06 AM

• this is really amazing. i can't believe all this stuff is coming so soon! finally, a great reason to ditch developing on 1.5 only :)
  its not everyday a software company you work with gives you pretty much everything you want.

  Posted by: ilazarte on May 21, 2007 at 09:19 AM

• I'm not too excited about longer boot/login times with quick start. This will force a decision for many users about whether they want Java installed at all. At least now people can install it and pay the slow start penalty when they are going to use Java. If you compel people to pay that penalty regardless, many will jettison Java completely.
  

  Posted by: erickson on May 21, 2007 at 12:04 PM

• Requirements for Java to be viable as a desktop solution for developers to code on:
  1. A GUI toolkit that lets you embed heavyweight objects.
  2. Once you have #1, on Windows it needs to allow ActiveX embedding (although with #1 perhaps you can leave this critical functionality to third parties)
  3. A GUI toolkit with a frame that can render a modern web page.
  4. Media. JMF is really awful... it's very fragile and takes days to debug anything. Any hope of a successful desktop Java will require dusting off and integrating some form of cleaned up JMF.
  5. Fixing the major JVM-crashing, screen-munging, and memory leaking bugs in the AWT and Java2D that have been there for years. Java6 made some progress, but there's still a lot of random ductus rendering crashes.
  6. A RAD environment for GUIs.
  7. Replace JNI with something that appears to bind to native code more directly for integration with all the other desktop infrastructure out there.
  8. Integration of a real text editor widget that can represent styled text, receive pastes from Word, paste to Word, and some toolkit for saving this to some standard document format. JEditorPane doesn't cut it, since it dumps all formatting (tab, space, etc). The rest don't accept copy and paste. Everyone shouldn't have to roll their own.
  9. The end-user shouldn't know they're using Java.
  

  Posted by: samkass on May 21, 2007 at 02:39 PM

• ugh, sorry about the formatting...

  
  A GUI toolkit that lets you embed heavyweight objects.
  Once you have #1, on Windows it needs to allow ActiveX embedding (although with #1 perhaps you can leave this critical functionality to third parties)
  A GUI toolkit with a frame that can render a modern web page.
  Media. JMF is really awful... it's very fragile and takes days to debug anything. Any hope of a successful desktop Java will require dusting off and integrating some form of cleaned up JMF.
  Fixing the major JVM-crashing, screen-munging, and memory leaking bugs in the AWT and Java2D that have been there for years. Java6 made some progress, but there's still a lot of random ductus rendering crashes.
  A RAD environment for GUIs.
  Replace JNI with something that appears to bind to native code more directly for integration with all the other desktop infrastructure out there.
  Integration of a real text editor widget that can represent styled text, receive pastes from Word, paste to Word, and some toolkit for saving this to some standard document format. JEditorPane doesn't cut it, since it dumps all formatting (tab, space, etc). The rest don't accept copy and paste. Everyone shouldn't have to roll their own.
  The end-user shouldn't know they're using Java.

  
  (Once you do all this, I think you'll have caught up to where C# already is today...)
  

  Posted by: samkass on May 21, 2007 at 02:41 PM

• Concerning Nimbus, I don't mind the scrollbars. (Side comment: I think both native look-and-feel and CSS-like stylability are both more important than another hey-it-looks-cool. But Nimbus does look much better than Metal/Ocean.) It's the tabs that get to me. Why not make them as big and spread them out as much as possible? Wasting real estate and drawing attention to side details _is_ fun. Seriously now, I think Firefox 2.0 tabs in Windows look just great. Nimbus people might want to take a look at them.

  Posted by: tompalmer on May 21, 2007 at 03:54 PM

• I don't understand why Swing is getting a new look & feel. I thought Swing now uses the OS to render widgets etc...? From an earlier blog entry, here's a quote:

  "In Java SE 6, the Swing native look & feel for both Windows and GTK was re-written to use the native platform rendering engine to draw Swing widgets. Instead of our old approach of using the native resources and doing our own rendering, we actually call the native rendering system to draw the widgets for us (on Windows, this is done through the UXTheme API). This means that we are finally able to achieve true native fidelity for these components because, by definition, our components are drawn in the same way that the native components are."

  For your readers, an other useful quote from that blog entry is:

  "It is also worth mentioning that we are still aggressively pursuing OEM deals. We have distribution agreements with over 20 PC manufacturers, including all the top 10. They have all been helping us test Java SE 6 as they prepare their new lines of Vista-based systems for shipment, so that Java SE 6 will just be there on any of their new systems running Vista."

  That is EXCELLENT. My last question is about apple. I'm not a Mac user yet but have been considering it. I see that they maintain their own JVM and I've heard that it sucks. What sucks about it, and why doesn't Sun's JVM run on it? Sun's JVM runs on everything BUT Mac OSX? I would say it's more important to run on Mac than Linux when talking about desktop apps, though Linux is still very important. I doubt Apple has gone out of their way to improve their JVM like Sun has been doing.

  Posted by: rdelaplante on May 21, 2007 at 05:26 PM

• "jwenting, If nothing can be done about virus scanners, then Flash wins." The problem is people still believing that Java classfiles are prone to being virusses, so AV software considers them potential risks and scans all of them. There's no real technical reason for it (though I assume you could use an applet for a phishing scam). It's psychological, aftereffects of the security problems with JNI and some early VMs nearly a decade ago.
  " Java is _starting_ to become cross-platform" It always has been. The only thing holding back acceptance (NOT applicability) on Linux has been politics and overzealous license fanatics, not technology.
  "Like with WebStart, it should be easy to store data across applet sessions. " I kinda disagree, unless maybe for signed applets. The sandbox is there for a very good reason, security. By letting data leak between applets you give up a good deal of the things that make applets secure.
  "A RAD environment for GUIs. " There are quite a few of those already. Netbeans, JBuilder, IntelliJ, etc. etc.
  "Once you have #1, on Windows it needs to allow ActiveX embedding (although with #1 perhaps you can leave this critical functionality to third parties) " AFAIK third parties have already taken care of that years and years ago.
  "Replace JNI with something that appears to bind to native code more directly for integration with all the other desktop infrastructure out there. " Why the heck would you want that? With platform independence ever more important why are you advocating making it easier to code platform dependent code (which would only lead to more complaints that "Jav zux" and "Jav no is platform independent" by people who now only get stuck coding fixed Windows paths into their applications and wondering why they don't find the files on Linux...
  "The end-user shouldn't know they're using Java. " And quite often they don't, which makes them think there are no Java applications on the desktop... Flash is recognisable instantly, so people do realise they're using it and think Flash is far more important than anything else. Check out the forums, someone was asking what IntelliJ was written in a few days ago and wouldn't believe the answer that it's a Swing application. In his mind Java applications are always slow and ugly, a leftover from AWT that's very hard to get rid of.

  Posted by: jwenting on May 21, 2007 at 11:17 PM

• Nice post - looking forward to the Consumer JRE.

  Are there any plans to allow the replacement of the standard applet splash screen?

  In my opinion, a major contributor to perceived slow starting of an applet is the Java logo presented at load time. It just makes the whole initialisation process so obvious. If I can be a bit more creative in keeping my users informed of progress rather that having a big orange blob coercing them to visit all the fun things at java.com then I'll be very happy.

  Posted by: lowecg on May 22, 2007 at 03:46 AM

• Thank you for these good news.
  I have an other proposal : JDK could provide a tool that would build directly install files of a Java application for Windows, Linux and Mac OS X. These install files would contain the application files and a JRE for the target system (excepted for Mac OS X, where the JRE is always available).
  These files would be big on Windows and Linux, but most people won't care as fast Internet connections become more and more available. By the way, a lot of people are used to install an application thanks to an installer for their system, not by clicking on a JNLP link !

  For Windows, that tool could be based on Launch4j and Inno Setup.
  For Mac OS X, you just have to create an .app directory containing the required files for a Java application and then a .dmg file.
  For Linux, I let people propose a solution.

  Posted by: puybaret on May 22, 2007 at 04:16 AM

• "Warm start times are reasonable these days, due to plenty of ongoing work on improving performance, in addition to machines simply getting faster over Java's lifetime. A simple application or applet will take 1-2 seconds to start up, which is in the same ballpark as standard web pages and within an acceptable range for the user"

  
  Mmmm... except that people compare. (especially concurrent solutions).
  People compare F3/javaFX with Flash for instance: for the moment, 1-2 seconds of warm startup is very visible for the user.

  
  I pretty understand this is definitely another challenge starting code based on very generalist Java VM compared to a much simpler and specialized Flash VM. Perhaps we could say "simple apps" like interactive ads will stay in Flash for a long time, and place for JavaFX/F3 is for "non micro apps" which anyway take +3 seconds downloading, even before starting.

  Posted by: djocal on May 22, 2007 at 06:29 AM

• I have to disagree with your assessment of the startup time issue, Chet.

  "For example, a recent version of Java SE 6 that I have sports an rt.jar file of over 40 MB alone...At the OS level, this means that all of these megabytes (or, rather, tens of megabytes) have to be read from disk, which is a very (to use a technical hardware term) slow operation."

  It IS our problem: we have 40MB of bloat in rt.jar. Scripting engines, web servers, xml parsers, multimedia drivers, etc. If we could get back to rt.jar actually being the ESSENTIAL REQUIREMENTS, we might not have to load 40MB at startup!

  Posted by: cmreigrut on May 22, 2007 at 11:24 AM

• Great stuff!!!

  It is a great step in the right direction.

  But there is another big problem (that will get bigger if the Consumer JRE caches on) that I didn't hear anything about it for the last while. The one application - one VM approach, specially when the VM is so memory hungry

  Any news about the MVM (http://mvm.dev.java.net/) or a similar solution?
  Cheers
  JD

  Posted by: jdavi on May 22, 2007 at 05:59 PM

• Sorry if I say something awfully stupid, because I'm still a newbee but:

  Wouldn't it be possible to only pack those parts of java you need with an application so that you don't load all the unused stuff? This would certainly reduce those ugly loading times.

  For example something that would "configure" the jvm loading, like "ok, load only these parts because I don't care about the rest".

  About the idea of a background service to start java faster, no thanks, as mentionned previously, justched.exe is already too much :/

  And for Nimbus, I think it's really nice looking, glad it's available soon ;)

  Posted by: lechtitseb on May 23, 2007 at 03:01 AM

• jwenting: "Like with WebStart, it should be easy to store data across applet sessions. " I kinda disagree, unless maybe for signed applets. The sandbox is there for a very good reason, security. By letting data leak between applets you give up a good deal of the things that make applets secure.

  I didn't say across applets, I said across applet sessions. That is if my applet runs on your computer today, I should be able to save data that can be used when the same applet runs on your computer tomorrow.

  Posted by: neilweber on May 23, 2007 at 12:01 PM

• Problem: Our application is too slow starting up.

  Solution: Let's just have a service in the background continuously and repeatedly starting it up (or at least perform the most expensive part of the startup) AT ALL TIMES, whether it will ever be used or not.

  I generally have a high esteem for the Java Engineering team, but this Quickstarter has to be one of the dimmer ideas ever to see the light. It seems to assume that oh-so-important Java has some priviledged right to the disk cache and can therefore constantly throw out other programs' files from it and replace them with its own. It would do this even while those other programs are actually being used and Java is not. By acknowledging that the disk cache is an important factor for program performance, it accepts that the performance of all other programs will be significantly degraded by having Java installed.

  Instead of for just being slow, Java will be known for making the whole machine slow, as soon as it is installed. That problem is an order of magnitude bigger than just being slow and causing it is sure to get yourself banned by corporate IT teams and hated by consumers. The first order of business for any software wanting to add whizzbang features still needs to be: Do no harm to whatever was working fine before it came along.

  To have faster startups I don't think there is an alternative to try ever harder to make your software lean and only read the bytes from disk you're truly going to need. So I'm with cmreigrut on this: If you see a 40MB file being read from disk, don't just take this as a god-given fact and blame the OS for not doing it faster. Maybe you just need to analyze harder what the 40MB are being used for and what could possibly be spared.

  Quickstarter is a Non-starter in my book.

  Posted by: loeli on May 27, 2007 at 01:24 PM

• That will be a good start.
  - Webcams and microphones are now ubiquitous, I'd like to be able to use these within applets without the user having to manually install JMF, it should be downloaded as just another "module", Flash has had this for a while now.
  - Likewise for Java3D and other extensions to the core JRE.

  Posted by: fatbatman on May 29, 2007 at 12:24 PM

• 
  The improvements in the installer are certainly welcome and needed, but I don't think you've gone far enough.

  We want a web page containing applets or JNLPs to be as painless as possible to Java-less users. This means the installer must be incredibly minimal. No asking which directory should be used for installation; no asking which components to install. There must, in fact, be only one step to installation. Anymore than that, and users will feel like something is being "done" to their computer, and they won't feel comfortable proceeding with the installation steps. I'm not saying it's reasonable behavior; I'm just repeating my understanding of the mindset of non-technical users, as it's been repeatedly described to me.

  In the screenshot of the improved install dialog, the command buttons' texts are "Decline License" and "Accept License". They should be "Decline License" and "Install Now". Limit it to one step, or users will feel uncomfortable.

  Posted by: vgr on May 29, 2007 at 02:36 PM

• Agree with everything vgr said.

  Posted by: loeli on May 30, 2007 at 05:00 AM

• Agree also with vgr.
  Make it a nice modern picture plus a simple nice round button like "Go man !".
  If Sun people could be inspired by all the mashup web service they would benefit from it.
  why?
  Because all those "web services" have all in comun a few things:
  - They are incredibly "Nice looking",
  - They are very simple to use : reduce dramaticly the idiotic questions like "de you accept to do that ", if they fell 99% of people will click yes.
  no
  - The all ultra minimize the legal smalltalk that interst 0.0001 % of users
  
  Chet Haase : Go for it ! Make java jre a simple, neet and quick service

  It is the projest jabva plaform needs dramaticaly today.

  
  

  Posted by: tmilard on May 31, 2007 at 02:09 AM

• Awesome list Chet. Sure all we were waiting for those features to be available. I would suggest to include a request that has been going on for more than 2 years (I believe), that is to have the Java plugin for 64 bits platforms, this will be really useful for people like me that need to deploy java applications on 64bit clients.

  Posted by: mvillarroel on May 31, 2007 at 12:51 PM

• Did the Deployment Toolkit find it's way into Java 6 update 2? if so where is it, I couldn't find it or any documentation on it. I'm just trying to auto-install on Firefox...

  Posted by: fatbatman on July 12, 2007 at 08:29 AM

• I'm extremely happy that Sun is finally looking at the requirements of the desktop user.

  The only thing I'm really wondering is whether these improvements will be made available to all platforms that Sun's JRE supports (Solaris, Linux and Windows)? Right now the installer for non-RPM Linux is nothing more than a self-extracting archive. This doesn't even make the necessary links for using Java plug in in browsers by default. We are having to create the symbolic link manually.

  Generally Linux distributors do not always provide the latest JRE in their repositories. So the installer for Linux must be modified so that Linux users are not denied of these improvements. At least, quick starter and Java kernel facilities must be made available on Linux without any complex setup instructions which will scare new users (remember Linux is no more a OS meant only for the geeks).

  If not GPL of Java may not really help it to replace Flash on Linux. Flash has a really simple method to install and configure the Flash plugin for browsers on Linux.

  Posted by: chandru_in on September 21, 2007 at 02:57 AM

• Seems that it does't work fine on Windows Vista.By the way,the language of my system is Simplified Chinese.

  Posted by: shepherd108 on April 14, 2008 at 06:38 AM

• IMJames , A bolish statement if I do say so myself.

  Users also want to see the backend evolve as well , like any project they want options not limitations.

  If all you give to someone is eye candy , eventualy you will give them a tooth ache.

  
  Regards,
  XAVIER T P.

  Posted by: xaviertpnolan on May 15, 2008 at 04:47 PM

• Back to Home
  Welcome to tangjewelry.com Our tangjewelry.com is a Wholesale Jewelry website where
  
  you will find the highest quality Jewelry conveniently that with
  
  outstanding costume jewelry, designer jewelry and body jewelry.Otherwise,Yahoo! we have our special jewelry stores widespread distribute in china.Since2004,Yahoo! our original website aypearl.com has established long-term cooperation
  
  relationship with thousands of customers from dozens of countries. Fashion jewelry 99% of costumers expressed their satisfaction with our products and service.
  Now our fresh website tangjewelry.Google com also looks forward to your patronageGoogle Canada In this potential website, you will find Silver Jewelry,Beaded jewelry,Jewelry Boxes,Swarovski crystal jewelry,precious stone jewelry,Materials ofjewelry supplies,imitation jewelry supplies ,Glass jewelry ,Pearl jewelry,Turquoise Jewelry,Wire jewelry,handcrafted jewelry. Yale-Yale, bridal jewelry,discount jewelry,vintage jewelry,Jewelry scaleseasily. We may as far as possible meet your need. Good jewelry can give you good mood and also can improve temperament.烛光
  Our sincere desires will build an ordinary but not stodgy life for you.Google Canada Now, let us start a section of beautiful jewelry journey!Jewelry Wholesale.
  pasing OICQ:80810487 博客

  找人网
  网赚
  成人用品
  性保健品
  性用品
  基因检测
  签证信息
  烛光

  
  烛光

  饰品
  烛光
  小饰品
  饰品批发
  水晶
  饰品
  小饰品
  烛光
  饰品批发
  chinese
  Google UK
  Wholesale Jewelry
  pearl jewelry
  learn chinese
  Jewelry
  Academic exchanges
  烛光
  Medicine
  Jewelry Wholesale
  Wholesale Jewelry
  Jewelry Wholesale
  Yahoo!
  Pharmaceutical
  Jewelry Wholesale
  Wholesale Jewelry
  Jewelry Wholesale
  jewelry stores
  designer jewelry
  烛光
  Google
  body jewelry
  costume jewelry
  silver jewelry
  beaded jewelry
  jewelry boxes
  swarovski crystal jewelry
  Materials ofjewelry supplies烛光
  Google Canada
  precious stone jewelry
  imitation jewelry supplies
  glass jewelry
  
  turquoise jewelry烛光 wire jewelry fashion jewelry unique handcrafted jewelry Yale-Yale bridal jewelry discount jewelry vintage jewelry烛光 jewelry scales Biological Chemical Polytechnic Material Economy English Retrieval English directory Arts News Automobiles Fooddrink烛光 Business Legal Finance health Exercise Slimming help 烛光Plasticexperts Beauty guidance Health Alert Bulletin Parental guidance Mental health A healthy diet烛光 Google China。

  Posted by: tangjewelry24 on May 21, 2008 at 04:15 AM

• My web :http://www.yufuzi.com/

  Posted by: pasing on May 22, 2008 at 07:32 PM

• The fourth wow power leveling latest game in wow power leveling Warcraft series is ‘wow power leveling’. Also known as wow power leveling, it represents a wow power leveling multiplayer online wow power leveling game, the best of wow power leveling kind. Initially, it was wow gold it be released in 2001, but wow powerleveling was delayed wow powerleveling 2004, thus wow powerleveling the 10 years ofwow powerleveling franchise of thiswow gold series. The world of warcraft power leveling was not world of warcraft power levelingfulfilling, because wow power levelproblems with wow power level server’s stability power leveling wow performance occurred, but power leveling wow game still power leveling wow a financial success powerleveling wow the most powerleveling wow game of its kind. The number cheap wow power leveling users that play Maple Story mesos, exceeds 8.5 MapleStory mesos, worldwide.As a form ms mesos,recognition for mesos,outstanding popularity, the game SilkRoad Gold, received aSRO Gold, of awards. Now the question eq2 plat, why is eq2 gold, game eq2 Platinum, popular? For anyoneEverQuest 2 Platinum, played the previous EverQuest 2 gold, and EverQuest 2 plat, already initiated lotro gold, the mysterious world lotr gold, the breathtaking Lord of the Rings online Gold, this Rolex Replica nothing but an Replica Rolex adventure that continues the story of ‘Warcraft III: Frozen Throne’, four years after conclusion, in the world of Azeroth. The game is online role-playing, the previous versions being online and offline strategy games. The major thrills and unique features are present as in every Blizzard game.

  Posted by: liwan on May 27, 2008 at 02:37 AM

• dofus
  dofus kamas
  dofus kamas
  dofus
  lotro
  lotro gold
  buy lotro gold
  lotro
  lotro gold
  buy lotro gold
  guild wars
  guild wars gold
  buy guild wars gold
  guild wars
  guild wars gold
  buy guild wars gold
  guild wars
  guild wars gold
  buy guild wars gold
  maplestory mesos
  maple story mesos
  maple story
  maple story
  maple story mesos
  maplestory mesos
  maple story
  maple story mesos
  maplestory mesos
  runescape
  runescape money
  buy runescape money
  runescape
  runescape money
  buy runescape money
  runescape
  runescape money
  buy runescape money
  runescape
  runescape money
  buy runescape money
  buy runescape money
  runescape money
  runescape
  runescape
  runescape money
  buy runescape money
  runescape
  runescape money
  buy runescape money
  runescape
  runescape money
  buy runescape money

  Posted by: maplestory on June 01, 2008 at 02:32 AM

• Our web is Wholesale Jewelry|Jewelry Designer |
  precious stone jewelry|
  body jewelry|
  costume jewelry|
  silver jewelry|
  beaded jewelry|
  swarovski crystal jewelry|
  glass jewelry|
  pearl jewelry|
  turquoise jewelry|
  wire jewelry|
  fashion jewelry|
  unique handcrafted jewelry|
  bridal jewelry|
  tour jewelry|
  discount jewelry|
  vintage jewelry|
  jewelry scales|
  jewelry boxes|
  imitation jewelry supplies|
  Material ofjewelry supplies and etc. Our
  Jewelry|
  Wholesale Jewelry Blog
  Jewelry stores|
  Blog.To know more details about
  Jewelry Wholesale|, please enter our web:
  www.aypearl.com
  beads jewelry
  水晶|饰品批发
  pasing oicq:80810487
  Our Email: Tangjewelry_001#yahoo.com
  

  Posted by: pasing3 on June 19, 2008 at 03:09 AM

• phone sex
  phone sex
  phone sex
  phone sex
  phone sex
  phone sex
  phone sex
  phone sex
  phone sex
  phone sex
  phone sex
  phone sex
  mootzie

  Posted by: cgspender on June 19, 2008 at 05:07 AM

• _

  Posted by: cgspender on June 19, 2008 at 05:07 AM

• nice site
  phone sex
  phone sex
  phone sex
  phone sex
  phone sex
  phone sex
  phone sex
  phone sex
  phone sex
  phone sex
  phone sex
  phone sex
  mootzie

  Posted by: cgspender on June 19, 2008 at 05:08 AM

• I'm so grateful for all that you've done. Thanks again for that nice essay and I would be most grateful if you would send me the latter ones....

  
  mirc
  mırc
  mirç
  mırç
  mirc indir
  chat yap
  islami sohbet
  dini sohbet
  kelebek
  kelebek sohbet
  kelebek mirc
  kameralı mirc
  kameralı sohbet
  chat yap
  çet
  çet odaları
  sohbet kanalları
  sohbet odaları
  yarışma
  sevgili
  arkadaş
  arkadaş ara
  arkadaşlık

  Posted by: jklmno on June 19, 2008 at 09:23 AM

• Thanks so much for this! This is exactly what I was looking for.
  ///////////////////////////
  phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex mootzie
  and other video to SWF, FLV ecoded by Java.
  May it Gadgets helpful To your lifestyle... Enjoy！！

  Posted by: cgspender on June 19, 2008 at 10:05 PM

This work is licensed under a Creative Commons License.