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.

Bug 78363 - I18N - Reverse Engineering does not work for a java file with 2-byte name.
Summary: I18N - Reverse Engineering does not work for a java file with 2-byte name.
Status: VERIFIED DUPLICATE of bug 80927
Alias: None
Product: uml
Classification: Unclassified
Component: Reverse Engineering (show other bugs)
Version: 5.x
Hardware: Sun All
: P2 blocker (vote)
Assignee: Viktor Lapitski
URL:
Keywords: I18N, RELNOTE
Depends on:
Blocks:
 
Reported: 2006-06-19 22:25 UTC by Ken Frank
Modified: 2008-03-27 01:18 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
image (14.65 KB, image/gif)
2006-06-19 22:27 UTC, Ken Frank
Details
image of how it looks in coco (62.01 KB, image/gif)
2006-11-13 18:17 UTC, Ken Frank
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Frank 2006-06-19 22:25:07 UTC
hen executing "Update Model from Source" for a java file with 2 byte name,
the "Reverse Engineering" dialog shows errors.
Please see the attached.
The dialog says the name is unexpected.
As the result, a Class diagram is not generated in a UML project.

Please do not say do not use 2 byte chars for Class name.
Java specification allows 2 byte to use for any identifiers.

This happens even if file name does not have mbyte, but other
parts of the file, like a function name, has multibyte in it.
Error msg shown is similar to one in gif, although  the hex character
it says is unexpected will vary.

Java does allow mbyte to be in java file name, function/method/etc
names.
Comment 1 Ken Frank 2006-06-19 22:27:16 UTC
Created attachment 31181 [details]
image
Comment 2 Ken Frank 2006-06-19 22:28:33 UTC
recent comment from Sergey on this:

addition of attribute with non-ascii character in name leads to absent of entire
class element in model.

ken.frank@sun.com
Comment 3 Trey Spiva 2006-07-10 22:36:52 UTC
This problem is now fixed.  Since we are using the javac parser, we are now able
to determine if the name of the namespace is a class or a package.  So, we are
doing the correct thing.

The fix in currently in a unstable branch.  When the unstable branch is merged
into the the release55 branch I will close this issue.
Comment 4 Ken Frank 2006-08-30 19:07:13 UTC
Trey,

can you merge this now ? We'd like to verify it but in regular entpack build.

Sasha, can you track this and verify when its in build ?

ken.frank@sun.com
Comment 5 Ken Frank 2006-11-04 01:35:50 UTC
please merge this fix now into coco_griffin or whatever the branch is for
coco and then for griffin also.  Needed for coco release.

ken.frank@sun.com
Comment 6 Trey Spiva 2006-11-06 13:39:31 UTC
We had to stop the MDR work.  So, this work did not make it into the release. 
IZ does not let me mark this issue as not being started.
Comment 7 Ken Frank 2006-11-13 18:17:59 UTC
Created attachment 36020 [details]
image of how it looks in coco
Comment 8 Ken Frank 2006-11-13 18:21:50 UTC
attached is image of how this looks in coco.

To clarify, this means that if a java file has function or variable or name that
does not have ascii characters, that reverse engineering will not happen at all.

If this will not be fixed, can info be put in release notes, with workaround
that users would need to
add the items to the diagram directly as well as adding them to their code ?

ken.frank@sun.com
Comment 9 Trey Spiva 2006-11-16 18:34:29 UTC
We where not able to complete the new reverse engineering component :-(
Comment 10 Viktor Lapitski 2007-02-12 03:55:34 UTC
looks like a dup of 80927. Intend to close it as such.
Comment 11 Viktor Lapitski 2007-02-16 02:31:23 UTC

*** This issue has been marked as a duplicate of 80927 ***
Comment 12 Peter Lam 2008-03-27 01:18:12 UTC
Since this is a duplicate of issue 80927 that has already been verified, this dup should have been verified as well.