 |
|
 |
 |
|
|
 
Jonathan Simon's BlogJava VM Management, a modest proposal...Posted by jonathansimon on July 17, 2003 at 08:05 AM | Comments (4)The Java VM installation and application launching has some serious problems. Its too hard to launch Java applications and make it seem as seamless as a native application (unless your on OSX). Sun is clearly trying to fix it with the creation of JavaWebStart and the new Java auto-update functionality. But Sun is really just putting band-aids on the problem. This really struck me as I watched a JavaOne presentation on the new Auto-Update architecture for Windows amidst all the hype about "Java on the desktop". I want to rant a little but about the problems and then Ill get to an idea. Sorry up front for the long rant, but there are a lot of ideas here that have been bubbling in me for a while. Launching a specific VM: All of the enterprise clients I have built require a specific VM version. This is caused by a wide variety of reasons including limited testing time (cant test application with all versions) as well as the state of bugs and subtle differences between versions -- even minor versions. So its not enough to say "I need a 1.2 compliant VM" I have to say "This application can only run with 1.3.1_02." On windows, where I do most of my deployment, the only way to figure out whether the VM is installed is to check the registry, determine the location of the installed VM of choice, and refer to that VM directory in the launch script. (And don't even get me started about suing launch scripts instead of .exe wrappers!) Installing new VMs breaks current applications: Just like my application needs a particular VM, so do other applications. Now I cant control how the rest of the company does deployment, I can only work with my piece. And the VM makes system changes when installed. For example, A colleage of mine wanted to use the auto-installation feature in JavaWebStart. Everything seemed fine, until tech support got calls that a number of mission critical applet deployed applications were broken. Turns out that the auto-installed JRE replaced the Browser plugin automatically. The VM is too big: Seriously, the VM installation is huge! In many cases the size is prohibitive. I have talked with several potential clients who decided against Java simply because of the size of the VM. And most of the built in packages are never used. For example, there is a logging API that no one uses... Auto-updating?: When I first saw the auto-updating piece, I thought it was generally an ok idea that probably wouldn't end up using for some of the reasons mentioned above. Then I got to thinking its a really bad idea. I look at it like this, as soon as mu users know that I wrote my application using Java, I have already failed. Thats my sort of deployment mantra. That means batch files, Java Look and Feel, and similar give aways are out. I mean, do you know that Word is written in C++ vs C or SmallTalk or Object Oriented Scheme? Ok. Now on to the constructive criticism. All of these problems (and a bunch I am not even thinking of now) could be solved with the addition of something Ill call a Java container. A Java Container as I am thinking of it is a small application that manages Java installations. You can see quickly how the first problem (specifying a version) would be solved. You would basically invoke the Java Container application saying "launch this application with this VM" The VM container would check to see if the requested version is installed. If it is it is run, the VM can be donwloaded. Thats already a huge improvement. Point 2. Installing new VMs breaks old ones. Well, when you install your new application, you could define to the Java Container what you want to install. Rather than running the installation, the application being installed can drop the new VM into the Container with information saying not to mess with the default VM and not to set the new plugin as the default. This could be really cool because the license could be popped up by the Java Container getting rid of the need for any real installation information. Point 3. The VM is too big. Ok, dont freak out, but the VM could be modularized. The VM could be separated out into core and external (like Javax was supposed to be) and only the core is installed by default. Then the application (at either installation time or runtime) could say, "I need such and such package" The Java Container could download it or it could be put in the Java Container. You get the idea. There is a lot to this, but you should get the basic idea. Essentially, an application to manage all VM installations on a machine from a central location. Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
CommentsComments are listed in date ascending order (oldest first) | Post Comment
| |
 java.net RSS Feeds
|
