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

[David Holmes]

On 15/11/2013 8:36 PM, Volker Simonis wrote:
> On Fri, Nov 15, 2013 at 12:32 AM, David Holmes <david.holmes at oracle.com> wrote:
>> 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"
>>> (https://bugs.openjdk.java.net/browse/JDK-8026964) 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.
>
> OK, but what is the definition of 'rt.jar'. I doubt that is is
> something like "..the required classes needed to bootstrat the jdk..".

No it is the set of required classes to run a Java application on the 
(Open)JDK that doesn't use any of the "optional" Java API's that exist 
in other jar files.

Cheers,
David

>   I think that currently the build just works with the Oracle/OpenJDK
> bootstrap JDKS because it happens that 'rt.jar' contains most of the
> classes which have to be in the boot class path. But this is not the
> case for J9 (e.g. they have SAXParser and other xml stuff in an extra
> xml.jar). They have just distributed the classes over more .jar files
> which seems perfectly legal.
>
>> The other boot classpath
>> stuff is not relevant to the build processes that set the bootclasspath.
>>
>> 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?
>>
>
> This was my first approach (see the description of
> https://bugs.openjdk.java.net/browse/JDK-8026964) but I was not sure
> if I really got all the relevant jars. And this could actually change
> any time the build references more or other classes or any time the J9
> changes their class partition (not to speak about other JDK which may
> choose yet another boot jar layouts).
>
> So just using sun.boot.class.path seemed to be the easiest, most
> general and most robust solution.
>
>> Cheers,
>> David
>>
>>
>>> 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
>>>
>>