On Mon, Oct 21, 2013 at 9:02 AM, David Holmes <david.hol...@oracle.com> wrote:
> 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.
>
Sorry, you're right. I've somehow misinterpreted $(PATH_SEP) as "/"
instead of ":".
>
>> 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.
>
OK, I see. So I'll ask the IBM colleagues how to correctly detect and
set BOOT_RTJAR for J9.
Regards,
Volker
> 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.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.
>>>>
>>>>
>>>>
>
