Hi Erik, with the small changes proposed in "8026964: Building with an IBM J9 boot jdk requires special settings for BOOT_RTJAR"
https://bugs.openjdk.java.net/browse/JDK-8026964 I could finally successfully build with J9 as bootstrap jdk. I saw that you already submitted this change so I'm probably to late, but I think you could also have removed BOOTJDK_CHECK_TOOL_IN_BOOTJDK(RMIC,rmic) from boot-jdk.m4 and RMIC=@FIXPATH@ $(BOOT_JDK)/bin/rmic from spec.gmk.in because it is not used anymore. Maybe you can remove it with another change. 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. >>>> >>>> >
