RFR: refactorings for Java 5 and 7 features

[Remi Forax]

On 12/17/2013 07:13 PM, Brian Goetz wrote:
>> 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.

I think it's better to simplify the code here,
instead of doing the boxing when doing the convertion String to float
using Float.valueOf(String), it's better to use Float.parseFloat() 
instead and
do the boxing only when calling Literal.

Rémi