Test Backports

Fri Apr 9 17:05:01 PDT 2010

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.

Thanks,
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8