Fwd: 7050570: (fs) FileSysteProvider fails to initializes if run with file.encoding set to Cp037 (original) (raw)

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