Fwd: 7050570: (fs) FileSysteProvider fails to initializes if run with file.encoding set to Cp037
Ulf Zibis
Ulf.Zibis at CoSoCo.de
Mon Aug 27 05:46:22 PDT 2012
Am 27.08.2012 14:12, schrieb Alan Bateman:
> On 27/08/2012 12:57, Ulf Zibis wrote:
>>
>> It matters, if sun.jnu.encoding is a double-byte coding.
>> ... and compared to the anyway processed normalizeAndCheck(dir), performance doesn't matter here.
>> :
>>
>> Yes, and additionally I wanted to say, that constant HERE should be initialized double-byte
>> encoding proof.
>>
Hm, before your change, lines using "."getBytes() were double-byte encoding proof, so HERE = { '.' }
is a kind of regression.
> As I said in the original mail, this is beyond the scope of this patch. Yes, we know this is
> kicking the can down the road and maybe some day there will be a locale on one of the supported
> platforms where this becomes an issue. The other point is that sun.jnu.encoding is completely
> internal to JDK, nobody should ever be setting it (same thing goes for file.encoding too but
> clearly people do seem to try that).
Ah, I see.
If you only want to "allow" file.enconding to be set, maybe you could include fix
https://bugs.openjdk.java.net/show_bug.cgi?id=100091
-Ulf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120827/8b7cd2ed/attachment.html
More information about the nio-dev
mailing list