RFR of lang level code migration patches

[Paul Sandoz]

On Dec 19, 2013, at 5:44 PM, Brian Goetz <brian.goetz at Oracle.COM> wrote:
> +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.
> 

Well spotted. I guess the reason is performance, since the size constraints are checked before looping there is no need to call hasNext (probably for the second time since next will probably call it :-) ).


On Dec 19, 2013, at 8:22 PM, Mike Duigou <mike.duigou at oracle.com> wrote:
>> Compress catches
>> http://cr.openjdk.java.net/~psandoz/tl/j.u.catch/webrev/
> 
> The comment in JarVerifier "// e.g. sun.security.pkcs.ParsingException" is now probably too broad to be useful. Maybe just remove it.

Done.


On Dec 19, 2013, at 7:33 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> I skimmed over the changes too and they look okay. I'm sometimes wary of IDEs re-arranging things but there's nothing here.

Yes, it is important to verify what the IDE is doing rather, more so for non-diamond-like transformations, as it sometimes gets it wrong and may monkey around with formatting [*].


> It would be good to get a few other areas done too while things are quiet.
> 

Yes. Both NetBeans and IntelliJ have the appropriate refactoring capabilities.

I can take on java.lang.

Paul.

[*] are we ever likely to agree on a single, tool-compatible, code format in the JDK before the heat death of the universe?