JDK-8011194 : Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 6u51,7u4,7u40,8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • Submitted: 2013-04-01
  • Updated: 2018-08-20
  • Resolved: 2013-08-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8
7u60Fixed 8 b103Fixed
Related Reports
Relates :  
JDK-8011195 - Apps launched via webstart have file.encoding value of US-ASCII on Mac OS X
Relates :  
JDK-7193966 - [macosx] [regresison from Apple's Java 6] non-ascii chars can not be read or displayed, causing files to not load, files not found
Relates :  
JDK-8003228 - (props) sun.jnu.encoding should be set to UTF-8 [macosx]
Relates :  
JDK-8072130 - java/lang/instrument/BootClassPath/BootClassPathTest.sh fails on Mac OSX
Relates :  
JDK-8013831 - non-ascii chars in file can not be read or displayed when doubleclick a jar file
Description
JDK-8003228 fixed a problem on OS X with filenames containing non-ASCII characters.  For instance, such files would not show up in file chooser dialogs under certain circumstances (launching via webstart or double-clicked .jars, or from the Terminal with LANG=C).  Post-8003228, the sun.jnu.encoding property is always set to UTF-8 on Mac OS X.

The problem remains that once the file is loaded, non-ASCII characters *contained* in files do not display correctly.  This is due to the "file.encoding" property being set to US-ASCII for apps launched by double-clicking a .jar file.
Comments
feedback from the CAP member - I could in theory use that workaround myself, but jAlbum is an open framework where 3:rd party developers add plugins and it's not manageable to have all change their code to use an explicit encoding. It's far better to have the bug fixed, isn't it?
03-07-2013
A workaround that an application can use is to explicitly specify an encoding when reading a file, instead of relying on the default encoding. The following change made to the Notepad demo allows it to correctly display the file containing non-ASCII characters when launched via double-clicking the .jar: *** 789,795 **** status.add(progress); status.revalidate(); ! Reader in = new FileReader(f); char[] buff = new char[4096]; int nch; while ((nch = in.read(buff, 0, buff.length)) != -1) { --- 789,798 ---- status.add(progress); status.revalidate(); ! // Ignore the default encoding and specify UTF-8 ! Reader in = new InputStreamReader(new FileInputStream(f), ! java.nio.charset.Charset.forName("UTF-8")); ! char[] buff = new char[4096]; int nch; while ((nch = in.read(buff, 0, buff.length)) != -1) {
02-07-2013
SQE is OK since this functionality never worked
01-07-2013
need SQE-OK for deferring this issue.
28-06-2013
7u40-defer-request justification: This bug should be deferred because making changes to the default file.encoding would be too risky this late in an update release. This bug documents long-standing behavior: it has never been possible for a double-clicked .jar to display non-ASCII characters, even dating back to Apple's JDK6. Care will need to be taken to allow double-clicked .jars to use a file.encoding other than US-ASCII, while maintaining correct behavior for other launch methods & locales. We plan to target a fix for 8, and backport to 7 from there.
27-06-2013
This does not work with Apple's Java either, though the details are a little different. In this case, file.encoding (and sun.jnu.encoding) are set to "MacRoman" ("SJIS" if the default language is Japanese). Files containing Japanese text or umlauts are garbled in Notepad (though differently than under US-ASCII). It doesn't appear that a double-clicked .jar has ever been able to display non-ASCII characters on MacOS X.
25-06-2013
The JDK should pick up the env variable _CF_TEXT_ENCODING and set the encodings based on this. See: http://developer.apple.com/library/mac/#technotes/tn2228/_index.html http://superuser.com/questions/82123/mac-whats-cfusertextencoding-for It is not clear what the encoding should be set to, and it appears this needs to be sorted out, discussing with the Apple developers ? Regardless, this is not a launcher issue, the launcher has no way of knowing whether it was double-clicked launch or launched via java -jar Foo.jar. I am reassigning this issue to core libraries.
18-04-2013
If the problem happened only on English perhaps it is easy to fix, but if the encoding is not set regardless of the user chosen language then what do we set the encoding to ? and how does the Apple's JDK manages to set the correct encoding ? So is the default encoding simply set to UTF-8 regardless on an Apples JDK ?
03-04-2013
The problem happens even when the preferred language is set to something besides English in the Language & Text preferences pane. I tried Japanese & German (plus logged out & back in), but a double-clicked .jar still got a file.encoding of US-ASCII.
03-04-2013
I've attached a copy of the Notepad JFC demo, modified to display the value for the following upon startup: * file.encoding system property * sun.jnu.encoding system property * LANG env var * LC_ALL env var Make sure you have a jre7 or jre8 installed (not Apple's jre6). To reproduce the bug, build the test case, go to NotepadProj/dist/ in the Finder, and double-click on the Notepad.jar file. Use File->Open to open the NonAscii_.txt file. The file will display in Notepad, with '?' characters displayed instead of the proper unicode characters. The app displays the file correctly when launched from Terminal, provided that LANG or LC_ALL is set to something unicode-capable (such as en_US.UTF-8). (Note: the absence of the NonAscii_��.txt file from the list of files in the Notepad file chooser indicates the presence of bug 8003228. This should not happen for jdk8b73 or later).
01-04-2013
JDK-7193966 covered this issue in the context of browser applets.
01-04-2013
I'd probably be dreaming if the solution was to change the default encoding for MacOS to UTF-8.... sigh.
01-04-2013