build: nb6 ml 2007-11-26_17-08-21
#1. create java application
#2. create uml project with "Java Platform Model"
#3. create class diagram and pull a class componet into it, name the class as Chinese characters.
#4. run code generation and
Chinese characters are invalid characters and display grabage in editor after code generation
I will attach the screenshot.
Created attachment 53699 [details]
Created attachment 53700 [details]
Reproducible in ja (EUC) locale on Solaris. Generated source
file is encoded with euc_JP, not UTF-8. Also reproducible on ja
version of Windows XP SP2.
Message from NetBeans on Solaris:
Warning: The encoding 'EUC_JP_Solaris' is not supported by the Java runtime.
In UTF-8 locale, this issue is not observed. I think alias
feature should be used for such cases, but it's irrelevant to
this issue, anyway.
can you tell if it happens when java project encoding property is
the default encoding for zh_CN or ja locale on solaris or windows ?
(or does it happen only using default utf-8 project encoding property which I think is the case here)
using gb2312 project encoding for the java project for solaris zh locale, for example,
I think its ok and it could be that the encoding of the locale is being used during code generation
instead of that of the project encoding (which is utf-8 by default)
for the case where utf-8 locale is used, there is not a problem since encoding of the locale
is utf-8 and thats same encoding of the project as default.
but probably if under utf-8 locale and change project encoding to gb2312, for example,
same situation could happen.
thus some workaround for now might be to change project encoding to that of the encoding of the
locale user is in.
This is a valid bug. CodeGen uses default system encoding instead of the specified target Java project file encoding
(the default is UTF-8). As Ken pointed out, the issue will occur as long as Java project file encoding is different from
system encoding, the workaround is to change Java project file encoding (through properties) to system encoding. The
actual fix is rather simple and straight forward.
adding whiteboard entry so it can be considered for patch1.
The root reason is Codegen and target java project use different encoding.
Ken, do you think we need to write down your workround into nb6 RN or other place to let users know it?
Yes, have already the text for it for rel notes, but forgot to put the keyword here.
Thank you very much, Ken.
restarting Netbeans with -J-Dfile.encoding=utf-8 (or with other
desired target encoding user's java project is set to) would
work as a workaround as well
fixed in trunk and unstable_uml_visualcomponent branch
using an internal trunk build of today, it seems to look ok for this case on solaris:
1. in ja locale, project encoding property is utf-8
2. in ja locale, new project encoding property is euc-jp/
3. in utf-8 ja locale, project encoding property is utf-8
4. in utf-8 ja locale, project encoding property is euc-jp
cases 1 and 4 was where the problem was seen.
have not tried on windows or using Chinese locales.
am verifying based on previous comments; Will please reopen if it does not
to clarify, this fix is not in 6.0.1 but is in the 6.1 or current trunk builds.
The fixes have been ported into the release601_fixes branch.
Checking in JavaCodegen.java;
/cvs/uml/codegen/src/org/netbeans/modules/uml/codegen/java/Attic/JavaCodegen.java,v <-- JavaCodegen.java
new revision: 220.127.116.11; previous revision: 1.39
Checking in Merger.java;
/cvs/uml/codegen/src/org/netbeans/modules/uml/codegen/java/merging/Attic/Merger.java,v <-- Merger.java
new revision: 18.104.22.168; previous revision: 1.19
Checking in UMLParser.java;
new revision: 22.214.171.124; previous revision: 1.4
verified and fixed on NB601 Patch1.