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.
This bug report came from sun's bugtraq #4502475 F4J: 3.0 OS: All Locale: Japanese > >I'm not sure this is valid test case or not but in Ant, when classname >contains Japanese, target "test" can not succeed. > >1. Start F4J in Japanese locale >2. Mount a filesystem >3. Create New > Sample Ant Project under the filesystem >4. Modify *.xml > in target name="test", change "com.foo.Main" to "com.foo.<Japanese>" >5. Create a simple class which contains main() as com.foo.<Japanese> >6. Double click on target "test" > >Output window shows error with garbage > > "java.lang.NoClassDefFoundError:com/foo/?????"
Please include a sample class with a Japanese name and also a matching Ant build script to reproduce this with. Was the XML encoding on the Ant script correctly set to match whatever the text entered in the editor was encoded in?
Created attachment 2767 [details] test.zip
I've attached the sample directory. In xml file, the name for target is written in UTF-8 but the exact filename is Shift_JIS (on Windows). I found com.foo.<classname of japanese> can not run normally when I choose "external" execute mode. We should choose "internal" if classname is japanese. Does this limitation cause this problem? Will Ant test always execute the target class by "external"?
I will try to check this but seeing as I do not have a Japanese-enabled Windows machine I may not be able to reproduce it properly. I am not even sure I could unpack your ZIP file correctly due to the non-ASCII names in it. Perhaps I could try to construct a similar test for e.g. Czech (which uses a non-ISO8859-1 encoding and where I actually know what the different encodings mean and can figure out what is happening). As far as external vs. internal: running the class via F6 from the IDE using External Execution simply forks a Java process and passes it the arguments you specified; I don't know why it would not work (but file a bug somewhere--not in the Ant module--if it does not); Internal Execution runs the class inside the IDE. The Ant module always runs Ant build scripts inside the IDE's VM. However in no case would this behave exactly like Internal Execution (Ant knows about files, not about IDE's Filesystems, which might affect encoding of filenames for all I know). The <java> task as you have it written (fork="true") will fork a fresh VM as requested. It is of course partially the responsibility of the Java process, the operating system, the file system, and various other parts to ensure that they are working on the same encoding. So if you get an error, it may be a bug in any of these things as well as in Ant or in the IDE's integration of Ant. Only bugs in the IDE's integration of the standard Ant libraries are considered for fixing here; otherwise if it is possible to determine what is at fault, an external bug can be filed for that piece of software. I am marking the bug as being Windows-specific because I suspect whatever the problem turns out to be, may be specific to OS.
Sorry, I don't have the equipment to even start to reproduce this. Perhaps Jirka does?
I have investigated it a little bit in Japanese locale and the results are: 1) it is impossible to execute com.foo.<japanese> from command-line $ java com.foo.<Japanese> Exception in thread "main" java.lang.NoClassDefFoundError:com/foo/ 2) from 1) results that executing com.foo.<Japanese> by External executor inside IDE throws the same exception 3) if there is "fork=true" in an ant file then the class is executed by new java proccess (like external executor) and NoClassDefFoundError is thrown 4) It is possible to execute com.foo.<Japanese> by Internal executor inside IDE In my opinion it is not a bug of IDE. Tested on Solaris (ja_euc), JDK1.3.1, build 011001_3_CE_JA.
OK, I guess this is the best we can do... I am assuming that the operating system is unable to pass non-8-bit characters correctly on the command line. At least Solaris JA, but it sounds like your (Masaki's) experiences match this on Windows JA. Besides using internal execution, it might help to package the classes in a JAR and run that, rather than running unpacked classes. As far as I know the JAR format defines the encoding for filenames inside it (UTF8 I think, but not sure). If this is true, then the Japanese class files could be kept inside the JAR. This leaves open some vulnerabilities: 1. You would have to be able to hold the Japanese .class files on disk long enough to JAR them. Hopefully Japanese Windows at least supports this. I believe plain Windows does not (using java.io.File at least). 2. You have to JAR them safely. Using Ant's <jar> task ought to work, I think, since it runs no external commands. (Cannot test this--I don't believe Linux supports non-8-bit filenames, or at least not my setup.) 3. If you main class has a 7-bit name, this would help. Otherwise you cannot pass the main class name on the command line (as with the current problem); you would want to pass it in the Main-Class attribute in the manifest, but it is a known and open Java bug that non-7-bit characters are not supported in manifests. Frankly I would not recommend using class names with Japanese characters at all given these problems (method names etc. should be fine, and of course Romanized names), but if it is necessary then it should be possible with these caveats. Please reopen if more information comes up that would help.
Consistent use of the I18N keyword.
Resolved for 3.3.x or earlier, no new info since then -> closing.