RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar

David Holmes david.holmes at oracle.com
Mon Oct 21 07:04:30 UTC 2013 

On 19/10/2013 1:50 AM, Erik Joelsson 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.

Because a class on the bootclasspath can do what it likes. Classes on 
the classpath aren't supposed to access JDK internal APIs - hence the 
warnings.

David
-----

> 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.simonis at gmail.com> wrote:
>>> On Wed, Oct 16, 2013 at 12:22 PM, Erik Joelsson
>>> <erik.joelsson at 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.Bateman at 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.
>>>>
>

More information about the build-dev mailing list