Paul deliberately stayed away from the JUC classes. Can we get a
definitive list of non-JUC classes that primarily live in the JSR166 CVS?
On 12/19/2013 11:48 AM, Martin Buchholz wrote:
(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.san...@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).
