file.encoding vs. sun.jnu.encoding(?) on OS X (original) (raw)

Paul Taylor paul_t100 at fastmail.fm
Thu Nov 22 12:10:15 PST 2012

On 09/11/2012 13:12, Alan Bateman wrote:

On 08/11/2012 19:25, Scott Kovatch wrote:

Hello,

I want to bring up something that is causing a lot of confusion, and is generating a lot of bugs on OS X. What is the relationship between path names and file.encoding? Or, maybe more correctly, why is there some relationship between path names and file.encoding? On OS X filenames are ALWAYS in UTF-8, so the current locale should never come into play. I was about to launch into a discussion (rant) about our use of nllanginfo(CODESET) for file.encoding, but the more I look into it, I don't think that's the problem, though you can also make a case that all text files on OS X are UTF-8 by default as well. I'm wondering if this has something to do with sun.jnu.encoding being set to the same value as file.encoding. -- Scott K. I've seen several mails on macosx-port-dev about this, although I think several issues have been conflated which makes for confusing reading. One of the issues is that HFS normalizes to a variant of NFD and the changes that came via the Mac port weren't right. Sherman has re-implemented this via 7130915 in jdk8 and it has been back-ported to 7u for 7u12. We've had confirmation from several people that this resolves the issues that they were seeing. The other issue, and I think the issue that you are trying to get at, is that sun.jnu.encoding is being set based on the locale whereas you are saying that it should always be UTF-8 on Mac. I think we need to create a bug on that and it would be great if you can get technical references so that we know this is the right thing to do. There are at least two places in the property initialization that would need to be updated to do this. I don't think we should change file.encoding as that would change the default encoding for the file contents whereas the issues all seem to related to the encoding/decoding of file names. The final issue is just consistent use of sun.jnu.encoding. This property was originally only used for Windows but now we have cases where it may different to file.encoding on other platforms. Sherman brought up 7050570, which is addressing something different again but part of it does fix up the new file system API to use sun.jnu.encoding. I haven't seen any mails on macosx-port-dev that look like this issue but we should get it in anyway (Sherman - you ask why I hadn't pushed that several months ago, sorry, it's been on my list as a low priority item and low priority items have been starved of cycles). -Alan. Just tried the latest ea release

macbook:songkong paul$ java -version java version "1.7.0_12-ea" Java(TM) SE Runtime Environment (build 1.7.0_12-ea-b02) Java HotSpot(TM) 64-Bit Server VM (build 24.0-b25, mixed mode)

and Im still getting a problem that files containing certain chars are not failing file.exists();

Is this the issue discussed that is meant to be fixed in 7u12 ?

This is the one bug in the Java 7 port that I need to resolve one way or the other before I can release my software so Id appreciate a definitive reply to this.

Also do you have an eta for when 7u10 final , and 7u12 final will be available ?

Paul

More information about the macosx-port-dev mailing list