Ethan Nicholas's Blog

"Java Browser Edition": New name, first steps

"Java Browser Edition" History

Some time ago I proposed the idea of a Java Browser Edition. The basic idea was that the current Java Runtime Environment is simply too big, and most programs require only a small subset of the functionality. The "browser edition" that I suggested would enable you to install exactly the subset of Java that your particular program required, but would be able to download all of the other functionality on demand (and thus be fully compatible with J2SE). I wasn't quite prepared for the response that this entry generated. In addition to generating a lot of comments and further discussions, it ultimately played a role in my getting hired by the deployment team at Sun.

I was cautioned by several folks at Sun that the Browser Edition would simply never happen. It would never be approved as a feature in the first place, and even if it were approved, we would never be able to actually pull it off. I'm told that this basic idea has actually been attempted within Sun twice before, and in both cases the resulting size reduction wasn't enough to be worthwhile. The core VM, it seems, is simply too big, and trying to make it smaller is too hard. There has even been a detailed analysis of the idea which paints a rather bleak picture of the potential gains.

New Name: Java Kernel

The feature did in fact get submitted as a proposal for Java 7, under the name "Java Kernel" (the idea being that you download a small "kernel" of Java functionality, which is in turn capable of downloading the rest of it). And, amazingly enough, it was accepted. And, lucky me, I'm part of the team responsible for implementing it. After having been told that it's been tried a couple of times before and that it's basically impossible -- not a situation which inspires tremendous confidence.

Building a minimal JRE

The first thing I have to do is establish that this project is feasible. Remember that even though it has been approved, it could alway be un-approved (disapproved?) at any point in the future if things aren't looking good. So I figured I would start out by creating a simple, stripped-down JRE installer that contained only the functionality necessary to run System.out.println("Hello world!"), to get an estimate of the size reduction we could expect. Stripping out the unecessary classes is easy -- you just run Java with the -verbose option to get a list of all of the classes it loads while running the Hello World program. Those classes are all that we need to include in rt.jar.

The real problem is the rest of the functionality. My devel build of the Java 6 JRE contains 683 files totalling 119MB. Many of them are not necessary to run Hello World, but which ones? Determining which files were truly necessary and which weren't could be a tough job, so I made my computer determine it for me. I wrote a simple program which would iterate through all of the files in the JRE. It would remove a file and then attempt to run the Hello World program using this stripped-down JRE. If the test succeeded, the file was evidently unnecessary. If the test failed, the file was deemed necessary and restored.

After going through all of the files in this fashion, I was left with an extremely minimal JRE that could run Hello World and... well, that's about it. But it at least provided a starting point. Building a working installer from this JRE was itself a challenge, because several of the files that weren't necessary to run Hello World were still necessary to successful install the JRE, but I persevered and now have a fully functioning, minimal JRE.

Results

I built two JREs using this methodology: one with a program that prints "Hello World" to System.out, and one with a program that displays an empty java.awt.Frame. Here are the results:

Things to note

Before you get excited, remember that this is just an experiment and that the JREs I built aren't the least bit useful. They don't include the Java Plug-In, Web Start, or indeed much of anything, and any "real" program will need at least some of these components. These JREs also do not have the ability to download the missing components, and will simply fail if an attempt is made to access missing functionality. The installers we ultimately ship with Java 7 may well be bigger than this.

Next steps

Despite the cautions above, I find these results extremely exciting. Keep in mind that so far we haven't done anything the least bit sophisticated -- just omitted unnecessary files and classes -- and we've already gotten the JRE below 3MB for a non-visual program. Classes compress extremely well, so this installer would stay under 3MB mark even with a lot of additional classes included. And there are still a lot of things we can do to improve the size further, such as break up big DLLs to get better granularity.

It's hard to say how big the final Java 7 installers will end up being, but my personal goal is to make an installer that can handle basic Java applets in under 3MB. This is a difficult goal, and it may end up being too optimistic, but we're going to get as close as we can. So, what do you think? If the Java installer were 3MB instead of 15MB, would you find the idea of using Java applets (or Java Web Start programs) more appealing?

Comments

• That's great news Ethan! I hope you can achieve your goal and deliver us something for Java 7.

  Posted by: gfx on September 06, 2006 at 01:45 PM

• 3MB @_@ EXCITED. But i think 5MB(average size of a PDF) is also acceptable. Also, I do hope that this "kernal" supports Web Start !!!!! I use webstart much more offen than applet.

  Posted by: fcmmok on September 06, 2006 at 01:59 PM

• Are you going to do any measurements soon on something beyond "Hello Ethan" or the high utility Frame example? I don't know what, maybe a Frame with buttons in it. :)

  leouser

  Posted by: leouser on September 06, 2006 at 02:08 PM

• What about startup time? I know many people complain about the size of the JRE, but for me applet startup time is more important.

  Posted by: neilweber on September 06, 2006 at 02:16 PM

• fcmmok: It's still going to be J2SE and will still support everything that J2SE does, Java Web Start included. It just might have to download some additional components first. I'll be posting more details about that as soon as we have everything nailed down.
  leouser: My next test will be SwingSet.

  Posted by: enicholas on September 06, 2006 at 02:18 PM

• How fun ! Now what are the figures on the hot and cold startup times. Down to Flash-like levels ? :-)
  
  How many MBs for a JRE that runs 70% of today's deployed applets ?
  
  And for extra credit, a mechanism to install on demand all the things you had to leave out for applications needing other pieces ?
  
  - Danny
  

  Posted by: dannyc on September 06, 2006 at 03:56 PM

