Hi Erik, On Fri, Nov 15, 2013 at 10:09 AM, Erik Joelsson <erik.joels...@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 > >