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

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 
>> nl_langinfo(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