Bug 123102 - I18N - Chinese characters display grabage in code generation
I18N - Chinese characters display grabage in code generation
Status: VERIFIED FIXED
Product: uml
Classification: Unclassified
Component: Code Generation
6.x
Sun Windows XP
: P2 (vote)
: 6.x
Assigned To: Viktor Lapitski
issues@uml
release601_fixes_candidate1, release6...
: I18N, RELNOTE
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-30 05:10 UTC by Will Zhang
Modified: 2008-02-26 12:09 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
screenshot (149.02 KB, text/plain)
2007-11-30 05:11 UTC, Will Zhang
Details
screenshot (149.02 KB, image/jpeg)
2007-11-30 05:11 UTC, Will Zhang
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Will Zhang 2007-11-30 05:10:53 UTC
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.
Comment 1 Will Zhang 2007-11-30 05:11:27 UTC
Created attachment 53699 [details]
screenshot
Comment 2 Will Zhang 2007-11-30 05:11:55 UTC
Created attachment 53700 [details]
screenshot
Comment 3 Ashizawa Kazunori 2007-11-30 06:29:36 UTC
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.
Comment 4 Ken Frank 2007-11-30 18:57:57 UTC
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

Comment 5 Yang Su 2007-11-30 20:49:11 UTC
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.



Comment 6 Ken Frank 2007-12-01 00:33:19 UTC
adding whiteboard entry so it can be considered for patch1.

ken.frank@sun.com
Comment 7 Will Zhang 2007-12-03 06:18:09 UTC
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? 
Comment 8 Ken Frank 2007-12-03 15:38:01 UTC
Yes, have already the text for it for rel notes, but forgot to put the keyword here.

ken.frank@sun.com
Comment 9 Will Zhang 2007-12-04 03:18:04 UTC
Thank you very much, Ken.

-W
Comment 10 Viktor Lapitski 2007-12-04 23:20:01 UTC
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
Comment 11 Viktor Lapitski 2007-12-05 00:40:14 UTC
fixed in trunk and unstable_uml_visualcomponent branch
Comment 12 Ken Frank 2007-12-06 02:01:53 UTC
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
Comment 13 Ken Frank 2008-01-24 02:42:10 UTC
am verifying based on previous comments; Will please reopen if it does not
look ok.

ken.frank@sun.com
Comment 14 Ken Frank 2008-01-24 17:47:39 UTC
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
Comment 15 khu 2008-02-09 00:12:06 UTC
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
Comment 16 Will Zhang 2008-02-26 12:09:56 UTC
verified and fixed on NB601 Patch1.


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