• hi there,
  
  congrats! on your persistence.
  
  Yes, if a 3 MB JRE on the browser will load 5 (almost) times as fast as a 15 MB JRE, then why not ?
  
  Flash and JAVA applets are painful because they take a hell lot more time to load than most people prefer to wait.
  
  Now, java applets can compete effectively with AJAX.
  
  Is this JRE only for the desktop browsers or will it make the MOBILE JRE(J2ME) versions better as well ?
  
  thank you,
  
  BR,
  ~A

  Posted by: anjanb2 on September 06, 2006 at 04:50 PM

• In reference to startup times, this change shouldn't have any effect. The exact same JRE pieces are being loaded as before -- the only difference is that the remaining, unused JRE pieces may not be present. That doesn't mean that we don't care about startup time or won't be working on it for Java 7, simply that this change isn't the mechanism by which it will be fixed.
  Danny: This change will be 100% compatible with existing JREs, which of course means that we will have install-on-demand mechanisms. The requirement to run 70% of today's applets isn't really relevant -- the JRE will get on your system because Applet X requested it, and it will come with exactly the components necessary to run Applet X. When your system is idle (or when it runs into a spot where it absolutely needs a particular component right now) it will continue to download additional functionality. So generally speaking, by the time you've moved on to running a different applet, the system will already have 100% of the JRE features, having seamlessly downloaded them in the background. At worst, it will have to display some sort of progress indicator and quickly download the necessary components.

  Posted by: enicholas on September 06, 2006 at 06:02 PM

• The 2.6MB version (AWT is totally unecessary for most uses) plus a DOM manipulation library would be enormously helpful to my AJAX work. I could dump JavaScript. The classes I write for the client side could be shared with any other Java application, and be 100% tested, profiled, debugged with existing Java tools. IMHO this is _really_ powerful.

  Plus, if you were to pack200 the 2.6MB xpi/exe/? you could wind up with something as small as 500KB. Add some management code to dynamically install extensions (plus the JVM/DLL/so?) and what are we looking at then?

  Seriously, leave applets, Swing, CORBA and all of the other complicated pieces for a 1.1+ version. I think getting something small out the door that serves the majority (not applets, not Swing, just AJAX web developers) would trim the task list and enable you to get something out sooner. The sooner folks start talking about it and playing with it and providing feedback the better.

  Cheers.

  Posted by: markswanson on September 06, 2006 at 06:42 PM

• There is one thing nobody has comented on yet: installation. The installation of such a beast should be like Flash. Period. If it is like installing java today, don't bother. For IE, use ActiveX (or whatever Flash does) and for FireFox use an xpi installer. For the rest, they download a .exe and doule click on it. When it done a little dialog say "Java is Installed" and that's it. The Flash installer doesn't even says that is has installed Flash correctly and is so fast that I executed it a coupe of times thinking that it was not wroking ! Ho, I almost forgot. For God sake, load the JVM when the browser start up! Don't wait for the first applet ! If you manage to do all that you could well relaunch the applet popularity. If a piece is missing, well, don't bother. PD: sorry for being harsh but that's how people will juge this.

  Posted by: imjames on September 06, 2006 at 11:34 PM

• hmm, interesting approach at least technical but in my humble opinion, the best approach will be to try to convince vendors to include the JRE environmnet in their OS. And when you are live inside the OS, you can have an update mechanism that will automatically try to download the newest or updated version of JRE (but only the changes and not the whole JRE) Regards, Christos

  Posted by: cvasilak on September 06, 2006 at 11:50 PM

• > the best approach will be to try to convince vendors to include the JRE environmnet in their OS. And when you are live inside the OS, you can have an update mechanism that will automatically try to download the newest or updated version of JRE (but only the changes and not the whole JRE)
  
  Well, that's exactly what we already do now (JRE is distributed with most OEMs), but it's not enough. Dmitri

  Posted by: trembovetski on September 06, 2006 at 11:56 PM

• I have just been writing a webstart application that can install its own newer JRE(not requireing windows admin rights). If I pack200 and lzma compress the JRE I get install download sizes of: 6.6Mb for 1.4, 8.3Mb for 1.5 and 9.8Mb for 1.6 Already smaller than the 15Mb installer? Posted by pottsj at September 7, 2006 03:00 AM

  Posted by: pottsj on September 07, 2006 at 03:00 AM

• Keep corporate users in mind
  
  Please keep corporate environments in mind as well. Today there are often policies in place that prevent users from downloading and installing software. It should still be possible to load the entire runtime as it is today so that it can be included in SMS inatllations and workstation images.
  
  The Java kernel sounds great for home users, but it may be less than ideal in a corporate setting.

  Posted by: rabbe on September 07, 2006 at 05:45 AM

• Hi Etan, The only "browser edition" for me of Java platform would be a Java VM that is able to start an applet as fast as Flash ! If this means bringing a striped down version of the VM dumping corba & all ... why not, but becarefull download size is the the #1 priority ! I mean, look at people downloading tons of mp3 and bigs word document all the time ... who cares about dowloading 10 or 20 MB nowadays ? Remeber that this download is only done once ! #1 priority now, is to get blazling fast startup time. This is what is realy killing Java momentum on the client side. So please Etan, if you realy want to improve Java overall perception amon the masses, simply focus on this priority and help the Java SE team to get to the graal ! We need fast startup that is all we need. (singing all together) ;-)

  Posted by: bjb on September 07, 2006 at 05:54 AM

