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

[Volker Simonis]

Hi Erik,

On Fri, Nov 15, 2013 at 10:09 AM, Erik Joelsson
<erik.joelsson at oracle.com> wrote:
> Hello Volker,
>
> I like this solution, even if it could be viewed as a bit of overkill.
>

thanks:)

I've just posted a RFR to the build-dev list:
http://mail.openjdk.java.net/pipermail/build-dev/2013-November/011108.html

with two small enhancements:
 - remove non-existing path elements from the 'sun.boot.class.path'
path list (e.g. jre/classes, jfr.jar, ..)
 - convert the path list to Unix form (with cygpath) on Windows to
avoid problems with FIXPATH later on.

Hope you like it:)
Volker

> /Erik
>
>
> On 2013-11-14 17:35, Volker Simonis wrote:
>>
>> Hi,
>>
>> I wanted to solve "8026964: Building with an IBM J9 boot jdk requires
>> special settings for BOOT_RTJAR"
>> (https://bugs.openjdk.java.net/browse/JDK-8026964) 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 \
>>   <jdk_root>/jre/classes
>>
>>
>> The Oracle documentation I could find ("How Classes are Found" at
>> http://docs.oracle.com/javase/7/docs/technotes/tools/findingclasses.html)
>> 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
>
>