Bug 48902 - I18N - project name with multibyte does not run
I18N - project name with multibyte does not run
Product: projects
Classification: Unclassified
Component: Generic Infrastructure
PC Windows ME/2000
: P2 (vote)
: 4.x
Assigned To: Milan Kubec
: 51136 (view as bug list)
Depends on:
Blocks: 51382
  Show dependency treegraph
Reported: 2004-09-12 21:50 UTC by Ken Frank
Modified: 2005-12-22 14:32 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT

exception info (7.75 KB, text/plain)
2004-09-12 21:53 UTC, Ken Frank
doc on running in other win locales (5.74 KB, text/plain)
2004-09-13 23:08 UTC, Ken Frank
ant run task errors listing (4.75 KB, text/plain)
2004-09-28 21:31 UTC, Ken Frank
updated instructions for setting up othert locales on en or non asian localized windows (7.31 KB, text/plain)
2004-10-08 04:35 UTC, Ken Frank
cleaned up how to setup information for release note (6.95 KB, text/plain)
2004-10-08 17:46 UTC, Ken Frank

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Frank 2004-09-12 21:50:01 UTC
create a project with multibyte in name

run the project - get an error in output window 
with exception trace - see attachment

also, in the way the project is viewing the 
name of this project, when trying to build it,
it shows the multibyte correctly sometimes
and as garbage ascii at othertimes - see 
with text from output window -- so seems like
encoding handling issue - whether that is full
cause of the trace/exception, I don't know.

Happened to me with java project / main class
and web project/ simple jsp, so am assuming its
general to all project types

(The main class i used did not have multibyte
in its name, to be sure, and another project,
without multibyte in its name, but with a java
class with multibyte in its name, did run)

The clean and build step works, but not the run
Comment 1 Ken Frank 2004-09-12 21:53:35 UTC
Created attachment 17568 [details]
exception info
Comment 2 Ken Frank 2004-09-12 22:57:49 UTC
this also means that sample projects cant run -- since
the name of some sample project, like JSTL Examples, is hardcoded
or readonly in the wizard, and since this will have multibyte when
translated, then as it is, these sample projects cant run, since their
names can't be changed.

If a separate issue is needed about allowing the project name to be
edited (unless there is someplace already I didnt see), let me know,
but assumption is that multibyte in project name should be ok, if 
not, then the labels for these sample projects need to have
#NOI18N comments.
Comment 3 Jesse Glick 2004-09-13 16:37:08 UTC
Probably need more debugging on your side. Best to have a complete
example that can be shown to break on several platforms (Windows,
Linux) or just on one platform (Windows) but work on another (Linux).
Better to have a more easily interpreted encoding as a test case (i.e.
something that makes the log files readable to developers!). Need to
check with system encoding set to UTF-8. Need to check whether the
project builds using command-line Ant or not. Need to include output
using Ant -verbose (or Verbose in Options dialog when inside IDE).
Need to check against JDK 1.5.

In particular, I just created a project on my Fedora Core 2 machine
(Linux, UTF-8) using JDK 1.5 named "čau" (that's a 'c' with reverse
circumflex - a Czech character not present in e.g. ISO-8859-1), with
the same word in the package name of the main class, and printing that
word to standard output; ran it, and everything worked just fine.

So whatever the problem you're having is, it is very likely specific
to a given platform, perhaps a particular JDK, probably a particular
system encoding. You need to track this down further so we can figure
out whether the problem lies in the operating system, in the JDK, in
Ant, or in NetBeans.
Comment 4 Ken Frank 2004-09-13 20:47:06 UTC
I will provide additional information on another platform but
dont think its needed to do all you say - think that could also
be viewed as what would be done when analyzing the issue.

I'm seeing behavior in the product doing a certain thing and think,
regardless of what other related issues, that its an issue that is 
seen and valid in itself.  I'm not operating at the ant level nor
checking ant - I'm operating the ide.

If you feel its still incomplete, then I guess that is up to you
not to look at it or fix it, but it still seems like its an issue

I did the following
A. platforms/locales

zh locale on en xp - locale set to simp zh, using pseudo localized -
saw the issue - using multibyte of that locale

ja locale on en xp - no pseudo localized bits - using multibyte in
name of java, web or mobile project - similar issue although the
target location in build-xml that is shown as initial trace of error
is different due to different steps in building of different projects
(using multibyte of that locale)

solaris 9 - zh locale - with pseudo localized - problem not seen

so this could be why you didnt see it

but also, about multibyte vs extended ascii - sometimes issues
have been seen with multibyte that were not seen with extended ascii.

B. ant from cmd line - puttting the ant in nb4 in the path on windows

cd to projdir with non multibyte name
ant -f .\build.xml run
no errors

cd to projdir with multibyte in name
ant -f .\build.xml run

