JDK-4267080 : Java Kernel: break up rt.jar into downloadable-on-demand components to reduce jre size
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: deployment_toolkit
  • Affected Version: 1.2.2,1.3.0,1.3.1,1.4.0,5.0,6,7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS:
    generic,windows_95,windows_nt,windows_2003,windows_xp,windows_vista generic,windows_95,windows_nt,windows_2003,windows_xp,windows_vista
  • CPU: generic,x86
  • Submitted: 1999-08-30
  • Updated: 2008-01-31
  • Resolved: 2008-01-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
6u10 b02Fixed 7Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Name: skT88420			Date: 08/30/99

One of the main problems of the Java platform is that it is not very client 'friendly'. Asking people to download a huge Runtime Environment release does not look very attractive.

I have had an idea to minimise this problem but not sure about its feasibility. You could add a special utility to the SDK. This will examine a set of a specific program's classes and determine which components of Java are needed. Then it will make a custom JRE installer geared towards the clients, which will be quite smaller than the full JRE download.

The installer will be distributed with the specific program, and when the client executes it, it will install all the necessary Java components needed to run the program. Also, by using a special versioning system, the installer should avoid replacing already installed components which are of greater version than the ones contained within the installer.

Ending up with a custom JRE installation of 2MB-3MB is still way better than asking users to download a full runtime of two or three times as much.

Finally, to eliminate consufion, the custom JRE installer could also install a little program on the client to allow him to complete or update their installed JRE release, by checking on the Java website.

This is a critical issue since, as the Java platform progresses, it also becomes bigger and I am not sure if end users are willing or capable of accepting this situation.

Best regards, 
Vangelis Erotokritakis
(Review ID: 94585) 

EVALUATION jplan item 158 - Java Kernel for Dolphin

EVALUATION We are currently looking into Installshield 7.0 which uses the Windows Installer service. It has a feature called install-on-demand, which only makes the user install the jre-core. Then later on if they need further components it will go back and install them automatically. If we use this with install-from-the-web media type, they only need to download the components they need at that time. We will be looking into making better jre components eventually in future releases (Tiger/Mantis). As for hopper, we would most likely just be splitting the components into jre-core and i18n. This is only if we decide to move to installshield 7.0. We wouldn't be able to use the "special versioning system", because certain components of one java release, will most likely not work with other components of other java releases. We do not even consider update releases the same as their previous release. Until we change they way we version the actual java product, this is not feasible. Defer to future releases. ###@###.### 2004-11-23 20:34:39 GMT