• I see lots of add this packages, don't add that package... it seems a very simplistic approach to the problem, why don't you go for a different solution:
  
  Re-write the base classloader. Lets imagine that we have a smart class loader that when loading a specific class searches for it in the classpath environment (and this includes rt.jar), if not found then connect to a class repository and downloads the specific class and adds it to the local rt.jar.
  
  To optimize this, the class repository should have a database with versioning so upgrades could also be performed to the current rt.jar. To make things even more interesting, the repository would have a dependency net for each class so, all required classes for a given class would be downloaded in a single update, reducing the transactions with the repository.
  
  The final idea sounds good however it must have to be handled with care since all requests should notify which classes one has already on the local rt.jar so there wouldn't be a huge download and duplicates.
  
  - Paulo

  Posted by: pmlopes on September 07, 2006 at 06:00 AM

• Good idea, however there are more things to be considered for improvement and in need of fixing:

  • Don't change download URLs JREs because they are hard coded in
  • Get the version mechanism for required JRE version bug free
  • Fix the caching algorithm for jars and files loaded through the classpath. As of 1.4/1.5 it does not reliably replace jars in the cache which are newer on the server. It's a hit or miss.
  • The start-up time for applets does split in two parts. Loading the JRE the first time and reloading an applet takes too long. May be there could be a flag that says take and store/cache a memory image for reuse. This would be important in cases where the same applet is used on many pages or needs to react to a page reload. I could imagine this to be a flag in the tag, Taking a memory snap shot right after class loading, before entering the main().

  Posted by: kajkandler on September 07, 2006 at 07:09 AM

• P.S.: Can somebody fix the "Preview" function of this comment system? It deletes the original text from the form-field. This does neither allow to make changes to the text in the preview window, nor does it allow to post from the preview window.

  Posted by: kajkandler on September 07, 2006 at 07:10 AM

• And just lost my comment too...

  To repeat: add LZMA and/or BZIP2 to the JDK (under javax.*?). They are small and unencumbered and well tested, and if used in the right way (eg after PACK200 for the big JARs) will make a significant difference. AND you will be doing the world a favour by making high-quality implementations available to users (eg to compress data that an applet downloads).

  Rgds

  Damon

  Posted by: damonhd on September 07, 2006 at 07:17 AM

• Wow, this is an amazing step forward. Congratulations Ethan! You're going to be spearheading a project that will transform the web industry YET AGAIN!

  Posted by: ilazarte on September 07, 2006 at 07:18 AM

• Well, 3.5MB for an empty JFrame is not that far from my 6.5MB for Yahoo! SiteBuilder analysis, is it? ;-) In any case, this is an improvement over what we have today.

  Posted by: alexismp on September 07, 2006 at 08:05 AM

• The analysis you linked to is wrong.
  
  I know from personal experience (having done this myself) that the JRE can be stripped down to 3MB at least (and probably more if you try extra-hard) by using a tool such as Proguard to remove all unused classes/methods. I had a network-enabled Swing application running on top of a 3MB stripped-down JRE. So it *is* technically possible.
  
  If the JRE were to support load-on-demand I am confident you could quite easily bring it down to 1MB.
  
  The hardest part about stripping down the JRE is that the native code (peers) do not document their dependencies so you have to (through trial and error) discover what breaks when you remove Java-side methods. If you want more information on how I made this work feel free to email me. I still have a Proguard configuration file which worked for me.

  Posted by: cowwoc on September 07, 2006 at 08:32 AM

• Ethan,
  
  I tried emailing you at your yahoo address but the mail bounced (unknown user). I want to send you files which will help you with this effort. How do I get in touch with you?
  
  Thanks,
  Gili

  Posted by: cowwoc on September 07, 2006 at 08:51 AM

• My new address is ethan.nicholas@sun.com. Where is the Yahoo address still listed?

  Posted by: enicholas on September 07, 2006 at 09:21 AM

• W00T!!

  Posted by: prime21 on September 07, 2006 at 11:16 AM

• Ethan, Your old address is still listed here: http://today.java.net/pub/au/438

  Posted by: cowwoc on September 07, 2006 at 11:24 AM

• Well, why not integrate the netbeans plug-ins classloader into the JRE7. You need an xml parser (go for a push-parser, simple and fast) to: 1. read plug-ins meta-data 2. resolve the jars depencies between 3. get versionning/signature/api-spi separation support for all the JRE7 components. Using a very constraint automatic downloader for missing plug-ins using netbeans auto-update feature (again network classes and xml), you can then only dowload the plug-ins that are really used by other JRE7 applications components... You could make a JRE6 plugins that delare the depencies on all the jars released with that release (same for JRE5, JRE4, ...) thus enabling very flexible and semless upgrade-able JRE with extended backward compatibility...and a robust infrastructure for Java Desktop Application, Web-Start and Web-Services deployment!!!

  Posted by: ccuche on September 07, 2006 at 12:08 PM