got java io file not found error msg but dont think its related - it 
just said that the
file or dir name not found - but that could be that dos window is not
viewing the multibyte properly -- since when in ide, I can do 
clean and build of project with multibyte, just not the run step.
Comment 5 Jesse Glick 2004-09-13 20:57:52 UTC
I'm sure it's a valid issue; my point is that there is no chance it
can be solved on development side until there is some clear list of
platforms, encodings, JDKs, etc. that it is known to occur on, so that
someone with access to a lab machine matching those specifications can
narrow down the problem. Maybe Milan knows who can do that. I
certainly can't do anything to help without some idea where the
problem lies, since I have little chance of reproducing the problem on
my own machine.
Comment 6 Ken Frank 2004-09-13 23:08:23 UTC
Created attachment 17598 [details]
doc on running in other win locales
Comment 7 Ken Frank 2004-09-13 23:10:45 UTC
looks like iz didnt update my previous comments

I think what has been descirbed is sufficient for someone to see if
the issue at least exists

i attached doc on how to run in other locales (and get multibyte)
fonts for en xp. for solaris, a servicedesk request to ilm or
ens, depending on if office or lab machine, can get solaris asian
locales and fonts installed

Comment 8 Jesse Glick 2004-09-13 23:30:48 UTC
Certainly suspicious if you can't even run the Ant script from the
command prompt; sounds like an OS problem to me, perhaps. As I say,
AFAIK everything works perfectly fine on Linux using UTF-8 uniformly,
but perhaps other OSs are defective in their treatment of file name
encodings. Or it may be just certain encodings that cause breakage. I
imagine some OS/JDK/encoding combinations just make it unreliable to
use non-ASCII characters in file names, which may or may not be
something we can do anything about - TBD.

Re. names of sample projects - well the "Standard" sample app, Anagram
Game, lets you pick a folder name. Seems the web samples don't. Feel
free to file a bug report for that (web/project). In the meantime, I
would strongly recommend that translaters choose a non-ASCII name for
the fixed folder name for these samples.
Comment 9 Ken Frank 2004-09-28 21:30:43 UTC
some additional information

1. does not happen on ja windows - can give project name and java
main class name with multibyte and it runs ok
(so am assuming ant is ok here too)

but on en xp set to asian locale, see problems described here -

-- I'm wondering if its that encoding is being viewed as different
on en xp set to asian locale, either by ide or xp or ant -- so the
run step chokes.

-- What is different about the ant run step vs the other project
build and compile steps in context of how it might view the 
multibyte ? (since the compile steps work ok)

attached is output window errors trace, maybe there is clue there ?

could it be that error only happens after ant is done and in some
java or other exec process ?

Thanks for any suggestions

Comment 10 Ken Frank 2004-09-28 21:31:47 UTC
Created attachment 17907 [details]
ant run task errors listing
Comment 11 Ken Frank 2004-09-28 21:33:30 UTC
attachment just added can be viewed in wordpad
Comment 12 Ken Frank 2004-10-08 04:33:30 UTC
Will add to release notes the need for user of some non localized
windows, who wants to use another locale, especially one that uses
multibyte charaters, to do the additional steps needed, in regional
settings, to make sure hat external or non unicode processes view the
locale as that which is set. It's not enough, for the case mentioned
in this issue, just to set the regional settings basically to some
other locale, since this situation relates to how external processes
handle the data sent by the ide.

regional setttings steps, using chinese prc as example
 control panel->regional settings - has several tabs

1) general tab - your locale - choose Chinese PRC

2) input locales tab - choose Add ...

3) in popup choose Chinese PRC as locale and
Chinese (simplified - Zheng Ma
as the Keyboard layout/IME
4a) additional important step for w2000

on first tab, choose set default in lower left under
language settings for the system

in the popup "Select System Locale, choose the same locale as was ch
osen at the
top of the first tab under your locale

4b) Additional important step for xp -
choose the advanced tab of the regional settings and then
Language for non-Unicode programs section popup -
choose the very same locale/lang you chose in step 1)

5) choose ok for all dialogs and reboot

I've put amended windows.usingasian locales as attachement again.


Comment 13 Ken Frank 2004-10-08 04:35:45 UTC
Created attachment 18152 [details]
updated instructions for setting up othert locales on en or non asian localized windows
Comment 14 Jesse Glick 2004-10-08 16:27:03 UTC
Ken perhaps you could clean up the note to not refer to Sun-internal
URLs or processes, so we could use it in our general release notes, if
that is appropriate.

Is there no way to just convince Windows to assume UTF-8 as the
encoding for everything? That would at least solve this immediate
issue, which seems to be disagreement between various components over
which encoding to use. Default locale for display of apps, default KB
entry mode, etc. ought to be separate considerations, right? At least
it works fine this way on Linux. Oh well.
Comment 15 Ken Frank 2004-10-08 17:44:36 UTC
I will clean up the note and reattach as relnote.windows.usingasianlocales

From what I've seen, it doesn seem like windows can be told to use
utf-8 as encoding for all things, but needs these separate regional
settings; I think part of it might be that there are still some parts
of windows that donot/cannot use utf-8 (or unicode in general by default
so that the additonal step is needed to somehow tell them what
locale/encoding is being used when sent data from other programs.

Comment 16 Ken Frank 2004-10-08 17:46:14 UTC
Created attachment 18171 [details]
cleaned up how to setup information for release note
Comment 17 David Konecny 2004-11-04 16:26:12 UTC
*** Issue 51136 has been marked as a duplicate of this issue. ***
Comment 18 Marian Mirilovic 2005-12-22 14:32:03 UTC
very old issue resolved a long time ago, closing

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