Use JDK7 and JDK8 Code Features

[dbwiddis]

Used IDE cleanup tool with manual reverting of the anonymous inner class fixes to apply the following (each in a separate commit for ease of review or if you only want a portion of the changes):

• Diamond Operators
• Try-with-resources
• Try-multi-catch
• Constants in preference to system properties

[matthiasblaesing]

You found a whole lot of diamonds ;-)

Thanks for preparing this. I left two inline comments, that might make sense.

[matthiasblaesing]

Not sure here, but the display name, that is even localized, seems wrong. The canonical name of the charset seems to be a better fit:

Suggested change

	final String encoding = Charset.defaultCharset().displayName();
	final String encoding = Charset.defaultCharset().name();

Same would apply in line 228

[matthiasblaesing]

See comment in DirectTest (same on line 480)

[dbwiddis]

You found a whole lot of diamonds ;-)

To be fair, Eclipse found them, plus a few others that it shouldn't have. The "Clean Up" tool made this easy.

I left two inline comments, that might make sense.

The suggestion was Eclipse's. Given Eclipse's failure with the diamonds on anonymous subclasses, I trust it less now, so looking into this.

• The file.encoding system property is accessible via the constant jdk.internal.util.StaticProperty.fileEncoding() but that's internal.
• That method is called in Charset.defaultCharset() as the argument to charsetForName()
• There the argument is canonicalized when looking up the actual charset (so it could be an alias) so the actual file encoding String is lost. But the Charset name field is populated with the canonical name
• Both name() and displayName() with no arguments return the name field without considering locale, so your suggestion makes no difference in the default case, but...
• Both of those methods can be overridden by subclasses as well, and the javadoc for displayName() indicates it's intended to be "human readable" so is probably not the best. name() returns the canonical name.

So it looks like your suggestion is a good one, although in theory if someone had a "human readable" file.encoding it might be closer to the truth. Perhaps that's what Eclipse's devs were thinking.

I'll update to your suggestion. It's in a test class anyway so not critical, worst case is a failed test someone has to debug.

[dbwiddis]

Will follow up with a similar PR for platform tonight.