I am seeing quite a few comments re the J2RE being too big - I agree - anyone know who to contact in Sun re this? I am looking for a cut down version - we do not need the 2 optional parts fro a start ...
The ideal solution is shipping Java Webstart with an absolutely minimum JVM required to run JWS (must be under 2MB!). Then it would download JVM packages on-demand.
I would consider this a major feature if Sun commited this to Mustang. Is anyone from Sun reading this? Some of your feedback would be much appreciated!
Users: make this happen today! Vote here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4267080
This subject came up when we were finalizing the list of stuff to include in Mustang (I'm on JSR 270). I cannot really speak for Sun or the future of the platform, but I CAN say that the Java Module System (JSR 277) was discussed as part of the long-term solution for this. It is possible that a future version of Java will be 'modularized' so that people can choose which components they want installed (I mean, who REALLY needs all the midi playing stuff, for instance?)
The jre core is down to ~7MB in Tiger (5.0). This is for the Windows Online jre installer only. This is quite an improvement over previous jre releases, despite all of the features that were added to the Tiger release.
Sun is always looking into new ways to reduce the jre download size, and will consider these suggestions for future releases.
Please see http://forums.java.net/jive/thread.jspa?threadID=90&tstart=0
The key, in my view, is to target dial-up users. I for one have always downloaded the offline installer because the with flaky connections (dial-up is definately flaky sometimes) you want to be able to resume a download and if some installation is expensive (again, this applies for dial-up connections) you want to download it once, store it somewhere for future installations. I would (personally) almost never use an online installer.
The download-on-the-fly JRE is another story. If we inform users that the difference in download size is 13MB for an offline installer and <2MB for the download-on-the-fly installer they will more likely choose the latter (especially since it'll resume any broken downloads). With 7MB and no ability to resume downloads, I would bite the bullet as a dial-up user and download the offline package instead (for the reasons I mentioned above).
Not only is the JRE rather large to expect our customers to download but the install (which normally seems trivially easy) has frustrated and thwarted [b]many[/b] of my customers.
I'm so frustrated with trying to help people get Java running correctly (with the correct version) that I'm ready to give up on Java completely (but I haven't been able to find an alternative language that is well documented).
What would really solve a ton of problems would be to just release native compilers so that our apps could be distributed without the Java install and configure and version nightmare.
I am a shareware developer. I am planning on releasing a new version this year and am bundling it with JRE 1.4.2 instead of 1.3.1. 1.3 just does not cut it anymore (no network browsing in JChooser etc...)
With jre 1.4, my installer size on windows has gone up from 10MB to 24 MB!! This is going to kill my business. I have already bought VS2005 and started translating my java programs to C#. Ofcourse, now I have to worry about the size of .NET runtime..
just noticed the pack200 utility in java 1.5. Supposedly packs the JRE 1.4.x down from 20 MB to ~5MB. Anyone has any experience with it?
I've used Pack200 - it really is great at shrinking JAR sizes - perfect for Rich Internet Apps.
I think a module system is *definitely* needed for Java. They could make it really funky with a dependency system to allow you to pick up all modules you need in one hit. Ruby has a module system that is like this and is really cool.
it would be nice to hear someone from Sun say exactly how much emphasis goes on getting the JRE size down.
there is an awful lot of shite in there at the moment :o) - eg MIDI support, audio support etc..
i don't think this is being too me-centric by calling audio support shite (the age of the applet for rich media content is surely over), and the question of how libraries outside the JRE are managed is only going to become more important
i think what is needed is
* a small core
* a well-thought out method of maintaining a library repository eg maven does a good job for build time dependencies but a controlled, designed, online way of doing this is needed (or is this happening already?)
a java community form thread on this exact subject
Just to be playing the devils advocate here.
A cut down version will probably never be a goal of SUN. Since they want to have java installed on every desktop. For programmers it is no fun to find out which library (or part of the jre) is on the users system to use and which library he should download.
Download on demand may be a more reasonable way to cut down the size of j2re.
It would be nice if distribution software (like webstart) would do this automatically for external libraries, so that sun does not need to embed every project out there that seems nice..
I really hope sun will pay attention to this issue since users do not want to download 25MB+ (linux) for a simple program of a few kb.....
I am also facing the same problem. Stripping down the JRE1.4 version. Really it is huge?
Do we have any solution?
The NSIS native Windows installer is small and
can compress the runtime environment quite well.
My 750 kB JAR comes as 9,6 MB exe bundled with
an international version of Sun's J2SE 1.4.2_03.
The last installer I tried on windows was not very big indeed, however during install the installer starts to download additional files from the sun website. I could not choose which parts of the jre should be installed to make it smaller.
But for people using modems 9MB is still a lot. Especially since a lot of "embedded libraries like the xmlparser, logger, etc" are not required by most applications.
If SUN is planning to embed every decent library out there in the standard JRE, they should:
1. Make sure they keep the library decent and not ruin it (like they did with log4j)
2. Make sure it can be installed "on demand". Either via webstart or other installation software. This way bugfixes can be released more often and in smaller packages.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.