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.
Original submitter: mikk Description: The 'Reverse Engineer Operation...' function generates bad parameter names on the diagram for methods called inside the operation. UML always displays parameter names as Unnamed instead of actual names. UML should preserve original names. Parameter names should start from lowcase letters.
See issue 80968 Sequence Diagram: Can't call an operation with the concrete value of parameter
This is not a P1 according to the NetBeans rules. According to netbeans rules, it has to be a sever problem like a loss of data, or crash.
According to UML 2.0 Superstructure Specification the operations should be shown with the parameters' vaues on a Sequence diagram. For example Reverse Engineer of the next operation: --------------------------------------------------- public void op() { System.out.println("Hello World!"); } --------------------------------------------------- should generate 'println("Hello World!")' message between Lifelines instead of 'println(Object unnamed)'.
Created attachment 34695 [details] RE Operation action doe not show parameters' values
http://www.netbeans.org/issues/show_bug.cgi?id=91474 was filed for specific methods calls (with specified parameters, without extra information about visibility etc), In my opinion new issue much more important then initially filed and is a separate issue.
What we show in the diagram is the operation definition. We did not design the code to show the parameter instances. Since this works as designed, I have marked this as an enchanement.
I don't quite agree on your justification that this is an enhancement. Since you said it's not designed to show parameter instances, it should not show parameter as "Object unnamed" which is confused to users. If it's not designed to show parameter instances, nothing should be displayed. Since it's showing "Object unnamed", IMHO, it should show the right thing or nothing at all.
I agree with Peter, Unnamed isn't good here and is addressed in this issue. You justification is good for second issue you have marked as enhancement.
I miss understood the issue. I thought that the issue was wanting the argument value to be displayed. In other words you wanted the string println("Hello World!") to be displayed in the sequence diagram. This is indeed what your issue states. What should happen is that public void println(String s) should so on the message. If this issue want public void println("Hello World!") to be displayed instead, that is an enhancement request. If the issue wnat public void println(String s) to be display, the issue is not an enhancement requrest. Kris is currently working to fix the fact that "unnamed" is being displayed in the parameter name field.
fix for iz 82874. The Library had some class names that were not fully qualified. This may be a different bug. Why is the RE return type=xmi.id in some cases and type=className in others during the same process? Fix consisted of forcing all the class names to be fully qualified in the config/Java16.etd file.
this one about 'Unnamed' and 91474 about println("Hello World!")
The issue is still reproduced. - Reverse Engineer the following method: ------------------------------------------------ void test(){ int a = Math.max( 2, 3); new LinkedList().add(""); } ------------------------------------------------ The max and add methods have unnamed parameters.
Created attachment 38669 [details] Unnamed parameters
There are two different bugs here: first all constant primitives were being converted to their Object types. Changed these back to the primitives (TokenExpressionProxy). Second, all generics in parameters were causing a failure to find the correct method signature. These generics were changed in the config/Libraries/Java16.etc. It is still possible that some types are mapped incorrectly. There is a file in the Library directory, DuplicationMappings.txt, that defines how the non qualified class names were mapped.
Verified in build 070222_1. From the following code, max now no longer has unnamed but add still has unnamed. See attached screenshot. ------------------------------------------------ void test(){ int a = Math.max( 2, 3); new LinkedList().add(""); } ------------------------------------------------
Created attachment 38847 [details] unnamed for add operation
String constants were given the nonqualified name String instead of java.lang.String. Therefore the super classes of String could not be found. In TokenExpressionProxy, the mapping of the type for a string constant was changed from String to java.lang.String
Verified in build 070223_1. From the same code below, add still has Unnamed. See the new attached screenshot. Now instead of "String" for the parameter type, "java.lang.String" is used. What's there ("String") before looks good for the type, just the parameter name should not be 'Unnamed'. ------------------------------------------------ void test(){ int a = Math.max( 2, 3); new LinkedList().add(""); } ------------------------------------------------
Created attachment 38924 [details] screenshot showing Unnamed
The issue is that an import statement for the LinkedList was not added to the source so the code is uncompilable resulting with the issue described for reopening this issue. Once the import statement was added making the code compilable, "Object o" was used instead. Therefore, preventing uncompilable code from being reverse engineered and/or issuing a warning is an issue here and is already being tracked in issue 76310. So, the original issue desscribed has been fixed.
verified