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