Constants for standard charsets -- CR #4884238
Mike Duigou
mike.duigou at oracle.com
Tue Apr 12 18:27:28 UTC 2011
On Apr 12 2011, at 11:11 , mark.reinhold at oracle.com wrote:
> 2011/4/12 10:38 -0700, mike.duigou at oracle.com:
>> On Apr 12 2011, at 03:33 , Alan Bateman wrote:
>>> ...
>>>
>>> 2. @see Charsets.DEFAULT, I assume this should be @see Charsets#DEFAULT_CHARSET
>>
>> Correct. I changed it to DEFAULT_CHARSET and forgot to fix this link.
>
> Why is forcing people to type Charsets.DEFAULT_CHARSET better than
> Charsets.DEFAULT?
>
> If DEFAULT_CHARSET needs the _CHARSET suffix then don't the other
> constants need that too? Why is DEFAULT special?
The addition of _CHARSET is to encourage static import of Charsets. Unadorned DEFAULT has too much chance of collision. The other defined names shouldn't collide.
>
>>> ...
>>>
>>> I was thinking more about DEFAULT_CHARSET and I'm not sure that we
>>> really need it. In the java.io package then all constructors that take
>>> a Charset also have a constructor that uses the default charset, same
>>> thing in java.lang.String and java.util.zip package. In
>>> javax.tools.JavaCompiler I see that null can be used to select the
>>> default charset. In java.nio.file.Files then we didn't include
>>> versions of readAllLines, newBufferedReader, etc. that didn't take a
>>> Charset parameter.
>
> I tend to agree with Alan that the DEFAULT isn't really necessary.
> There's already a perfectly good method for that, and invoking a method
> rather than referencing a static field makes it harder for developers to
> assume, incorrectly, that it's actually constant across platforms.
A good point. I think consensus is currently leaning towards removing DEFAULT_CHARSET.
Mike
More information about the core-libs-dev
mailing list