JDK-8057085 : 64bit offline isn't compressed
  • Type: Bug
  • Component: install
  • Sub-Component: install
  • Affected Version: 8u40,8-pool,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: x86
  • Submitted: 2014-09-02
  • Updated: 2015-06-03
  • Resolved: 2014-10-24
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.
JDK 8 JDK 9
8u40 b14Fixed 9Fixed
Description
In 8u20, we moved the jre payload to inside of the installer.exe as a resource.  The installer.exe is now residing in the MSI binary table, which does not get MSZIP compressed.  

As a workaround for 8u20, we temporarily turned on UPX compression for the 32-bit offline, so that file is compressed.  Though UPX is not idea for large offline installers, because it does not show feedback/progress...and appears to hang on older/slower systems.  Also, the current version of UPX that we use does not work for 64bit exe's. 

The correct long term fix is to move installer.exe to the file table, where it will get automatic MSZIP compression.  MSI compression is comparable to UPX when you are dealing with large 80MB files like the jre offline.  One side effect is that we will need a way of deleting the installer.exe at the end of the install.  Normally, we would just delete it using installer.exe, but installer.exe can't delete itself when it is running.  We may need to create a helper dll to delete installer.exe as a custom action at the end of the install.
Comments
Verified with 8 PIT b14. Issue fixed. The size of jre180.exe is 40MB. The size of this file has reduced from ~90MB to ~40MB, as expected by Dev. Attached screenshot of listing of files as shown in Windows-amd64 folder.
05-11-2014
Agree.
24-10-2014
ah ok, you mean the installer.exe. I agree. Anyways, I think this approach can be considered for the future, but there is an easier way to fix this.
24-10-2014
Agree, we still need to build three separate msi files anyways. However if we build installer.exe without adding patch and baseimage into resources, we can build it only once per build.
24-10-2014
I don't think moving UI to wrappers defeated the one-stop-shop installer.exe vision. Functionality-wise, installer.exe does basically everything for installing the JRE. Moving the baseimage and patch files to the msi does not mean we only need to build one msi. We still need a smaller patch msi (without the base image) and a full msi for full installs. And we still need the enterprise msi for one file-per-component. So we would still need to build 3 msi's. I'm not sure that there would be as much of a performance improvement to warrant the large change. I have a pretty simple solution to deleting the installer.exe.
24-10-2014
The plan has been defeated already by moving UI into wrappers, hasn't it? Current memory usage: 1. basimage in msi as a part of installer.exe; 2. basimage in installer.exe extracted into memory by msi to run as a final custom action; 3. basimage extracted from installer.exe and saved to disk by installer.exe. Proposed memory usage when basimage is saved into msi and removed from installer.exe resources: 1. basimage directly in msi; 2. basimage extracted from msi and saved to disk by MSI service before running installer.exe. The later is definitely more work. However it promises better performance and also allows to have only a single installer.msi executable in the build instead of three (build system should create less targets -> build speed up). BTW, I'm not sure the proposed solution is that much work. It seems to me less effort anyways compared to crafting solution that will delete installer.exe
23-10-2014
That's a possible solution, but it goes against our plan to have everything in the installer.exe. It's also more changes. I think I have a simplified solution to the removal of installer.exe at the end. Why would less memory be used? The memory used would just move from installer.exe to the msiexec process right?
23-10-2014
If we store baseimage and patch image not in installer.exe resources but in msi file table that can save us from need to remove installer.exe when installation is complete. Also this will speed up the installation process and minimize memory used.
23-10-2014
I think it's simpler to just move installer.exe from the binary table (which isn't compressed) to the File table (which gets MSZIP compression). I've already done that part of the work. The only tricky part is deleting the installer.exe at the end of the install. You can't delete it from installer.exe itself, because it's locked and running. I'm trying to come up with a clever solution to delete the file. We can't use the RemoveFile table because the RemoveFile standard action has already been run at that point. We need a custom action of some sort.
23-10-2014
In 8u40 and 9 installer.exe is no longer compressed with UPX. The more simple solution would be to write baseimage and patch image into installer resources as zipped files. When installer runs, it should extract these files from the resources and unzip them.
23-10-2014