Hi Neil, Steve,
is there an easy way to detect and specify a correct setting for
$(BOOT_RTJAR) if we are using an IBM J9 as bootstrap jdk in the new
build system? With OpenJDK/Oracle based boot jdks $(BOOT_RTJAR) is
simply set to "$BOOT_JDK/jre/lib/rt.jar" but this doesn't work with
IBM J9 because many of the classes which are in "rt.jar" in OpenJDK
are spread over other jar files in J9.
This leads to problems during the build if the newly compiled javac is
executed with "-source 7 -target 7 -bootclasspath $(BOOT_RTJAR)"
because J9 will not find basic classes like Object which are not in
rt.jar.
I managed to compile JDK8 with IBM J9 as bootstrap jdk with the
following extra settings in "boot-jdk.m4"
diff -r 584dc2e95e04 common/autoconf/boot-jdk.m4
--- a/common/autoconf/boot-jdk.m4 Thu Sep 12 12:29:17 2013 -0700
+++ b/common/autoconf/boot-jdk.m4 Mon Oct 21 16:22:35 2013 +0200
@@ -268,6 +268,14 @@
BOOT_RTJAR="`cd ${BOOT_RTJAR%/*} && pwd`/${BOOT_RTJAR##*/}"
fi
fi
+# IBM J9 jdks need a special BOOT_RTJAR setting
+if $BOOT_JDK/bin/java -version 2>&1 | grep 'IBM J9'; then
+
BOOT_RTJAR="$BOOT_RTJAR:$BOOT_JDK/jre/lib/math.jar:$BOOT_JDK/jre/lib/xml.jar"
+ IBM_J9_VM_JAR=`$BOOT_JDK/bin/java -XshowSettings 2>&1 | $TR ' '
'\n' | grep 'vm.jar'`
+ if test "x$IBM_J9_VM_JAR" != x; then
+ BOOT_RTJAR="$BOOT_RTJAR:$IBM_J9_VM_JAR"
+ fi
+fi
BOOT_TOOLSJAR="$BOOT_JDK/lib/tools.jar"
BOOT_JDK="$BOOT_JDK"
AC_SUBST(BOOT_RTJAR)
So this adds math.jar (needed for e.g. BigInteger), xml.jar (needed
for e.g. SAXParser) and vm.jar (needed for e.g. Object) to
$(BOOT_RTJAR). Do you consider this "enough" or should I add the jars
which contain classes from the java and javax packages to
$(BOOT_RTJAR). And what about "vm.jar"? Do you consider the detection
via '-XshowSettings' stable for the upcoming Java 8 as well? I first
wanted to construct the path to vm.jar manually, but it contains the
architecture as well as the 'compressed pointer mode' so I thought
that taking the path from the '-XshowSettings' would be the simplest
solution.
I opened bug: "8026964: Building with an IBM J9 boot jdk requires
special settings for BOOT_RTJAR"
https://bugs.openjdk.java.net/browse/JDK-8026964
for this issue and if you agree with the solution I will send out a
request for review and check it in into our ppc-aix staging
repository.
Thank you and best regards,
Volker
On Fri, Oct 18, 2013 at 5:50 PM, Erik Joelsson <erik.joels...@oracle.com> wrote:
> Hello Volker,
>
> Building without a -bootclasspath results in the following warning which is
> likely why it was added in the first place:
>
> warning: [options] bootstrap class path not set in conjunction with -source
> 1.7
>
> Note that we are using the bootstrap javac, so it's not the one bundled with
> the bootjdk. Bootstrap javac wants to generate jdk8 classes by default.
>
> When using an OracleJDK as boot, tools.jar needs to be on the classpath when
> building BUILD_BOOTSTRAP_CORBA. I put BOOT_TOOLSJAR there, but that's
> actually incorrect. I should have put the bootstrap javac jar instead. And
> it doesn't need to be on the bootclasspath, just -classpath.
>
> I tried building without -bootclasspath in corba, but it generates a big
> chunk of warnings:
>
> /localhome/hg/jdk8-tl/corba/src/share/classes/com/sun/corba/se/spi/orb/ORB.java:100:
> warning: AppContext is internal proprietary API and may be removed in a
> future release
> import sun.awt.AppContext;
> ^
> /localhome/hg/jdk8-tl/corba/src/share/classes/sun/corba/Bridge.java:39:
> warning: Unsafe is internal proprietary API and may be removed in a future
> release
> import sun.misc.Unsafe ;
> ^
> /localhome/hg/jdk8-tl/corba/src/share/classes/sun/corba/Bridge.java:40:
> warning: ReflectionFactory is internal proprietary API and may be removed in
> a future release
> import sun.reflect.ReflectionFactory ;
>
> I don't know why these aren't showing otherwise.
>
> Could we figure out a more general way of expressing a proper bootclasspath
> that works for J9 too?
>
> /Erik
>
>
> On 2013-10-18 17:15, Volker Simonis wrote:
>>
>> Hi Erik,
>>
>> I had to fix another issue in the JAXWS build
>> (https://bugs.openjdk.java.net/browse/JDK-8026874) but with that I've
>> finally managed to get to the Corba build with a J9 bootstrap JDK.
>>
>> With the following small change in BuildCorba.gmk:
>>
>> - FLAGS:=$(BOOT_JDK_SOURCETARGET) -bootclasspath $(BOOT_RTJAR)
>> $(DISABLE_CORBA_WARNINGS),\
>> + FLAGS:=$(BOOT_JDK_SOURCETARGET) $(DISABLE_CORBA_WARNINGS),\
>>
>> I could successfully build Corba with J9 as bootstrap JDK. So you (and
>> the others) were right with your observation that during build time we
>> don not call the boot JDKs idlj/rmic compilers any more. That's good!
>>
>> Now to your change (and my two changes lines above). You did the
>> following in BuildCorba.gmk:
>>
>> - FLAGS := $(BOOT_JDK_SOURCETARGET) -bootclasspath $(BOOT_RTJAR)
>> $(DISABLE_CORBA_WARNINGS), \
>> + FLAGS := $(BOOT_JDK_SOURCETARGET) -bootclasspath
>> $(BOOT_RTJAR)$(PATH_SEP)$(BOOT_TOOLSJAR) \
>> + $(DISABLE_CORBA_WARNINGS), \
>>
>> This probably doesn't do what you intended because $(BOOT_RTJAR)
>> already expands to a complete path and you then append another path
>> which will give you an invalid file. So actually it turns out that
>> your change is equivalent to mine where I completely eliminated the
>> '-bootclasspath' option (although I think mine is cleaner :)
>>
>> So I wanted to know why we need the '-bootclasspath' option at all,
>> because we are anyway compiling with the boot JDK and it will use its
>> $(BOOT_RTJAR) by default.
>>
>> The same problem also exists in makefiles/Setup.gmk
>>
>> $(eval $(call SetupJavaCompiler,GENERATE_OLDBYTECODE,\
>> JVM:=$(JAVA),\
>> JAVAC:=$(NEW_JAVAC),\
>> - FLAGS:=-source 7 -target 7 -bootclasspath $(BOOT_RTJAR)
>> $(DISABLE_WARNINGS),\
>> + FLAGS:=-source 7 -target 7 $(DISABLE_WARNINGS),\
>> SERVER_DIR:=$(SJAVAC_SERVER_DIR),\
>> SERVER_JVM:=$(SJAVAC_SERVER_JAVA)))
>>
>> I don't understand why we need the '-bootclasspath' option to javac
>> because this will executed by the boot JDK and as far as I understand
>> it will pick up its $(BOOT_RTJAR) anyway.
>>
>> The problem I have with this construct is that other VMs may not have
>> all required classes in rt.jar and as far as I know that's not part of
>> the Java 7 specification. For example J9 has jre/lib/rt.jar but some
>> classes like Object are in another jar file
>> (jre/lib/ppc64/{compressedrefs|default}/jclSC170/vm.jar).
>>
>> So if this '-bootclasspath' option is really needed, I will be
>> necessary to rework the $(BOOT_RTJAR) detection for every distinct
>> boot JDK which is not very nice because I think any Java 7 compliant
>> JDK should work as boot JDK out of the box.
>>
>> What do you think?
>>
>> Regards,
>> Volker
>>
>>
>>
>>
>> On Wed, Oct 16, 2013 at 2:51 PM, Volker Simonis
>> <volker.simo...@gmail.com> wrote:
>>>
>>> On Wed, Oct 16, 2013 at 12:22 PM, Erik Joelsson
>>> <erik.joels...@oracle.com> wrote:
>>>>
>>>> On 2013-10-15 17:29, Volker Simonis wrote:
>>>>>
>>>>> Hi Erik, Alan,
>>>>>
>>>>> first of all I think this is a good change because it helps porters to
>>>>> build a complete JDK even if the newly build rmic wouldn't run.
>>>>>
>>>>> On the other hand I'm a little bit concerned if this change still
>>>>> allows it to bootstrap with a non-Oracle based bootstrap JDK. I
>>>>> remember that we had some problems with IBM J9 as bootstrap JDK
>>>>> because they have different default implementations of idlj and rmic
>>>>> (see
>>>>>
>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/raw-file/tip/README-ppc.html#_TOC_ANCHOR_4_)
>>>>>
>>>>> Fortunately, the IBM J9 also contains the original Oracle idlj and
>>>>> rmic versions and with the old build it was possible to use them by
>>>>> specifying the two variables:
>>>>>
>>>>> IDLJ='$(ALT_BOOTDIR)/bin/java -cp $(ALT_BOOTDIR)/lib/tools.jar
>>>>> com.sun.tools.corba.se.idl.toJavaPortable.Compile'
>>>>> RMIC='$(ALT_BOOTDIR)/bin/java -cp $(ALT_BOOTDIR)/lib/tools.jar
>>>>> sun.rmi.rmic.Main'
>>>>>
>>>>> I'm not sure if this is still possible with the new build system.
>>>>>
>>>>> By the way, the main problem why the IBM J9 idlj and rmic didn't work
>>>>> out of the box were some command line options which were only
>>>>> supported by the Oracle implementation. It would therefore be very
>>>>> nice if you could completely remove such options from the build.
>>>>>
>>>>> And you can easily check this by trying the IBM J9 as bootstrap JDK on
>>>>> Linux/x86_64.
>>>>
>>>> I tried building with J9, but it broke in Hotspot already so couldn't
>>>> get to
>>>> the relevant parts of the build.
>>>
>>> Just realised this myself and opened "JDK-8026703: Wrongly placed
>>> <xsl:import> element in Event-Based JVM Tracing .xsl files"
>>> (https://bugs.openjdk.java.net/browse/JDK-8026703). The fix will
>>> follow in the next minutes...
>>>
>>> Unfortunately, this is not the last problem before getting to the
>>> "relevant parts" :(
>>>
>>>> But as David pointed out, this should work
>>>> as we aren't running the rmic or idlj in the bootjdk at all now.
>>>
>>> This sounds good!
>>> But nevertheless I'll try to verify it if I'll manage to get around
>>> the other build issues :)
>>>
>>>> /Erik
>>>>
>>>>> Thank you and best regards,
>>>>> Volker
>>>>>
>>>>>
>>>>> On Tue, Oct 15, 2013 at 4:40 PM, Alan Bateman <alan.bate...@oracle.com>
>>>>> wrote:
>>>>>>
>>>>>> On 15/10/2013 15:30, Erik Joelsson wrote:
>>>>>>>
>>>>>>> Currently the RMI stubs in the jdk are built with the newly built
>>>>>>> rmic
>>>>>>> binary at the end of the build. This patch changes that and instead
>>>>>>> builds a
>>>>>>> bootstrap version of the rmic classes, much like bootstrap javac in
>>>>>>> langtools, which runs on the bootjdk, but generates classes for the
>>>>>>> new
>>>>>>> jdk.
>>>>>>> The new solution is more friendly to cross compilation.
>>>>>>>
>>>>>>> A few notes on the patch:
>>>>>>>
>>>>>>> * In src/share/classes/sun/tools/tree/Node.java, I had to change a
>>>>>>> call
>>>>>>> to
>>>>>>> a jdk8 only constructor in java.lang.InternalError.
>>>>>>> * The packages included when compiling rmic were just picked by
>>>>>>> extending
>>>>>>> for each missing class until the compilation succeeded. If someone
>>>>>>> knows
>>>>>>> of
>>>>>>> a crucial package or class that needs to be included, please say so.
>>>>>>> * I renamed a parameter to SetupJavaCompilation. I do not consider
>>>>>>> the
>>>>>>> parameter a hack anymore, but a necessary option for this case.
>>>>>>> * In RMICompilation, the dependency file is now a real touch file
>>>>>>> instead
>>>>>>> of a virtual one. This was needed for proper dependencies in
>>>>>>> GenerateClasses.gmk.
>>>>>>> * All of corba is compiled twice since I have no idea which parts
>>>>>>> would
>>>>>>> actually be needed. This doesn't add much build time since it can be
>>>>>>> run
>>>>>>> effectively in parallel with the rest of the corba build.
>>>>>>> * I put the compilation of bootstrap rmic in GenerateClasses.gmk
>>>>>>> directly
>>>>>>> instead of Tools.gmk. This was to not add much compile time, since
>>>>>>> Tools.gmk
>>>>>>> is included and therefore parsed a lot.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6604021
>>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/6604021/webrev.01/
>>>>>>>
>>>>>>> /Erik
>>>>>>
>>>>>> It's great to see a solution coming for this, it was always been
>>>>>> troublesome
>>>>>> to run the newly built rmic.
>>>>>>
>>>>>> So what are the implications of this? I assume it means that we need
>>>>>> to
>>>>>> be
>>>>>> careful in sun.rmi.rmic, sun.tools.{asm,java,javac,tree,util} and
>>>>>> restrict
>>>>>> API usage to what is available in the boot JDK - is that right?
>>>>>>
>>>>>> -Alan.
>>>>
>>>>
>
