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.
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] screenshot
Created attachment 53700 [details] screenshot
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. ken.frank@sun.com
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. ken.frank@sun.com
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. ken.frank@sun.com
Thank you very much, Ken. -W
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. ken.frank@sun.com
am verifying based on previous comments; Will please reopen if it does not look ok. ken.frank@sun.com
Will, to clarify, this fix is not in 6.0.1 but is in the 6.1 or current trunk builds. ken.frank@sun.com
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: 1.39.6.1; previous revision: 1.39 done Checking in Merger.java; /cvs/uml/codegen/src/org/netbeans/modules/uml/codegen/java/merging/Attic/Merger.java,v <-- Merger.java new revision: 1.19.8.1; previous revision: 1.19 done Checking in UMLParser.java; /cvs/uml/core/src/org/netbeans/modules/uml/core/reverseengineering/parsingfacilities/Attic/UMLParser.java,v <-- UMLParser.java new revision: 1.4.8.1; previous revision: 1.4 done
verified and fixed on NB601 Patch1.