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.