• I have tears in my eyes :-) I have them for two reasons.

  1. It is hight time that the JRE size is tackled and below 8 MB would be a great outcome.
  2. On the other hand, I am an oldtimer. A good old FORTH VM (including what passes as a development environment in FORTH) is about 8 KB (yes, K as in kilo).

  So a 8 MB Java kernel would still be 1000x larger than ancient technologie. Why do I mention this? Because to point out that if you want to have a real breakthrough (several magnitudes) you need to change more than just not loading a few classes at startup. I am not saying that you should switch to FORTH technology, but I am saying if a Java kernel for a simple "hello world" is 1000x larger than with other technologies you have a severe architectural, and not just an organisational problem at hand.

  With just re-organizing class loading and probably throwing in yet another compression algorithm (after ZIP and pack2000) you will only come so fare. You will likely hit a wall still in the megabyte range. If you want to go below that, you will need another technology. A lightweight, no frills core VM to bootstrap the rest of the system on-demand.

  And this raises the big question: How low do you actually need to go? What is the requirement? Do you have a real goal, or are you toying around? Did you just get the "goal" of "do your very best", and are you just hoping for the best, or is there a real plan behind creating a Java kernel?

  Posted by: ewin on September 07, 2006 at 12:22 PM

• WOW - if only we could bring the idea of applets back! Not that they ever went anywhere but I'd LOVE to see them compete on equal footing w/ flash...given the capabilities of Java - it could easily bury Flash if applets could become lightweight enough.

  Posted by: zambizzi on September 07, 2006 at 12:56 PM

• This is really good news. Has there been any consideration to using one of the embedded VMs like those used in CDC or CLDC? Those are designed to be very small with very fast startup times. I know that a lot of things would not be possible, but it certainly would be very small and download times would be really short. For Applets that just paint on a Canvas (which is a lot of them), I think it would be sufficient.

  Posted by: sandtiger on September 07, 2006 at 01:01 PM

• ccuche: We'll probably be using the module system from JSR 277 -- it's the same basic idea.
  
  ewin: I actually grew up programming Forth, so I definitely hear you. However, I don't agree that the size of the VM represents a severe architectural problem. Even an extremely stripped-down Java VM is going to contain an optimizing compiler, a sophisticated generational garbage collector, a dataflow analyzer for verifying classes, cryptography functions for verifying signatures, and on and on.
  
  Yes, Forth got along without any of those features. Forth also doesn't allow you to download machine-independent code from an untrusted source and run it without fear of it destroying your computer, not to mention all of the other neat things Java can do. Even a minimal VM has amazing capabilities. Forth is a neat language, but it's a toy compared to any modern VM.
  
  As for "how low do we need to go", we're putting together the requirements now. These preliminary tests are merely investigation so that our requirements can be reasonable. I expect that our internal requirements documents will call for basic AWT functionality (i.e. what most applets use) in a package no bigger than 4MB. And, as I said, I hope we can actually deliver it in less than 3MB.

  Posted by: enicholas on September 07, 2006 at 02:09 PM

• GREAT initiative Ethan. I believe this is definately the way to go for the future of Java. If this gets extended to 3rd party APIs, it would simply do wonders for the jars missing on thousands of classpaths every day. Please ignore the naysayers, and know that the hope and good will of many java developers support you.

  Posted by: phlogistic on September 07, 2006 at 04:18 PM

• That GREAT!!!! This will benefit installer, server and other applications that does not require SWING and others! That GREAT!! I had been waiting this 100 years ago! imagine, used Java in Installer! ( I know alot out there but... I havent include my app it already much much more bigger than my app... )

  Posted by: ivano on September 07, 2006 at 06:33 PM

• I don't really think there is that much to be gained for most people by shrinking the JRE to a minimal set of classes. I am not saying it won't help some people but there are some far bigger issues with deployment. Java comes pre-installed on most computers, the main problem is when a new version of java is released the entire JRE has to be downloaded, not just the changes (which i assume are pretty small between dot releases). Another issue is that packages like Java3D, JAI, ImageIO, JavaMail etc should be able to be installed with the JRE. There is a lot of comparison with Flash but Flash doesn't install just a kernel and then download more later, that would in fact make it look slower. Why would you want to encourage people to install a version of java with only a minimal set of classes, then when they view an applet they have to wait longer while more JRE classes are downloaded, this sounds like a backwards step. I do however believe some parts of the JRE could be separated and installed on demand. These separated packages could sit beside Java3D, JAI, ImagIO as install on demand packages but a stripped down 'kernel' does not seem to really help anyone. I think people are confusing a stripped down version meaning it will load faster but that doesn't seem to be true. The user will also have to wait longer for the extra JRE classes to be downloaded. What is the gain? The only gain is for a user with no java installed and who is only going to view a very simplistic applet. I think even that user would be better off downloading the whole JRE at the start, then all applets would load a lot faster.

  Posted by: dutchiedave on September 07, 2006 at 08:27 PM

• GREAT! When can we download the alpha copy ? Thanks

  Posted by: ivano on September 07, 2006 at 08:37 PM

• Great if Sun will provide 2 type of JRE ( Something like what Eclipse did ) 1 - A cusomizable JRE. Choose what you want and download what you want. 2 - A full set of JRE which is 15MB.

  Posted by: ivano on September 07, 2006 at 08:40 PM

• This is really impressive and exciting, congratulations. Interestingly, your work may help with this problem: http://blogs.sun.com/mr/entry/removing_features. Unwanted stuff like MIDI could be removed in a future JRE without loss of backward compatibility since old java apps using MIDI would still work if they could download that component using your solution.

  Posted by: commanderkeith on September 08, 2006 at 02:21 AM

