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 06:09:27 PDT 2012


Am 27.08.2012 14:43, schrieb Alan Bateman:
> On 27/08/2012 12:57, Ulf Zibis wrote:
>> :
>>
>> I still do not see any reasonable why this UnixFileSystem-API is partly processing chars vs. bytes.
>> E.G compare UnixPath.normalize(...) vs. UnixPath.initOffsets().
> This is the initialization of the file system and so is somewhat special, it basically needs the 
> default directory so that it can compare it it to the working directory of the process. The 
> syscall for the later give it to us in bytes. You are right that the absolute path check could be 
> done with chars but I don't think it makes any difference unless there are wider changes to 
> support multi-byte encodings.

Yes, you are right, there should be more changes to support multi-byte encodings.

My first assumption was, that Cp037 is a multi-byte charset, as you referred to [1] which is about 
UTF-16, and you wanted to support this.

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-July/010758.html

Other arguments had been, that processing bytes would perform better than chars, so I was wondering 
why of all things UnixPath.normalize() processes on chars, as it should run on every new file path 
being opened.

-Ulf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120827/18bbf211/attachment-0001.html 


More information about the nio-dev mailing list