Setting BOOT_RTJAR: rt.jar vs. 'sun.boot.class.path'

Volker Simonis volker.simonis at
Thu Nov 14 16:35:16 UTC 2013


I wanted to solve "8026964: Building with an IBM J9 boot jdk requires
special settings for BOOT_RTJAR"
( and came across the
question what the real semantics of BOOT_RTJAR is?

Currently, for OpenJDK/Oracle based boot JDKs BOOT_RTJAR is simply set
to "rt.jar" (and for MacOSX to "classes.jar" if "rt.jar" is not
found). For an IBM J9 boot JDK however this is not so easy because
some essential classes (like Object or String) are not contained in
"rt.jar" (see the before mentioned bug for more details). So for IBM
J9 we need to add additional jar-files to BOOT_RTJAR.

Now I wonder what's the exact semantics of BOOT_RTJAR i.e. which are
the required classes it should contain? Naively I would assume these
are the classes contained in the "sun.boot.class.path" system
property. But for an OpenJDK/Oracle based JDK, this property contains
much more classes than just rt.jar:

sun.boot.class.path= \
 <jdk_root>/jre/lib/resources.jar \
 <jdk_root>/jre/lib/rt.jar \
 <jdk_root>/jre/lib/sunrsasign.jar \
 <jdk_root>/jre/lib/jsse.jar \
 <jdk_root>/jre/lib/jce.jar \
 <jdk_root>/jre/lib/charsets.jar \
 <jdk_root>/jre/lib/jfr.jar \

The Oracle documentation I could find ("How Classes are Found" at
states: "...Bootstrap classes are the classes that implement the Java
2 Platform. Bootstrap classes are in the rt.jar and several other jar
files in the jre/lib directory. These archives are specified by the
value of the bootstrap class path which is stored in the
sun.boot.class.path system property..."

So for me it seems that the current solution of using just "rt.jar"
works only accidentally until now and it would be more logical to set
BOOT_RTJAR to the value of "sun.boot.class.path". This value could be
queried during the configure process (e.g. by using the -XshowSettings
option). As far as I can see '-XshowSettings' and the
"sun.boot.class.path" property is supported on all the JDKs I know
(OpenJDK, Oracle JDK, SAP JVM, IBM J9, HP JVM).

So my question is, if there are any objectives if I'd change the
current BOOT_RTJAR detection to the following lines:

  # Parse the settings of the 'sun.boot.class.path' property
  # The tricky thing is that we must quote AWK field references (i.e.
$1, $2, ..)
  # and the name 'index' which is a M4-buildin function by placing brackets
  # (i.e. '[]') into the corresponding names.
  BOOT_RTJAR=`$BOOT_JDK/bin/java -XshowSettings 2>&1 | $NAWK ' \
      /path.separator/      { path_separator = $[]3} \
      /sun.boot.class.path/ { sun_boot_class_path = $[]3; \
                              while (getline && !in[]dex($[]0,"=")) { \
                                sun_boot_class_path =
sun_boot_class_path "\n" $[]1 \
                              } \
                            } \
      END { gsub("\n", path_separator, sun_boot_class_path); print
sun_boot_class_path }'`

which effectively set BOOT_RTJAR to the value of 'sun.boot.class.path'
(separated by the valid platform path separator which is also queried
from the output of '-XshowSettings').

I've tested this and it works on Linux and Solaris with an OppenJDK
based boot JDK and on AIX with the IBM J9 boot JDK. I think it would
be more robust for other JDKs as well. And of course it fixes my bug:)

So if there are no general objections I'll be happy to prepare a
formal webrev for this issue.


More information about the core-libs-dev mailing list