RFR: refactorings for Java 5 and 7 features

[Brian Goetz]

> The refactoring is fine, but this whole method can probably be replaced
> by a line or two of cod using the nio.2 API from JDK 7, perhaps an
> adaptation to one of the methods in java.nio.file.Files.

Yes, there are many such patterns that could benefit from library 
changes.  In addition to the obvious use of streams, the new methods on 
Map can help a lot.  For example:

   Foo f = map.get(k);
   if (f == null) {
       f = new Foo();
       map.put(k, f);
   }

can be collapsed into

   Foo f = map.computeIfAbsent(k, k -> new Foo());

I noticed this pattern many dozens of times as I walked through the code.

> Some of the changes involve rely on implicit boxing or unboxing, like
> below:

I considered explicit boxing-via-constructor (where we used "new 
Long(n)" rather than Long.valueOf(n)) to be a bug, so I replaced these 
with autoboxing.  There were a few unboxings that were safe and more 
readable that I converted opportunistically, but didn't go nuts on these 
since this is just syntactic sugar and doesn't actually change the 
bytecode.

> I'm a bit cautious towards these changes, not being fully certain
> off-hand of all the boxing vs unboxing priorities and the hazard of an
> == being done on objects rather than a equals comparison of values.

FWIW these were done with IJ's automated refactors, which suggests that 
the semantics of the transforms have been reasonably vetted.