• Well, from Adobe's site i can see that Flash is 1.3MB (including everything). If you need Java to really be usable, well, you must provide a distribution that is around 1.3MB. I would argue for less, actually. See, lots of sites use Java for simple things, like bobbing text, simple buttons, pathetic menus, etc. And all of these look pathetic compared to Flash stuff. At the other hand, Flash has seen a big spread in Flash games, interactive ads, Flash-based forums, image galleries even whole media and video players. So here comes the question: you, as a user (forget your love for Java for a moment), would you download 1.3MB for experiencing all this Flash visual extravaganza, or the same (or more) for experiencing text, buttons and menus that look like they were designed and made by a 13-years old, colorblind coder? (note: from personal experience -and i surf the web since 1995- most Java applets i've seen look like that, with some few notable exceptions BUT these are exceptions!). Try to think as a 56k modem user. I know lots of such users. Your argument about the optimizing compiler, sophisticated garbage collector, etc that the standard VM has is good, but not enough. The "mini" or "browser" edition could have a very minimalistic VM. If the user wants anything faster (or if the applet has a special line in it's manifest saying "i need a FAST VM!"), he can always download a better VM, just like downloading more packages. Yes, it's hard and i'm not the one who will do it, but someone has to do something and bring Java to the browser.

  Posted by: badsector on September 08, 2006 at 05:20 AM

• Dear Ethan, Your efforts towards a lighter java are apreciated. However unless you (SUN) decide to strike into the heart of the problem, which is start-up time and memory consumption, I see litlte point in making the download bundle smaller. I agree with dutchiedave that such a java version could lead in worse perception from the common people about java's spped. Dimitris

  Posted by: mofo on September 08, 2006 at 05:36 AM

• Ethan, make sure you talk to the JME guys. They've been chasing this problem a long time and might have something to add.

  Posted by: dwalend on September 08, 2006 at 09:30 AM

• Just another thought I'd like to add:

  You will also have to fight on a second front: Your feature-crazy colleauges who e.g. added stuff like scripting, the Synth PLAF, Java IDL, the SmartCard API, Instrumantation, etc.

  I am not saying the mentioned stuff is totaly useless, but it doesn't belong into the platform core. So watch your back, because if you don't, you have no chance. Turn your back on them, and they will slip another MByte with a rarely needed feature into the platform core.

  Posted by: ewin on September 08, 2006 at 10:12 AM

• 1) I think you need to be under 1 megabyte to really hit. By 2MB you're already losing a critical chunk of your audience. By 3-4MB you're now in "failed plugin land" - there is a stack of the bones of 4MB plugins a mile high somewhere out in southern California. A barrier that high is just not a serious option for mainstream projects. Sorry. If Java can never be this small, then Java can never be a ubiquitous web client solution like Flash, or MS's new Avalon plugin (unless MS started preinstalling Java - hah). That's nothing against Java. Those are just the facts. 2) Let's be honest about what you're really doing here. A 3-4MB installer that immediately needs to turn around and download another 2-3-4-etc. MB just to do anything is not a 3-4MB install. Yes, that's the "worst case" first timer scenario. No, nobody cares about anything else.

  Posted by: obsidian01 on September 12, 2006 at 12:30 PM

• This is a great idea and I wish you luck. 3-4 meg VM would be a pretty amazing improvement, and unlike the previous poster, I think it's something people would use ... specially when it's pretty automatic and painless to install (like the Flash plugin).

  Posted by: augusto on September 12, 2006 at 09:03 PM

• May I suggest an algorithm like this: Pack each package in a separate archive (be it pack200). Lets call them "subpacks". We then would need three things:

  1. An application that records all the packages/subpacks that an application absolutly needs to start, store that in some metadata file
  2. A classloader that "caches" downloaded subpacks
  3. A classloader that upfront downloads all needed, not already cached subpacks before the application starts (the information is fetched from the meta data) and that dynamically downloads all subpackages that the application additionally needs while running.

  You would get an Eclipse-like startup process. Perhaps the JRE should be structured around OSGi as a bunch of plugins ;-) The point is to hide the "load time" from the user as much as possible. If the said application that records the minimum needed subpacks also records all possibly needed subpacks you could start the downloading of the "additional" subpacks in the background while the application is already starting.

  Posted by: gropi on September 13, 2006 at 05:49 AM

• Nice!

  But touches only one question: why not pre-compile the runtime-packages during installation? Optimization for the used machine should speed up the start time of a program.

  Same way could be used with custom packages - eg. dowloaded with Webstart or used by browser plugins!

  Posted by: fromwaldj on September 13, 2006 at 08:15 AM

• As a long-time Java developer for the desktop, I'm really happy to see this. I can't really provide any technical suggestions but I know for certain that this can play a big part in increasing Java adoption in the desktop area. Flash is good and does many things, but Java can do a great deal more and I see the relationship as complementary instead of competition.

  Posted by: rexguo on September 13, 2006 at 08:50 PM

