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.
Product Version = NetBeans 5.5 Dev (Build 200606090200) Operating System = Windows XP version 5.1 running on x86 Java; VM; Vendor; Home = 1.5.0_07; Java HotSpot(TM) Client VM 1.5.0_07-b02; Sun Microsystems Inc.; F:\Java\jdk1.5.0_07\jre System Locale; Encoding = ja_JP (nb); MS932 --- I've created applet in jappanise localized nb (multi-byte in package name and in applet name as well) and i can't invoke "run file" on it -> throws exception (see attachment) (it works fine with applet's without multi-byte characters in its name)
Created attachment 30978 [details] mentioned exception
Should be fixed in 5.5
The problem is not in the Applet viewer. The problem is in the name of the project. When you create a java project with multi-byte characters, then you can not run this project with the same exception. I think that the main reason is composing value of -classpath parameter. I'm able to reproduce this on WinXP and if in the name of project are Czech chars. I'm not able to reproduce on Linux. So I'm reassigning this issue to the java module.
The ant is not able to create an process using Runtime.exec(), it seems that the encoding of the filesystem != encoding of the project.properties. Can you try if the following code works: File f = new File ("The_strange_path"); assert f.canRead () : "File not found";
I doubt this is a problem of NetBeans, seems as a problem of the OS setup. But I need a requested test for evaluation.
I used a recent nb6 and have multibyte in name of applet, of package name and am running nb in ja locale - I created an applet from file->new of a java project and also created one in gui designer using awt->applet form. I can run both of these ok, and applet viewer appears. I have not set any project properties to indicate encoding value. Not sure if this is problem in 5.5 or if am executing the same steps as in original issue, but these are my observations. ken.frank@sun.com
You have correctly set operating system (filesystem encoding is the same as your encoding).
Using nb551 and using jdk6, I see this or at least related problem in that having java project name with multibyte in it, and then run the project, it wont build it giving output window error of build.xml cant find build-impl.xml in the package dir. (which also has mbyte) and using a recent jdk6 vs the one used in previous comment, the same problem happens. In the past this kind of simple situation has always worked as to using multibyte project/package name with a java project; it compiled and ran ok, with no need to set any kind of compiler properties as to encoding, which should not be required in any case. Perhaps this needs to be filed as a separate issue ? ken.frank@sun.com
I am in ja locale on solaris when running nb thus seems like no special encoding would need to be set in the file props or project props but even when do so, to eucJP-open as is stated in messages.log, the problem in ow described below happens. ken.frank@sun.com
what I am seeing is 83712; thanks Jiri for pointing this out and that is not related to this issue; sorry for the confusion here. ken.frank@sun.com
Is this issue still valid in 6.0?
seems to be ok; am resolving as works for me; using nb6 latest, in both default utf-8 project encoding as well as euc-jp encoding; am running nb in ja solaris locale. ken.frank@sun.com