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.

Will follow up with a similar PR for platform tonight.