RFR of lang level code migration patches

[Brian Goetz]

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