JDK-4976363 : Java-related executables should use shared zlib library
  • Type: Enhancement
  • Component: tools
  • Sub-Component: launcher
  • Affected Version: 5.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2004-01-09
  • Updated: 2005-12-20
  • Resolved: 2005-12-17
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 6
6 b65Fixed
Related Reports
Relates :  
Relates :  
Description
After the launcher was updated with multiple jre support (bug 4811102), the build process for the linux and solaris executables (e.g. java, javac, javah, etc.) builds and links a static version of zlib for each executable.  It would be preferable if all the launcher-derived binaries used the same zlib shared object already generated by the build.

Comments
SUGGESTED FIX See evaluation. The following files were modified: make/common/Program.gmk make/common/Release.gmk make/java/Makefile make/java/lsr/Makefile make/java/lsr/FILES_c.gmk make/java/lsr/mapfile-vers make/java/instrument/Makefile src/share/native/java/util/lsr/parse_manifest.c src/share/bin/parse_manifest.c src/share/native/java/util/lsr/manifest_info.h src/share/bin/manifest_info.h src/share/native/java/util/lsr/version_comp.h src/share/bin/version_comp.h src/share/native/java/util/lsr/wildcard.h src/share/bin/wildcard.h src/share/native/java/util/lsr/wildcard.c src/share/bin/wildcard.c src/share/native/java/util/lsr/version_comp.c src/share/bin/version_comp.c src/share/native/java/util/lsr/lsr_util.h src/share/native/java/util/lsr/lsr_util.c The vast majority of these changes are mangling names and Makefile work.
17-10-2005

EVALUATION The solution here exactly meets the description: "all the launcher-derived binaries used the same zlib shared object already generated by the build". Although extra credit would be if the Java zip interfaces also used the same zlib shared object, this isn't (practically) possible. The Java libzip (bad name) has dependencies which cycle back to libjvm and libjava. These libraries take on different forms depending upon the -client/-server flags and the manifest must be read before this is determined (because indeed, eventually the manifest may contain this information). Hence, a separate "Launcher Support Library" (lsr) is created and simply needed by the launcher via a $ORIGIN based dependency. In addition to the libzip routines, several other launcher modules were moved into this new library, resulting in further sharing - parse_manifest, version_comp, and wildcard. The splash screen stubs were not moved as they would change almost nothing in terms of size and performance while further cluttering the namespace. More importantly, I expect this implementation to be modified in the not too distant future. In addition to build time (and build clutter) this also reduces the download size. Of course, the smallest improvement is the one we most care about: the Windows jre download. By simply measuring the size of the download .exe bundles we improve (shrink) the download size by 50K (49377 to be exact, but that will probably vary by a few bytes depending upon the exact build environment). java.instrument also uses these routines, but it was only modified to find the appropriate files in their new location. A separate CR will be filed on this to allow the folk who "own" java.instrument to determine what the right thing is. *** (#1 of 1): [ UNSAVED ] ###@###.###
17-10-2005