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

David Holmes david.holmes at
Thu Nov 14 23:32:47 UTC 2013

Hi Volker,

On 15/11/2013 2:35 AM, Volker Simonis wrote:
> Hi,
> 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?

For the combination of the OpenJDK libraries and VM it really just meant 
rt.jar (not everything on the bootclasspath) as the build system "knows" 
what is in there and that it is what was needed. The other boot 
classpath stuff is not relevant to the build processes that set the 

I don't see an issue with generalizing it to the full boot classpath but 
is it necessary? Can't you just define it to be rt.jar plus whatever 
jar(s) is needed for J9?


> 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 \
>   <jdk_root>/jre/classes
> 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.
> Regards,
> Volker

More information about the core-libs-dev mailing list