On Apr 12 2011, at 03:33 , Alan Bateman wrote:
> Alan Bateman wrote:
>> I see your mail in the archives:
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-April/006487.html
>>
>> but I didn't receive it. I had a similar issue yesterday on another list but
>> I've no idea where the problem is.
>>
>> -Alan
>>
> Just a couple of initial comments on the webrev:
>
> 1. In the standard charsets section of the class description then it might be
> useful to include a reference to Charsets, maybe "The {@link Charsets} class
> defines constants for each of the standard charsets".
OK
>
> 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.
>
> 3. Looks like Charsets is using 2 rather than 4-space indenting.
Ooops, I will correct this.
>
>
> 4. It would be nice to update java.nio.file.Path's class description to
> replace Charset.forName("UTF-8") with Charsets.UTF_8;
I will do so.
> 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 agree that requiring an explicit Charset is best because it makes it clear
what charset is being used. For me this argues though for the DEFAULT_CHARSET
declaration because it's best to be obvious that the default charset is being
used.
I always interpret content being accessed with the default charset in one of
two ways;
- Content that's known to be private that the jvm wrote itself. Useful for
caches because it's assumed that the default charset is the most efficient for
that platform & configuration.
- Content that's potentially uninterpretable because it has an unknown charset
and the default charset is the fallback choice. In recent times I've considered
switching to using UTF-8 for unknown content.
Charset.getDefaultCharset() is possibly just as clear. I personally would use
the constant and use only Charsets constants for accessing content.
> They can be added if needed but there is an argument that you really need to
> know the charset when accessing a text file as it can be too fragile to
> assume the default encoding (esp. with files that are shared between users,
> applications, or machines).
I wouldn't add them. Default charset content should never be shared between
instances (though it frequently is).
When I have used the default charset it's usually been in mime type
declarations for content encoded using the default charset. An example from
JXTA:
private static final MimeMediaType DEFAULT_TEXT_ENCODING = new
MimeMediaType(MimeMediaType.TEXT_DEFAULTENCODING, "charset=\"" +
Charset.defaultCharset().name() + "\"", true)
My goal in adding a DEFAULT_CHARSET constant was to make use of the default
charset more explicit. I definitely don't want to do anything which encourages
inappropriate use of the default charset.
Mike
