RFR of lang level code migration patches
Martin Buchholz
martinrb at google.com
Thu Dec 19 16:48:04 UTC 2013
(as always) Please don't modify jsr166 classes (ArrayDeque) here, since
they are maintained upstream in jsr166 CVS. Since jsr166 targets a variety
of java runtimes in general, it tends to be a late adopter of new language
features. Although it's probably time to start using jdk7 features.
On Thu, Dec 19, 2013 at 6:51 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> Hi,
>
> Here are some patches that migrate some code to use more up to date
> language features. I will create a bug later on after feedback.
>
> This is motivated from Brian's patches to lang tools.
>
> I focused just on java.util, minus the concurrent packages, and i used the
> IDE to assist in the code migration. It's easy to pick off other packages
> over time. This makes for more of a low-brow effort [*], perfect when one
> has a cold.
>
> Use <> syntax:
> http://cr.openjdk.java.net/~psandoz/tl/j.u.diamond/webrev/
>
> Replace for with for-each
> http://cr.openjdk.java.net/~psandoz/tl/j.u.foreach/webrev/
>
> Replace while with for-each
> http://cr.openjdk.java.net/~psandoz/tl/j.u.foreach-while/webrev/
>
> Compress catches
> http://cr.openjdk.java.net/~psandoz/tl/j.u.catch/webrev/
>
> Use switch for strings; not sure this one is worth it
> http://cr.openjdk.java.net/~psandoz/tl/j.u.swtich/webrev/
>
> I ran all the j.u. tests locally and there were no regressions. Yet to run
> a JPRT job.
>
> Paul.
>
> [*] although one needs to be vigilant since sometimes the IDE can refactor
> incorrectly and sometimes code is arranged in a certain way for a reason
> (which one reason for leaving j.u.concurrent packages alone for now).
>
More information about the core-libs-dev
mailing list