At a post-JavaOne dinner with some very bright people, a rumor about update 2 of the Java 6 JRE was mentioned. The rumor is that update 2 will indeed be a slimmed-down version of the JRE - stripped down to around 2-4 megabytes. Details were fleeting, but if it's true, this might be the kick that Java in the browser has needed for a long time. We'll try to chase this down at JavaOne on Friday, but Fridays tend to be a bit spare... and it may be that people from Sun aren't talking much about it. The rumor said that it was an update "floating around inside Sun" so it may be unofficial - and it may not work at all. This is still a great idea, if true - and might go a long way toward dispelling some of the doubtful opinions about JavaFX. Addendum: a TSS reader pointed out this interview with Bob Brewin that effectively confirms the rumor, although specifics aren't given.

They must be removing the CORBA packages

If it is really going to be divided, the question is how modular is it going to be? The core + the rest is not good enough. But, if we will have something more granular like core + awt + swing + net + rmi + sql + logging + corba + ..., that would be something. The important thing there would be how independent those parts can be, and versioning. Or, would it be possible to use core-6u2 + swing-6u3 + loggind-7u1?

If it is really going to be divided, the question is how modular is it going to be?

The core + the rest is not good enough. But, if we will have something more granular like core + awt + swing + net + rmi + sql + logging + corba + ..., that would be something.

They can make it as modular as the runtime's internal dependencies allow. For example, it's useless splitting the logging API into a separate download, if several other APIs invoke it, so as soon as an application tries to load a class from SWT, CORBA or whatever, the classloader will hit a reference to some logging class and trigger the downloading of that package. This would botch the whole modularized JRE idea - some app developer carefully writes a JAWS program that depends only on core+AWT+Java2D, excepting a maximum JRE download of (say) 2.3Mb, promises that to its clients, and when clients who don't have the JRE try the app, it loads 5Mb of JRE due to internal dependencies.

See for example IBM JDK, it's already modularized in a way, its jre/lib directory splits the core into no less than 21 jar files (v5.0). For example, there's a xml.jar (6Mb), a graphics.jar (6.4Mb - with AWT, 2D, Swing, ImageIO, Sound etc), and a ton of ibm*.jar with CORBA and security APIs. But the way they broke it seems tuned mostly toward WAS and also to separate Sun's code from IBM's code, e.g. the CORBA and security stuff is all cleanroom-made by IBM and there's even a BD.jar of 40Kb just for BigDecimal, which implementation was made by IBM (but adopted by Sun years ago).

Having said that, proper modularization tuned for downloading shouldn't be that hard, at least for coarse-grained pieces like Swing. Sun hackers should be all busy now, running JDepend on their code and refactoring bogus dependencies. ;-) And it's not only the rt.jar, the JRE contains a good chunk of native code: for 6.0u1/Win32, 54 DLLs with 6,6Mb + HotSpot Client's 2,2Mb in a single DLL. Most native code appears to be already very well modularized (unless internal dependencies cause most DLLs to be loaded all the time). But HotSpot isn't, and it's pretty honking big, even for the Client VM. It compresses down to 765Kb, still a huge part of a goal of 2Mb for the full JRE. But I bet the VM can be broken down into some additional pieces. For example, HotSpot offers several options of Garbage Collectors, but most client-side don't use fancy GC tuning anyway so all code supporting this, and any other non-default stuff of significant size, could be moved to a separate DLL(s) that's downloaded on demand.

There are also resources of significant size, like TTF fonts, i18n data (charsets, timezones etc), CMM and audio soundbank. I hope the new runtime can split these bits too. Many apps never use these things, for example who needs Java's fonts when the first rule of decent native LAF is using the "system" fonts bundled with each OS? Apps tuned for fast downloading in the componentized VM could also take care to not depend on such resources.

And I had a beer with some very bright people and they confirmed that Schwartz has six fingers on his left foot. More shocking news from JavaOne on the way... Stay tuned...

For being at JavaOne you guys seem to have quite carefully missed all of these details considering I saw them in presentations multiple times throughout the week. The JRE will be modularized to given something like a 2MB hello world distribution, a 4MB distribution for limewire, etc -- with lazy loading grabbing additional things in chunks as needed. While pieces (e.g. the more usable installer GUI) will start showing up in Update 2, I never heard anyone promis the kernel installer feature for Update 2.

The JRE will be modularized to given something like a 2MB hello world distribution, a 4MB distribution for limewire, etc -- with lazy loading grabbing additional things in chunks as needed.

Note this was 2 and 4MB of JRE distribution -- not application code.

i dont think JRE size or CORBA packages is the problem today. Today most people has a broadband connection. 10Megs JRE takes 3 minutes to download. And updates are not so frequent, so it is not a big problem for dial up users either. Problem is the incremental updates and managing the different versions. download should be automatic and done with a single click. for linux it is difficult because all has a different central package management how will this Java kernel fit there?

The size reduction will solve just part of the problem, because start up time will continue to be too long, as I've read somewhere. Both problems (plus the update issues) need to be solved for users to finally have a really good desktop java app impression.

