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