The immensity of the JRE
Is there anything in the world Sun does not consider a "core" API? Just like everyone else in this Brave New World of broadband Internet and gigabyte hard drives, they figure nobody will mind downloading 14 Meg. Of course, they seem to be doing a fantastic job of compressing the JRE compared to the SDK as a whole (the whole 1.4.2 SDK is 44 MB, but expands to just a little over twice the size of the extracted JRE by itself). And the API's are certainly useful. Jonathan Simon addresses the issue of JRE deployment in this blog. I concur, and would like to take it a bit further.
Sun has gone as far as introducing a versioning API to check versions of other APIs installed in the
lib/ext directory. I am also reminded of the Mac API for checking for the existence and version of extensions. Back in my applet days, where an applet could be running under any number of versions of the JRE, including M*Soft's, one often had to use Class.forName() or runtime exception catching to determine if a specific class or method even existed. Applets seem to have fallen out of favor, so I will address only the issue of non-Web Start applications.
The reality is that one still often has to deploy a JRE with one's Java application. One reason is that the JRE installers all try to make the JRE they are installing the default. Besides possibly messing with already-installed applications, clients may be wary of having system-wide installs done by an application installer. However, their fears are not unreasonable. Whereas we like to think the JREs are all entirely backward-compatible, I am not sure if this has been proven 100%. There is, for example, the possibility than one has written a hacked workaround to, oh, I don't know, maybe a memory leak in Swing, by extending an internal but public class or method. In the next version of Swing, perhaps the method signature changes or the class changes, and the code is broken. It might be possible to activate this hack only for a specific version of the JRE, but who knows if the next version of Swing might introduce a new bug. (Impossible!)
So, we are left with the fact that an app wants to run only under one specific version of the JRE. And not all apps can (or want to) run under Web Start. So given that there is no other (free) version of VM management for the OS as a whole, at least on Windows and, I think, Mac (UNIX has the advantage of being able to install the jre in an arbitrary location, or at least soft-link to it), an app will often have to be installed with its own JRE. Problem is, the app might only be using a subset of all the APIs in the JRE. Why must the app developer be forced to install it all? True, there are package interdependencies which require that many APIs must be core even though it does not appear at first as if they have to. But do I really need to install, say, CORBA, rmi, or any cryptography if I am not using it? (I know, some of the crypto stuff is in separate jars.)
Even for applets, why can't the Java Plugin download rarely-used APIs as needed? This is similar to how QuickTime (and many other apps) allow you to initially install only a set of core components, and get new ones when required by running content that needs it. Not to mention browser plugins themselves. Sun would perhaps be a lot more successful getting people to install the plugin on Windows if the initial download were very small. Hey, people out there are still dialing up, many at well below 56K.
So I guess I am proposing a transparent download-on-demand system for applets (to allow full backward-compatibility), plus use of API versioning, and changing many of the core packages into extension packages. Remember the days when Swing was separate from the core JAR file, and even when it was a separate download? If you are not using Swing for any reason (how about those headless apps the core code seems to be supporting?), that's a lot of baggage to be taking along with you. I have never worked with J2EE: does that come with Swing? If so, that would seem useless to many people. if not, what about the needs of the guy who implemented server-side graphics by using Swing to draw into an image and downloading it? (That's a THIN clinet.)
Anyway, as you can perhaps tell, I haven't figured out the complete solution to all of this, but I sense it can be done, either by splitting up the core APIs or at least finding a better multiple-JRE-management solution. Again, read Jonathan's blog for a good description of the issues.