The size reduction will solve just part of the problem, because start up time will continue to be too long, as I've read somewhere. Both problems (plus the update issues) need to be solved for users to finally have a really good desktop java app impression.

I thought this was to solve the "java don't act like flash on startup for things that you might use flash for" issue. For desktop apps, which Flash is [currently] not for, Java 1.6 is pretty good.

The size reduction will solve just part of the problem, because start up time will continue to be too long, as I've read somewhere. Both problems (plus the update issues) need to be solved for users to finally have a really good desktop java app impression.

Startup time is being addressed by pre-populating the disk cache in the background.

I've asked this before, and maybe I am dead wrong, but can't we have all of the runtime files for say Windows distributed in the form of an OCX or dll? I'm sure that if the Flash VM had a big chunk of its core runtime in the form of a jar, with or without disk caching, startup problems would be similar to what we have now. Can't we just load and pin?

in the states, europe and asia you have lots and lots of cheap broadband... i'm in south africa - and we pay for broadband! there was a piece in a local paper saying it would be cheaper to fly to hong kong and download from there that to sign up for broadband here.

i dont think JRE size or CORBA packages is the problem today. Today most people has a broadband connection.

While that might be true, it's not true enough. You can't afford to make almost half (or even a third) of your potential customers wait half an hour to access your site.

10Megs JRE takes 3 minutes to download.

Vs. how many seconds for a flash plugin? The total of all of my Firefox plugins is a third of that 10megs.

Who cares any more?

Who cares any more?

Obviously a lot of people.

Sun is always building hopes just to crush them with long awaiting. Sun has either lack of vision, ability to execute or not enough resources. If you don't want to feel like a jilted lover, just stay away - don't put your hopes in Sun fulfilling stated or inferred promisses. A slick IDE for JavaFX? It will be late and shortcoming. Look for Eclipse or IDEA plugins. Expect handcode in either. Small JRE? Maybe. Flawless updates? No way. They will cave in to interests API. There's not way Sun will be the true provider for enthusiastic coders. They don't believe in you.

They don't believe in you.

Talk for yourself.

Sun is always building hopes just to crush them with long awaiting. Sun has either lack of vision, ability to execute or not enough resources. If you don't want to feel like a jilted lover, just stay away - don't put your hopes in Sun fulfilling stated or inferred promisses.

A slick IDE for JavaFX? It will be late and shortcoming. Look for Eclipse or IDEA plugins. Expect handcode in either. Small JRE? Maybe. Flawless updates? No way. They will cave in to interests API. There's not way Sun will be the true provider for enthusiastic coders.

They don't believe in you.

How often do things in the software world make a comeback? Rarely. Does Sun have a tendency to be reactionary instead of proactive? Yes. Think of Sun's attitude towards alternative languages on the JVM until now. Think of Sun's attitude towards Linux until not too long ago. What is the average view of applets? Not good. To be fair to Sun, they don't have the nearly infinite resources that a company like Microsoft has, so Sun chased the serverside for a long time, which is understandable. But that doesn't really change perceptions. Java is open source now. For those that do care, it's time for them to take control into their own hands.

Sun is always building hopes just to crush them with long awaiting. Sun has either lack of vision, ability to execute or not enough resources. If you don't want to feel like a jilted lover, just stay away - don't put your hopes in Sun fulfilling stated or inferred promisses.

A slick IDE for JavaFX? It will be late and shortcoming. Look for Eclipse or IDEA plugins. Expect handcode in either. Small JRE? Maybe. Flawless updates? No way. They will cave in to interests API. There's not way Sun will be the true provider for enthusiastic coders.

They don't believe in you.

I don't think it is healthy to be this emotionally attached to technology issues. Paging Dr. Phil...

What's 2 to 4 MBs between JDK's? It's already very large and it'll only get bigger. They need to find a way to trim the fat honestly. Why is it so huge anyhow? Best Regards, Richard L. Burton III

good question. delete rt.jar and you can't run anything. Even with the shared archive, I think we've taken things to the extreme to silly. If I download the JRE onto my system, I know its Window's based, which version of Windows it is (or the installer knows) and then everything can be installed as a couple of exe's and a bunch of dll's that get mapped as soon as I load them. What the target system is, that information is already available. Make it cross platform at the bytecode level for user code, but make the targeted runtimes as lean and mean as possible.

What's 2 to 4 MBs between JDK's? It's already very large and it'll only get bigger. They need to find a way to trim the fat honestly.

Why is it so huge anyhow?

Best Regards,
Richard L. Burton III

Maybe I'm missing something. I thought the point was that the JRE would be 2-4 MB total. I'm I wrong?

In my view, this is a huge step in the right direction. It doesn't solve all problems for Desktop Java but it certainly tackles the biggest one: deployment issues.

There was also a deployment BOF I think (I missed it), plus this "Consumer JRE" was mentioned at the keynote. Joseph you need to pay more attention next time! :-) Here are my notes for the "Easy deployment is finally here" talk; http://sellmic.com/blog/2007/05/16/easy-deployment-is-finally-here-session-my-notes/