http://weblogs.java.net/blog/enicholas/archive/2006/09/java_browser_ed.html
Very interresting.
that is very cool, had the same idea about downloading parts of the jre when needed, if this is implemented it would be pretty cool.
Interessting indeed but I’m wondering how far he can succeed having a swing JRE significantly small? I think that is the real challenge. Nevertheless he succeeded with awt. And ho!, having a game running with LWJGL would be really really interessting since no swing or awt is necessary therefore for a gaming solution it can be very promising.
yeh bundling the jre with a game would be much nicer too since 3mb is pretty good for jre size, especially if small bindings like lwjgl do the rest 
but how about JOGL? I know JOGL works with awt/swing but is it a required dependency?
It’s an interesting idea. I wonder how many problems it will solve and how many new problems it would create. It’s not like your typical Java user is downloading a new JRE everyday. If this is targeted at getting people new to Java to download their first JRE, then doing it piecemeal versus doing it all at once, does it really make a difference?
For game demo download it could make a huge difference. Online casual gamers that still have a dial-up connection can be easily affraid by the size of the download and choose not to try it.
I agree with some of the comments about startup time being much more of an issue.
Does it mention anywhere that distributing the new 3mb JRE would break the current license agreement? If not, then great! Hasn’t Cas been doing this for years?
Last time I check the stripped VM that will run LWJGL programs comes out at about 4meg. Anyone started on the automated tool to do this work?
Kev
i don’t think start up time will really be affect there would only be a slight delay if a required component is missing while it is downloaded.
In ideal conditions. If the user is on dial up, is experiencing poor internet access at the moment, Sun’s server is down, whatever, then getting that missing component could be a hassle. It would suck to download a game from server A, but not be able to play it because some minor system class is missing and server B which houses it is down.
well they could just have the small jre for ppl with fast net connections and have the normal full offline jre for 56k users and ones without net.
My JRE is about 2.5mb, 7zipped. That’s why my games are so small.
Cas
Cas always has been the trend setter
Eventually standard Java catches up though…
Maybe first look at what parts does the JRE have, and which part depends on which other.
Something like in the JDK doc: Image of JRE parts
Then determine for every part, how many % of the real world applications/applets need it.
I made a few desktop apps (and we are talking about desktop apps right?), and I needed one or another part of JRE somewhere. Most notably swing. And swing is big (it depends on awt, java2d, and other who knows…). Java desktop app without swing? It is either SWT or an opengl game. (headless apps are not used by avarage users, and developers can wait a little, they know what they are doing)
So I do not know about you, but if the user has to download 3-4MB JRE, and then the application, then Java says that “Sorry I need to download even some more things”, well…
So maybe it is good for opengl java games, but not for a lot of java apps, me thinks.
P.S.: I was not talkinkg about private JRE-s, they are a different story
For pure lwjgl ogl games there is no swing/awt need, but as it comes with GUI Tools it is needed. How much does awt/swing takes into JRE’s download size?
Anyway, having the opportunity to strip the JRE legally would be great
Thats not strictly true, IIRC, lwjgl uses AWT for some window creation stuff in linux/mac. Im sure elias will correct me on what platforms use AWT, but it is being used…
DP
It’s an interesting effort, but to be honest I’m not feeling too confident that it will work. As tortoise suggested, there’s so many things that can screw things up and it will have to make so many assumption for it to work.
For example see how ‘well’ Java Web Start handles versioning (how many times did you have to clear your cache?), do we want those kind of extra potential problems in something so critical like the JRE?
Say you download a game and you’re going to play it offline (while travelling or something), and in the end of level 1 it encounters some new functionality which requires a new java update…
Will our code have to change to handle such situations?
For me it doesn’t look like the question will be ‘Will something break?’, but rather ‘How broken will it be?’.
Sorry to sound so negative, but I think this will not solve our problems but I fear it will introduce new ones instead.
Let’s just continue pushing java to be preinstalled on new PC’s, fix java’s current auto-update function, fix JWS, pre-load the JRE in the browser, make a license change to allow distributing a stripped private JRE.
On Mac, the JRE is built-in to the OS in a particularly genius technical decision so no need to worry about JREs at all. On Linux we figured it’s so hit-and-miss whether anything works anyway who cares about an AWT dependency or download size, it’s a tiny tiny tiny niche market. The big win is AWT-less Windows deployment.
Look at Kev Glass’ Tiltiation as well. Doesn’t even embed a VM - it’s compiled using GCC!
Cas
Eric, concerning your offline issue I think we would need some sort of mechanism that allow programatically or by configuration the request of certain Java modules (not classes). This way when the player download and install the game, the game would force the download and install of the required modules if not already installed. The “by class” solution is too fine grained in my opinion and therefore too dynamic for offline situations and execution pauses.