This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 225743 - InvalidPathException on OS X for non-ascii file paths
Summary: InvalidPathException on OS X for non-ascii file paths
Status: RESOLVED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: JDK Problems (show other bugs)
Version: 7.1
Hardware: Macintosh (x86) Mac OS X
: P3 normal (vote)
Assignee: Tomas Zezula
URL: http://bugs.sun.com/bugdatabase/view_...
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-05 10:17 UTC by sworisbreathing
Modified: 2013-02-13 10:58 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Minimal test case (3.43 KB, application/zip)
2013-02-05 10:17 UTC, sworisbreathing
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sworisbreathing 2013-02-05 10:17:30 UTC
Created attachment 131033 [details]
Minimal test case

The attached project demonstrates an issue which prevents projects from working correctly when they attempt to handle file paths that contain non-ascii characters on some platforms

The project builds from the command line when I run `mvn clean install` but not when I build it from within the IDE.  And I only appear to have the problem on OS X.

The attached project includes two test methods: testAsciiPath() and testNonAsciiPath().  Both tests pass when run from the command line.  However,  testNonAsciiPath() throws an exception when run from NetBeans, which appears similar to the following in the output window:
java.nio.file.InvalidPathException: Malformed input or input contains unmappable chacraters: /var/folders/z0/nxkmx1854c52_jx6t_gyl5sh0000gn/T/junit1868257566787511103/testNonAsciiPath/test?eb
	at sun.nio.fs.UnixPath.encode(UnixPath.java:147)
	at sun.nio.fs.UnixPath.<init>(UnixPath.java:71)
	at sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:281)
	at java.io.File.toPath(File.java:2069)

The non-ascii path should not be a question mark.  In the test code it's an `a with grave accent` character (\u00e0) and when run from Terminal using `mvn clean test`,  is output correctly as:
/var/folders/z0/nxkmx1854c52_jx6t_gyl5sh0000gn/T/junit1868257566787511103/testNonAsciiPath/testàeb

Additional information (since this appears to be a platform-specific issue):

Operating System: Mac OS 10.7.4 build 11E53

java -version output:
java version "1.7.0_10"
Java(TM) SE Runtime Environment (build 1.7.0_10-b18)
Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)

mvn --version output:
Apache Maven 3.0.3 (r1075438; 2011-03-01 04:31:09+1100)
Maven home: /usr/share/maven
Java version: 1.7.0_10, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.7.4", arch: "x86_64", family: "mac"

NetBeans about dialog info:
Product Version: NetBeans IDE 7.1 (Build 201112071828)
Java: 1.7.0_10; Java HotSpot(TM) 64-Bit Server VM 23.6-b04
System: Mac OS X version 10.7.4 running on x86_64; UTF-8; en_US (nb)
User directory: /Users/Steveo/.netbeans/7.1
Cache directory: /Users/Steveo/.netbeans/7.1/var/cache

Important stuff from netbeans.conf:
netbeans_default_options="-J-Dcom.sun.mysql.startcommand=/usr/local/mysql/support-files/mysql-admin.server -J-Dcom.sun.mysql.stopcommand=/usr/local/mysql/support-files/mysql-admin.server -J-Dcom.sun.mysql.startargs=start -J-Dcom.sun.mysql.stopargs=stop -J-Dcom.sun.mysql.port=3306 -J-client -J-Xss2m -J-Xms32m -J-XX:PermSize=32m -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true -J-Dsun.zip.disableMemoryMapping=true -J-Dfile.encoding=UTF-8"
netbeans_jdkhome="/Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/"

In case anyone is wondering, NetBeans is configured to use Maven in /usr/share/maven.  It's a moot point, however - the issue remains the same when I switch NetBeans to its bundled version of Maven (3.0.4) and also when I copy the test code into a non-maven project.

Also, the problem persists even when I remove "-J-Dfile.encoding=UTF-8" from netbeans_default_options (this was an attempted workaround that didn't work).
Comment 1 Tomas Zezula 2013-02-05 10:35:29 UTC
See issue #222569 or http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003228.
Adding -J-Dsun.jnu.encoding=UTF-8 to netbeans.conf will solve the problem if the FS is set to use UTF-8 rather than MacRoman.

*** This bug has been marked as a duplicate of bug 222569 ***
Comment 2 sworisbreathing 2013-02-05 11:40:13 UTC
The problem persists after adding -J-Dsun.jnu.encoding=UTF-8 to netbeans_default_options in netbeans.conf

I've tried everything I know to do to make everything the same between the command line and NetBeans.  Since the issue only manifests itself when running from NetBeans and not from Terminal, I'm convinced the problem is on NetBeans' end.
Comment 3 Tomas Zezula 2013-02-12 12:22:21 UTC
>Since the issue only manifests itself when running
>from NetBeans and not from Terminal, I'm convinced the problem is on NetBeans'
>end.
No it's a JDK issue http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003228 and also partially also Apple issue (the  LC_CTYPE is not set by default).
The behaviour in terminal depends on the Tarminal.app preferences.
When the Terminal export LC_CTYPE set to UTF-8 it works fine in terminal as the sun.jnu.encoding is set to the value of LC_CTYPE. When it's not set it does not work. The problem with setting the sun.jnu.encoding is that it may be overwritten by the JDK, so it's safer to export the LC_CTYPE=UTF-8.
Rather then addding -J-Dsun.jnu.encoding=UTF-8 to netbeans.conf prepend the export LC_CTYPE=UTF-8 to it.
Comment 4 sworisbreathing 2013-02-13 10:58:57 UTC
Thanks, Tomas.  I've removed -J-Dsun.jnu.encoding=UTF-8 from netbeans_default_options and added the following as the first line of netbeans.conf:

export LC_CTYPE=UTF-8

The test case now passes :-)