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.
UML is not adapted to the Java style of programmation. And then, reverse engineering (RE) too. Suppose I have a JavaBean with 10 fields. With associated getters/setters, 10 getters and 10 setters. When I do the RE, I have got a graphical rectangular representation: - 10 lines for fields, - 10 lines for getters, - 10 lines for setters Then, total = 30 lines. IMHO, the 10+10 lines for get/setters are redundant for the UML representation. In fact, to say all the story, this problem has its roots into the fact that a Java class has still no properties, but fields! A Java class property is currently somewhat defined through a getter (plus, for writable property, a setter). Not exactly by a field ! Having today 30 lines (10+10+10) instead of 10 is quite VERY cumbersome to study a domain model! Then, I just feel like sometimes the UML representation (JUST after RE) is useless. This is why I wrote above: UML is not adapted to the Java style of programmation. I would prefer the following solution: - if there is a field 'myField' with a getter or a setter, I don't want 2 (or 3) lines like: some_type myField; public some_type getMyField(); public void setMyField(some_type); I would prefer something like this - just one line: public property some_type myField; with a tagged value (or stereotype ?) in order to indicate if there is a getter and if there is a setter. Or maybe 'property' keyword being a stereotype (I don't know if stereotypes are doable on attributes...). I would like such RE behavior to be available as an UML option. Then, UML diagrams would be (1) much more readable by default, (2) it would be more inline with property to come in some future. What do you think ? Thanks.
*** Issue 140184 has been marked as a duplicate of this issue. ***
similar to issue 109048 (soem comments in 109048). at least it's good to have option show/hide accessors. unfortunately it may not be implemented in nearest future because of resources.