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.
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 attachment 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 step.
Created attachment 17568 [details] exception info
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. ken.frank@sun.com 09/12/2004
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.
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. ken.frank@sun.com
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.
Created attachment 17598 [details] doc on running in other win locales
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 ken.frank@sun.com
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.
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 ken.frank@sun.com
Created attachment 17907 [details] ant run task errors listing
attachment just added can be viewed in wordpad
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. ken.frank@sun.com 10-07-2004
Created attachment 18152 [details] updated instructions for setting up othert locales on en or non asian localized windows
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.
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. ken.frank@sun.com
Created attachment 18171 [details] cleaned up how to setup information for release note
*** Issue 51136 has been marked as a duplicate of this issue. ***
very old issue resolved a long time ago, closing