RFR of lang level code migration patches

[Brian Goetz]

+1 on all changes, except perhaps for this one in Collections.copy:

  ListIterator<? super T> di=dest.listIterator();
               ListIterator<? extends T> si=src.listIterator();
               for (int i=0; i<srcSize; i++) {
                   di.next();
                   di.set(si.next());
               }

The code is bizarre enough (calling next based on a range loop rather 
than hasNext()) to leave alone.

On 12/19/2013 9:51 AM, Paul Sandoz 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).
>