Test Backports

[Joe Darcy]

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?

> [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 :-)

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

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20100408/4fe4bb42/attachment.html