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.
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…
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!
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.
[quote]I think we would need some sort of mechanism that allow programatically or by configuration the request of certain Java modules
[/quote]
IMHO, coding around potential problems introduced by a JRE feature is a workaround, not a solution.
One key point about having a strictly maintained java standard is that we can be sure that a java installation is compatible. Something like this could break that, or at least add more assumptions (“it is only java compliant as long as you and Sun’s servers are always online”).
If you are after the best compression ratio possible, you might be interested in trying Kzip.
In the field of j2me games, it reliably obtains roughly 1% better compression than 7zip.
This is ofcourse assuming you are using the conventional zip format, not the 7zip proprietary format; which I assume is the case, if you are distributing via webstart.
Incidentally, is there a technical reason you are not taking advantage of pack200? (for clients that support it)
Uhm… with 7zip he means lzma (NSIS) and no webstart or whatsoever. The webstart links are tagged as “linux” but they are infact xplatform.
He could use p200 for the installer, too. But then it would go from gray to completely black.
Using it for webstart would be certainly a possibility, but I think he was too lazy for setting it up. ROI wise there isnt much to get anyways (if there are already win and mac builds).
I don’t use Pack200 because I use a 1.4 VM (it’s smaller). Also targeting Macs for which the 1.4 VM is still prevalent. I use LZMA as oNyx says because it’s built in to the NSIS installer. Good stuff. Those guys deserve a medal.
Lil off topic… is 1.4 really prevelant on Macs? Apple updates the JRE as part of system updates. I’d think Mac users would be the ones who are most likely to have the latest and greatest Java.