• Hi Ethan, I thought you might be interested to hear from one of the people involved with one of the previous failed attempts at Sun. I left Sun about 5 years ago but have some rough notes - and possibly the old implementation somewhere. On the technical side we took very much the approach you have taken - using "java - verbose" to find the minimal rt.jar and then trial and error to find the minimal resource set. We (Lars) modified the VM to provide a hook when classes were absent and we used a (Java) network classloader to dynamically download the missing parts of the real rt.jar on as-needed basis. I havesome numbers (on the back of an envelope of course):

  • rt.min.jar 87K
  • jvm.dill 150K
  • awt.dill 350K

  Like you, we did three tests and the numbers I have for the overall download costs were:

  • Hello World 0.9M
  • Awt Test 1.4M
  • Swing test 1.8M

  If these numbers are like-for-like with yours it looks like things have got quite a bit bigger in the intervening years. :-(

  The 'project' was a skunkworks effort from myself and Lars from the VM team. Technically there wasn't really much to do - the "java -verbose" trick can be used on a program that downloads a missing class to reveal what is needed for a "streaming VM" - and we demo'd the modified VM running some real programs - I think we demonstrated swingset and a few other things. Technically there wasn't actually very much to do to get it all working.

  The problem for us was not on the technical side but in the fact that the effort was initiated at the same time as JWS. They were both percieved by upper management as alternative deployment strategies and, in the end, JWS was backed instead of the 'Streaming VM' as it was then called.

  Good luck with your efforts - its the right thing to do (and always was!) . If I can be of any help please feel free to get in touch with me at philippmilnenet.

  Philip

  Posted by: philipmilne on September 14, 2006 at 03:29 AM

• Sorry, my email obfuscation got eaten - I'm at philip_AT_pmilne_DOT_net

  Posted by: philipmilne on September 14, 2006 at 03:34 AM

• Great Idea, this is a good direction, I would like to help

  Posted by: jaquinte on September 14, 2006 at 11:54 PM

• The Flash player plugin is 1.3 MB. So >3.5 MB for a Swing enabled JRE looks a bit big if we try to compete with Flash.

  Posted by: jaquinte on September 15, 2006 at 01:45 AM

• Hi Philip, thanks for the history. And yes, things have gotten a lot bigger -- awt.dll, for example, is now 1.6MB. There's been similar swelling all across the board.

  Posted by: enicholas on September 15, 2006 at 12:17 PM

• Wanderfull work! What about Java Application, I hope to use minimal kenerl for java desktop applicaiton.

  Posted by: stoneganda on September 17, 2006 at 08:37 PM

• I think you are looking in the wrong direction. Nobody would want to call System.out.println("Hello, world!") in a browser. And the servlet thing has already been tried. But if I had access to the DOM and could make asynchronous web service calls, then I would have something! What would it take to replace the JavaScript in AJAX with real Java?

  Posted by: michaellperry on September 18, 2006 at 08:03 PM

• Sorry, replace "Servlet" with "Applet".

  Posted by: michaellperry on September 18, 2006 at 08:06 PM

• A smaller JVM is nice for my harddisk or for my memory chips. If you can make a smaller JVM also faster than it would be nice for me (the user).

  Posted by: vvaldo on September 19, 2006 at 06:14 AM

• Very interesting. See also JRE provisioning.

  Posted by: glyn on September 21, 2006 at 02:32 AM

• Hi Ethan, I remember reading your original post on this, great news that you've been given the task of tackling this issue. I agree with the posts above above particularly about starting the jvm on initialization to improve the applet initialization time and making the install process more transparent. But these should be the absolute minimum if Java is serious about competing with Flash and the forthcoming XAML/WPF/E. I'd like to add; Better cleaning of applets after leaving a page. Once a user leaves the page, the jvm should be completely cleaned of all resources created by that applet. I know there are many issues here that will make this complex and its probably not a priority but it should be tackled. It will minimise the problem of dodgy applets that fail to tidy up threads and force the user to restart the broswer, reducing the chance of that user using applets again in the future. Long term Java needs a Flash style vector graphics editor. A tool that can be used by designers without any Knowledge of the Java language and generate Flash style vector graphics, with the timeline, layers and other features that Flash has to make it as easy as possible for non-technical people to create simple animations. This would generate Java code + XML, that could be adjusted/linked with additional Java code when needed. The initial version of this tool could be fairly simple, 90% of Flash movies don't do anything very complicated and the non-cosmetic things would be added the traditional Java way - by coding it. It would take a very long time to win back this market from Flash on the desktop but in the mobile world, all is still to play for. There may be a small company or open source project out there doing something similar with Java and SVG. If so its should be helped along. Good luck :)

  Posted by: fatbatman on September 21, 2006 at 07:37 AM

• I personally beleive we are not in the direction of replacing or resisting flash plugin. As an enduser he just expects a few KB probably around 500KB fully functional of download to have a animation or a special content to get displayed. This MB of JRE is just a ME TOO solution like object orientation of PHP,PERL.....Pls do get to move towards a plugin that is java based which just replaces flash's dominanace .There wont be a compelling reason to go for a MB download of REnv only bcoz it is java. The project has to be MiniWebkernel,MiniKernel..notto be too generic and failing in all aspects...I beleive this is going to be like the clear cut simple easy to develop ASP.NET vs Complex multifaced gigantic webbased java solns available

  Posted by: gk_sezhian on September 26, 2006 at 02:04 AM

• I agree with gk_sezhian, no one is gonna leave Flash for Java just cause it's Java. Only when creating animation in Java will be as easy as in Flash AND the installer is about the same size AND some other important issues - only then Java has a real chance to successfully compete. To my mind it's high time to drop the Java 1.0 backwards compatibility and all the AWT unneeded components (ie awt.Button, instead we have a better one - swing.JButton). Prolly not you, but rather Sun MUST remove all these old components, it is a good idea to completely re-new the JRE every 5 years, ONLY this way we can avoid keeping old components, we can't bring Java back to the desktop with those old buttons and ugly styles (I can't believe that suporting 7-years old applets is that important - it's more important to bring Java back!), innovation and technology is the key for Java to succeed otherwise resistance is futile (sorry if a bit harsh, but we all see the consequences). Hm.. my comment is getting too large : )

  Posted by: xlinuks on January 11, 2007 at 02:21 PM

• We need it smaller! I know: Easy to say - hard to implement! But users and developers need this! And Java needs this, too!

  As a proven modem user I would NOT download a package, which is more then 2 MB! If I only need a little applet which depends on a new jre ...

  So reduce the size again, may be SUN develops a new compression algorithm for the jvm :-) as they have done with pack200 for .jar files. Or why not doing the following, which would be great for linux-modem-users:

  1. user gets the jvm source.

  2. user compiles them via gcc

  3. update the sources via svn or a simple diff file and compile again

  But it would be better to think about an OS independend mechanism (like apt-get, yast) to install and update java programs with the installed jre easily and which manages dependency resolution etc.

  I think that an os independend solution is very welcome! Although I googled and find some good but not 100% solutions.

  This management mechanism would reduce the overall downloading size,too (e.g. ant.jar is involved almost everwhere :-) The 'normal' java libraries could be splitted into java-util.jar, java-util-zip.jar etc.

  I think a programmer simply put a 'link' in his 'program-name-version.jnlp file' where to find an .xml file. And there the programmer should put

  1. the version of the current (older versions, too?) program or library.

  2. the dependencies (should be created from the jdk included 'java-version' program :-)

  Some additional requirements:

  1. double linked packages. Library x should know there 'users'. To know when we could remove it. And lib x should know, what it needs. To know what to download.

  2. handle non-root downloads: install the packages into /home/user/.java/jre-version?/ (Should SUN offer something like: update root packages from user repository?)

  3. handle different java versions of same jar: put them into special defined sub directories?

  4. keep in mind that if this os independend packaging is successful, people want to use it for their non-java programs.

  5. keep in mind that we could get security problems! See [1]

  After all SUN can say (User AND developer) download this here (smaller 2MB) And the rest would be done via the new, included and small SJPM (Swing JavaPackageManagement program :-)

  and if you want to update: simply hit the 'update' button :-)

  Any comments are welcome, Peter.

  [1] http://zero-install.sourceforge.net/security.html

  Posted by: peat_hal on February 23, 2007 at 03:23 PM

