On Dec 19, 2013, at 5:44 PM, Brian Goetz <brian.go...@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.dui...@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.bate...@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?
