Test Backports
Andrew John Hughes
ahughes at redhat.com
Fri Apr 9 06:56:02 PDT 2010
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.
--
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
More information about the jdk6-dev
mailing list