• Amazing! Only yestreday we were talking about J2WE i.e. Java 2 Web Edition along the lines of J2SE, J2EE, J2ME. This should have:
  java.lang*
  java.util.*
  java.net.*
  java.awt* + applet + dnd + datatransef + swing*
  Java 2d and optionally 3d
  java.security/crypto ?
  + the media stuff
  + RSS/ATOM support etc i.e. Web2.0 stuff
  

  Posted by: sandipchitale on March 01, 2007 at 06:12 PM

• Why not running a Java Browser Edition on top of the announced Firefox JavaScript VM as I wrote here ? This should lead to a faster Java startup, as this VM will be running as soon as Firefox is running too. It could be fun to do so for a whole class of Java applications on the client-side. Imagine nearly zero startup for (declared) small/medium applets ! This may lead to (re)vivify applet on the client-side.

  Posted by: dmdevito on March 20, 2007 at 08:19 AM

• Ethan your project is great! I'm very interested in this project, I'm anxiously looking for updated information about it. How is it going ? Can you give us some details about the actual work you are doing? removing modules from the VM, removing classes from the classpaht. Thank you very much. Hope to read something about it soon!

  Posted by: ojava on April 23, 2007 at 12:36 AM

• As a 'left field' thought... I wonder how this would compare to a native code approach (something like D Language with SWT for UI) in terms of size. I am thinking of someone downloading a RIA app (natively compiled to various platforms).

  I figure this really implies- drop the VM functionality for natively compiled code (that has automatic garbage collection).

  Is that too radical? I figure it depends on what features are in the VM that people think are required for RIA etc.

  Posted by: rbygrave on April 25, 2007 at 09:56 PM

• this is great news, whoever did this has my gratitude...thanks you made my work easier... i'm now working on somekind of search module for siemens mobile phones. anyone interested in that kind of projects can visit my blog and any question... See you soon, Boris Savic

  Posted by: borissavic on April 28, 2007 at 12:20 PM

