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