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

[David Holmes]

On 19/10/2013 1:15 AM, 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 :)

I don't follow this. The bootclasspath can contain multiple directories 
and/or jar files. Classes found on the bootclasspath are loaded by the 
boot loader and have elevated privileges.

> 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.

OpenJDK's javac requires/suggests you set the bootclasspath when 
specifying -target/-version to ensure you actually compile against the 
API that matches the requested version.

David
-----

> 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.
>>>
>>>