Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 77731 - i18n - can't run applet
i18n - can't run applet
Product: java
Classification: Unclassified
Component: Project
All Windows XP
: P2 (vote)
: 6.x
Assigned To: Tomas Zezula
: I18N
Depends on:
  Show dependency treegraph
Reported: 2006-06-12 16:03 UTC by Pavel Rehak
Modified: 2007-11-05 03:49 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT

mentioned exception (5.88 KB, text/plain)
2006-06-12 16:04 UTC, Pavel Rehak

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Rehak 2006-06-12 16:03:07 UTC
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)
Comment 1 Pavel Rehak 2006-06-12 16:04:08 UTC
Created attachment 30978 [details]
mentioned exception
Comment 2 Petr Pisl 2006-06-20 17:43:46 UTC
Should be fixed in 5.5
Comment 3 Petr Pisl 2006-07-10 16:05:25 UTC
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. 
Comment 4 Tomas Zezula 2006-09-12 15:22:01 UTC
The ant is not able to create an process using Runtime.exec(), it seems that the
encoding of the filesystem != encoding of the Can you try if
the following code works:

File f = new File ("The_strange_path");
assert f.canRead () : "File not found";

Comment 5 Tomas Zezula 2007-01-04 09:30:30 UTC
I doubt this is a problem of NetBeans, seems as a problem of the OS setup. But I
need a requested test for evaluation.
Comment 6 Ken Frank 2007-01-04 13:48:18 UTC
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.
Comment 7 Tomas Zezula 2007-01-04 14:11:03 UTC
You have correctly set operating system (filesystem encoding is the same as your
Comment 8 Ken Frank 2007-01-04 14:35:56 UTC
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

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 ?

Comment 9 Ken Frank 2007-01-04 14:45:00 UTC
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.
Comment 10 Ken Frank 2007-01-04 15:10:04 UTC
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.
Comment 11 Jiri Prox 2007-09-12 10:42:34 UTC
Is this issue still valid in 6.0?
Comment 12 Ken Frank 2007-11-05 03:49:07 UTC
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.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo