Is there a wiki for wish list?
I would like to argue that it be nice to break up big rt.jar into smaler ones, so that each can move at a different speed.
Apparently, there are many feedbacks after my last response, so I will address some of the questions in one reply here instead of replying individually:
> I don't think you are considering the same types of applications that the rest of us are. I know that some people have already looked into this and rebuilt a stripped-down JRE to test the theory.
The type of application that we considered are typical rich client applications that use core/networking/io/awt/swing/security/xml. The case that you mentioned is actually a corner case that I don't think it applies to most applications out there.
> Do you have some measurements that you can share? Like logical partitioning and the sizes of each chunk?
Class partitioning is pretty complicated in the measurements because there are many inter-dependencies between various packages in the JRE. I don't think I can disclose the measurements here for various reasons. However, it is actually very misleading if you look at class partitioning simply at the package level, because many packages such as core/networking/io/security/xml cannot be separated cleanly from each other.
> I think the current JRE install already uses PACK200 compression for rt.jar. This is considerably better than plain zip. I don't know why rt.jar is installed (on disk) in uncompressed form, but Windows certainly does support memory mapping.
Yes, the JRE/JDK installer already uses Pack200 for rt.jar internally. The reason why rt.jar is installed in uncompressed form is to ensure the VM does not need to uncompress rt.jar at startup, thus making Java application startup faster. It is a tradeoff between disk space and VM startup time.
> Sun: How do I get an offline installer with 7MB (like your online installer?) Is the InstallShield configuration file that you use available to the public?
You should be able to get the necessary file from the J2SE 6.0 (Mustang) source bundle. However, be careful if you want to strip out any of the JRE file from your JRE installer because there are legal implications. You may want to check out the README file for more details:
Sorry to bring back an old thread, but I was googling and found this.
>The type of application that we considered are typical rich client applications that use core/networking/io/awt/swing/security/xml. The case that you mentioned is actually a corner case that I don't think it applies to most applications out there.
I think the desire to have modular installation for private JREs is higher than you think. On a project I was working on recently we wanted to distribute a private JRE across grid computing infrastructure. Due to internal policies and technical size constraints, installing a full version of the JRE was unacceptable. Aside from the licensing contraints from Sun.
This was before Sun's new licensing plans for internal and acedemic use of the JRE - I have yet to look into this but that may allow us to legally repackage the JRE for our own needs. Nevertheless, it still a lot of work to do for a reoccuring situation that developers are running into. I understand that Sun would rather not do that work either, but there seems to be demand for it.
Another point is that you should switch from InstallShield to the free Nullsoft Installer. Last time I checked, InstallShield has an overhead of 1MB and Nullsoft 38k.
Actually, we only use Installshield to build the msi files. At the end, there is actually no Installshield overhead because we have a basic msi project, and we do not need to bundle the installscript engine.
The only installer overhead is the msi file, which only adds 174KB to the installer. We use both pack200 and lzx compression to compress the installer files.
I'm happy to eat my own words. I've thus far managed to shrink rt.jar + charsets.jar + jce.jar + jsse.jar + localedata.jar from 32,816k + 8,312k + 80k + 482k + 779k = 42.469MB down to around 8MB... and I'm not done yet (I have more ideas on how to reduce the size further).
After being processed by pack200, the combined JAR goes down to 2.5MB. I think that is pretty darn impressive!
I would honestly like to work with Sun to make it both legal to distribute stripped down private JREs and also technically easier to produce such packages.
Can someone at Sun please comment on why the legal limitation is in place? I'm not looking for an "official answer". I just want to know whether it would be possible to have legal permission to do this for special cases. I think this makes a huge difference for desktop applications.
-- update --
Stripping away code actually reduces the size from 42.469MB down to 16MB (not 8MB like I reported earlier). PACK200 still reduces it down to 2.5MB.
Message was edited by: cowwoc
I must disagree. I took the 30+ MB rt.jar, stripping it down for use with my application (which uses networking, swing heavily) and I've got it down to 10MB. That's a 66% size reduction.
The ability to strip down the JRE and ship it as a "private JRE" with your application is a *huge* deal for J2ME, desktop applications where size is crucial. A size difference of 5-10 MB is usually enough to drive users away.
The current JRE is 7MB (only if you use the online installer). Think of how low we could get it by allowing customized JREs. My "ideal JRE" is a 2MB "core" that automatically downloads additional classes on-demand as the application references them. It makes a lot of sense for desktop applications.
The difficulty is that that native code references are not picked up by any tool I am aware of so you'd have to manually annotate all native methods with a list of classes, methods they reference. I know it's a lot of work; but I think the benefit is actually worth it in this case.
Unless you guys find a way to ship J2SE standard in Windows again (doubt that will happen anytime soon) .NET will have a major leg up over Java.
I stand corrected. rt.jar is 32MB because it is uncompressed (why is this btw? I don't think that Windows supports memory-mapped files...).
Anyway, when rt.jar is compressed, it goes down to 9MB which is more-or-less what I get when I try stripping down the JVM :(
Keep in mind I didn't finish trying to strip down the JRE. It might yet go down below this figure. Still, I am disappointed that there is no easy fix to go below the current JRE size. Part of the problem, is the high coupling between the various JRE components.
Any other ideas? How about moving to better compressors (i.e. RAR) instead of classic ZIP? The former is cross platform, better compression than ZIP and licensing fees are extremely low ($20 per build machine for unlimited distribution).
Gili, I think the current JRE install already uses PACK200 compression for rt.jar. This is considerably better than plain zip. I don't know why rt.jar is installed (on disk) in uncompressed form, but Windows certainly does support memory mapping.
I need AWT and Swing for my applications, and if you add in the core classes plus io, then all the rest doesn't add up to a significant reduction in download size.
Unfortunately I might be forced to agree.
Sun: How do I get an offline installer with 7MB (like your online installer?) Is the InstallShield configuration file that you use available to the public? I've got InstallShield locally and I'd like to tweak the installer and remove stuff I do not need (unused locales, fonts, etc)...
My assumption is that the offline installer is 15MB because it contains all locales and the online installer only downloads the appropriate locale which is why it's down to 7MB. If that is the case, I'd like to do the same for my applications. For example, if I have an en.us install, it should contain the JRE installer and on installation of my application I want it to trigger a silent install of the JRE on the user's machine.
I prefer this way because:
1) If I'm going to install the entire JRE, it might as well be public instead of private.
2) The JRE install script seems to be well written and I'd like to reuse it.
I think if modified-jre distribution would be allowed this would be really bad for java.
Most applications would ship a pre-shrinked java to just fit their needs -> a common runtime would not be possible anymore.
Till now it did not matter wether your Java was installed yourself or by Limewire or Opera -> installed once runs everything.
If you would allow modified builds then their would be tons of striped-down releases arround incompatible with each other just to save 3mb download size.
Btw. I would love to see an 7mb offline installer package like it was available for 1.3.x. Just plain English and thats it ;-)
> Is there a wiki for wish list?
Currently the General Mustang forum has been the
place for wishlists.
> I would like to argue that it be nice to break up big
> rt.jar into smaler ones, so that each can move at a
> different speed.
I will ask Stanley from deployment group to comment on this one. Thanks,
Breaking up rt.jar is an interesting topic to discuss, because many people see it as a simple way to cut down the JRE download size.
However, there are at least two factors to consider:
1. Class libraries that could be pulled out of rt.jar.
2. Compression ratio of rt.jar in the JDK/JRE installer.
It turns out that the JDK/JRE installer have done a very good job in compressing JAR file. Even if many big class libraries in rt.jar are pulled out (e.g. AWT, Swing, ...), the resulting JDK/JRE installer size reduction is only in the order of 1-2 MB, but the resulting installer will not have sufficient set of class libraries to run most Java applications.
Breaking up rt.jar is a myth to most Java developers as a silver bullet to the download reduction problem, but this approach actually does not work as great as most people think. On the other hand, we understand that JRE download size remains to be a critical issue to many Java developers, and we will continue to keep the JRE download size to be small in future releases.
I don't think you are considering the same types of applications that the rest of us are. I know that some people have already looked into this and rebuilt a stripped-down JRE to test the theory.
For one, all of the core classes (e.g. those available without any import statements or fully qualified names) can be placed in a separate jar. That gives you a download with a basic JRE with only the core language and none of the main Java APIs.
For some people that might already be enough! They will use their own third-party APIs for UI, the gaming community can work this way with the LWJGL bindings that give acces to OpenGL, Audio and input devices, without requiring AWT.
In the gaming case, they want to bundle their own stripped down JRE that will be a PRIVATE JRE for their application only. Currently the licensing forbids this, and I can't understand why, since a private JRE does not result in the sort of bad user experience that might happen had you installed half of the full JRE publicly and then some apps don't run etc.
Even if the savings are only 2 MB, in some cases we are so close to the threshold of what a casual user might consider downloading vs. something too big to download, that it can make the difference.
Do you have some measurements that you can share? Like logical partitioning and the sizes of each chunk?
I think for private bundled JREs that are used by one app the same rules don't apply. Many people go that route as an alternative to WebStart (it is a good idea, but the implementation needs a lot fo work to make it more inviting to the end user). Since they test against a specific version, they bundle that version. With WebStart you can specify the version to use, but then if the user doesn't have that version, their 3MB download is suddenly much bigger, because it needs to pull down the whole JRE. Can webstart download only diffs between the user's currently installed JRE(s) and the requested one? The actual number of classes and native code that changes from one release to another must be much smaller than the whole.
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.