Test Backports

[Joe Darcy]

On 04/09/10 05:05 PM, Andrew John Hughes wrote:
> On 9 April 2010 17:30, Joe Darcy <joe.darcy at oracle.com> wrote:
>   
>> Andrew John Hughes wrote:
>>     
>>> On 9 April 2010 01:47, Joe Darcy <joe.darcy at oracle.com> wrote:
>>>
>>>       
>>>> On 04/08/10 05:43 PM, Andrew John Hughes wrote:
>>>>
>>>> On 9 April 2010 01:27, Joe Darcy <joe.darcy at oracle.com> wrote:
>>>>
>>>>
>>>> On 04/08/10 04:54 PM, Andrew John Hughes wrote:
>>>>
>>>> On 8 April 2010 23:22, Joe Darcy <joe.darcy at oracle.com> wrote:
>>>>
>>>> [snip]
>>>>
>>>>
>>>>
>>>> On another note, there is now some code requiring source level 6 in
>>>> OpenJDK6 (due to use of the @Override annotation on interfaces):
>>>>
>>>>  src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java
>>>>  src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java
>>>>  src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java
>>>>  src/share/classes/sun/security/provider/certpath/OCSPResponse.java
>>>>  src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java
>>>>
>>>>
>>>> There is an overly-long story behind -source 5 vs. -source 6 and
>>>> @Override.
>>>> The short answer is that javac in JDK 6 unconditionally applies the more
>>>> liberal (and more useful) semantics for @Override.  For the JDK sources,
>>>> a
>>>> compiler that does the same should be used.
>>>>
>>>>
>>>>
>>>>
>>>> Exactly.  I know ecj throws it out for 5 but not for 6 and thus
>>>> building using ecj (our method for bootstrapping) falls foul of the
>>>> classes above.  I'm not sure if javac is allowing them through because
>>>> its version of 1.5 allows it or it is simply defaulting to 6 because
>>>> nothing else is specified.  I had a quick look but the version is
>>>> currently set in more than one place, so I think this needs a more
>>>> in-depth review and I'd prefer it waits until b20 to be on the safe
>>>> side.
>>>>
>>>>
>>>>
>>>> The javac command in JDK 6, both open and proprietary, will allow use of
>>>> @Override on interfaces, even if "-source 5" is specified.
>>>>
>>>>
>>>>
>>>> Ok, that explains why it works for javac and fails for ecj.  Is there
>>>> any reason we're using 5 for a build of OpenJDK 6?  The bootstrapping
>>>> classes are now explicitly 5, but surely the final JDK code should be
>>>> 6.
>>>>
>>>>
>>>> Not necessarily.  How rt.jar and tools.jar are compiled (and even if
>>>> there
>>>> is a rt.jar and tools.jar) is an implementation artifact of the JDK.  One
>>>> of
>>>> the main benefits of target 6 over target 5 is that stackmaps are
>>>> supported
>>>> in the class files which allows for faster class file verification.
>>>> However, files on the bootclasspath, such as rt.jar, are not verified
>>>> anyway
>>>> so using target 6 to compile the classes going into rt.jar would add to
>>>> the
>>>> size of rt.jar without conferring any speed benefit since verification is
>>>> skipped anyway.
>>>>
>>>>
>>>>
>>>> Ok.  Well we have 1.6 code listed above, so we either need to decide
>>>> to move to 6 or revert these @Override annotations.
>>>>
>>>>
>>>> Is there still a need to bootstrap with ecj as opposed to an earlier
>>>> OpenJDK/IcedTea build?
>>>>
>>>>
>>>>
>>>> We keep it working.  It makes it possible to port to new platforms as
>>>> gcj can be built without an existing Java stack being present.
>>>>
>>>>
>>>> I suppose that is easier than setting up a cross compilation environment
>>>> for
>>>> Java...
>>>>
>>>>
>>>>
>>>> [snip]
>>>>
>>>>
>>>>
>>>> Next one is 6909153 which turns off a number of options that fail or
>>>> are inappropriate on Zero:
>>>>
>>>> http://cr.openjdk.java.net/~andrew/6909153/webrev.01/
>>>>
>>>> Ok to push?
>>>>
>>>>
>>>> Approved to go back.
>>>>
>>>> I'm not sure of the HotSpot conventions, but the removal of the opening
>>>> brace on the end of line 1824 of compileBroker.cpp looks suspect to me.
>>>>
>>>> However, I see this was done in the JDK 7 HotSpot sources so it is more
>>>> important to keep the patches the same.
>>>>
>>>>
>>>>
>>>> The if block was a one-liner, so the brace is now being used to close
>>>> the new conditional instead.
>>>>
>>>> Right; I had to look twice to verify it was all okay :-)
>>>>
>>>>
>>>>
>>>> Me too!
>>>>
>>>>
>>>>
>>>> Not ideal, but not a bug and, as you
>>>> say, it's as it is in 7.  This was a clean hg import.
>>>>
>>>> Pushed: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/131295e4931b
>>>>
>>>> The next one is 6913869, an assertion fix needed to build on ppc and
>>>> ZSeries:
>>>>
>>>> http://cr.openjdk.java.net/~andrew/6913869/webrev.01/
>>>>
>>>> Ok to push?  Another clean hg import from jdk7.
>>>>
>>>>
>>>> Approved to go back.
>>>>
>>>>
>>>>
>>>> Done:
>>>>
>>>> The last one is 6914622:
>>>>
>>>> http://cr.openjdk.java.net/~andrew/6914622/webrev.01/
>>>>
>>>> This ensures that all flags are printed on product VMs, rather than
>>>> options being hidden.
>>>>
>>>>
>>>> Looks fine; approved to push!
>>>>
>>>> -Joe
>>>>
>>>>
>>>>
>>>>         
>>> Done: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/5c6d1b90dc19
>>>
>>> I know I said that was the last one, but it seems another was pushed
>>> recently that I missed (presumably after I finished for the Easter
>>> vacation):
>>>
>>> http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f61d795ce6de
>>>
>>> webrev: http://cr.openjdk.java.net/~andrew/6939845/webrev.01/
>>>
>>> Ok to push?  I know it's still a bit fresh but is #ifdef on ZERO.
>>>
>>>       
>> Approved to go back.
>>
>> -Joe
>>
>>     
>
> Done: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/dd5a19d97c1d
>
> Just waiting on Kelly's reponse now wrt. the HotSpot source/target fix.
>
>
>   

Acknowledged.

I'll send out a separate "last call for b19 changes" message.

Thanks,

-Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20100409/b31934bb/attachment.html