Fwd: 7050570: (fs) FileSysteProvider fails to initializes if run with file.encoding set to Cp037
Alan Bateman
Alan.Bateman at oracle.com
Mon Aug 27 09:56:43 PDT 2012
On 27/08/2012 14:09, Ulf Zibis wrote:
>
> 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.
It's only necessary to do the normalization when creating a file-path
from a String that the user (or application) provides. If the file-path
is coming from the operating system, iterating over the contents of a
directory for example, then it's in bytes and also does not require to
be normalized.
I'm not aware of any locales on the supported platforms that would give
us Cp037 as the default charset. The changes here are really just to us
exercise some conformance tests with this encoding (despite the fact
that file.encoding is meant to be a read-only property and should never
be set on the command line).
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120827/e8826a66/attachment.html
More information about the nio-dev
mailing list