On Fri, Nov 15, 2013 at 12:32 AM, David Holmes <david.hol...@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..". 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 >> >