• "The real problem is the rest of the functionality. My devel build of the Java 6 JRE contains 683 files totalling 119MB. Many of them are not necessary to run Hello World, but which ones? Determining which files were truly necessary and which weren't could be a tough job, so I made my computer determine it for me. I wrote a simple program which would iterate through all of the files in the JRE. It would remove a file and then attempt to run the Hello World program using this stripped-down JRE" You could have used a dependency program like JDepend instead of writing that iterarator program- but the problem is also the JVM native code - that needs to be stripped down of all the related dependencies as well (the native calls that aren't used) And you can also make it smaller by removing the hotspot features that don't apply to a browser edition. I hope the JVM experts can be of assistance here.

  Posted by: dljava on May 25, 2007 at 01:05 PM

• I thiought the real problem with java applet is it's loading time. To start the applet it need to load entire jar file. Instead we can have jar file format that is having the class files in the order of usage. i.e If there are 3 class files 1.class,2.class and 3.class and the start up class is 1.class then applet should render up after loading the 1.class itself and if 1.class need to call a method or information from 2.class then just show a loading screen on glass pane of appet top corner and temporarily stop rendering and restart rendering after 2.class is loaded. In this way user get good experience in using applet. This is same as thinkfree doing in rendering the documents. But the real issue faced by them is they also need to wait upto the whole jar file is loded into JVM. I am suuggesting a file format to be as below jab (Java Browser Archive) <FOLDER name="app"> <FILE name="1.class">Content of 1.class in zipped format to reduce the size</FILE> <FOLDER name="app2"> <FILE name="1.class">Content of 1.class in zipped format to reduce the size</FILE> <FILE name="1.class">Content of 1.class in zipped format to reduce the size</FILE> </FOLDER> </FOLDER> Herre 1.class(Main class) needs 2.class and 3.class in runtime only so we don't need to load those at first. We can do this in the running time of applet. According to my file format supposed above you can load the 1.class first because it encountered first in the unpacking the jab archive and start render it ... If I am not clear feel free to mail me iamdvr@yahoo.com

  Posted by: vr9_desu on July 11, 2007 at 01:49 AM

• The format of jab archive may be as below:: <FOLDER name="app"> <FILE name="1.class">Content of 1.class in zipped format to reduce the size</FILE> <FOLDER name="app2"> <FILE name="2.class">Content of 2.class in zipped format to reduce the size</FILE> <FILE name="3.class">Content of 3.class in zipped format to reduce the size</FILE> </FOLDER> </FOLDER>

  Posted by: vr9_desu on July 11, 2007 at 01:51 AM

• There are some interesting comments in this thread. The URLClassLoader, and variations on it have been used for ages to dynamically extends the contents of the JVM at run time. The Thread.setContextClassLoader() allows you to establish a class loader context for a thread to peer into for downloading things that aren't there yet. One problem is that the JVM doesn't integrate this functionality well with the AWT event thread. Inner, anonymous class construction (for listeners and other callbacks) should establish a classloading context equivalent to the time they were constructed, on method entry. I.e. we need to be able to stack another classloader into the mix. Ideally, we'd further refine the JNI mechanism to make it much more light weight and to expose the entire OS api set into Java so that there was only a couple of "dll" things in the entire JVM implementation and everything else was Java classes that could be loaded on demand and stripped if not needed. Dependencies could be accurately established etc. The Jini community has been using a "class dependency" tool set for ages which builds us minimal jars for downloading so that we can get exactly the minimal set of classes we need for our particular applications use of all the associated classes. With this technology, you just specify the top level class, and any classes which are loaded implicitly through Class.forName() etc, and presto, you get a compact and complete jar file.

  Posted by: greggwon on August 28, 2007 at 06:07 AM

• We need a new JNI implementation more than anything. We need something that provides a very powerful, yet lightweight access to the OS. Borrowing a work from .NET, "unsafe" could be a keyword, or annotation which results in JVM permissions being necessary to make use of any such code module. In this way, we could still have protection from downloaded code, while still having the power of easier access to native, OS code. In particular, this would allow a large number of things that are in 1000's of lines of native code to be moved back into 100% Java code. This would allow dependency analysis to be automated, so it could be a built in tool in the JDK, that would render a JAR file for you that was EVERYTHING you needed to run your program. There would of course be some type of annotation which says which version of a particular class is needed for which OS, if you had native access outside of the JVM code functionality.

  Posted by: greggwon on August 28, 2007 at 07:20 AM

• Would it also be possible to get the Java Kernel applets included inside PowerPoint, Acrobat Reader and Word, just like you can do with Flash?

  Posted by: hulagutten on August 31, 2007 at 05:29 AM

• Thanks for very interesting article. btw. I really enjoyed reading all of your posts. It’s interesting to read ideas, and observations from someone else’s point of view… makes you think more. So please keep up the great work. Greetings.

  Posted by: winrelocation on October 30, 2007 at 01:13 AM

• Hello, Ethan!

  I would like to know if the dependency component in Java Kernel will be open to 3rd parties. That is: can I make my own Java class repository, distribute only the core classes of my application and then have the Kernel download supplementary classes, if necessary?

  Of course this would generate a train load of problems, like what to to with duplicated classes in multiple repositories, but the lack of dependency management is, I belive, the most cited problem when talking about JVM.

  Thanks, Bogdan

  Posted by: b09d4n on December 17, 2007 at 01:40 AM

• Hi Ethan the "browser edition" will definitely help - so no JRE involved - it will be great.. even if a small subset of JRE's functionality is used as u were talking about - still it will be nice it will save installation time for first timers thanks for sharing this great info

  Posted by: miteshrami on December 21, 2007 at 03:07 AM

• Hi Ethan the "browser edition" will definitely help - so no JRE involved - it will be great.. even if a small subset of JRE's functionality is used as u were talking about - still it will be nice it will save installation time for first timers thanks for sharing this great info thanks mitesh rami http://mitesh.webng.com

  Posted by: miteshrami on December 21, 2007 at 03:09 AM

• 抓姦是否合法？徴信社抓姦又是否不觸犯法律呢？

  Posted by: stillstayhere on February 26, 2008 at 07:28 PM

• there is any update on this? Have them included the Java Plug-In, Web Start, or anything else? If these JREs have the ability to download the missing components? Digital Frame

  Posted by: kyes on May 15, 2008 at 08:39 PM

This work is licensed under a Creative Commons License.