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 100758 - [65cat] Implement beans refactoring (and improve encapsulate fields)
Summary: [65cat] Implement beans refactoring (and improve encapsulate fields)
Alias: None
Product: java
Classification: Unclassified
Component: Refactoring (show other bugs)
Version: 6.x
Hardware: All All
: P1 blocker with 15 votes (vote)
Assignee: Jan Becicka
Keywords: PLAN
: 49485 90941 111616 128858 (view as bug list)
Depends on: 47625 51919 69498
  Show dependency tree
Reported: 2007-04-12 10:51 UTC by Jiri Prox
Modified: 2013-01-11 17:25 UTC (History)
3 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Prox 2007-04-12 10:51:22 UTC
NetBeans IDE Dev (Build 200704111800)
1.6.0; Java HotSpot(TM) Client VM 1.6.0-b105
Linux version 2.6.5-1.358 running on i386
en_US (nb); UTF-8

When renaming class field it would be nice to have a possibility to rename also
the setter and getter method. There is no way how to do that now, when the Beans
node was removed.
Comment 1 Jiri Prox 2007-08-01 15:04:00 UTC
*** Issue 111616 has been marked as a duplicate of this issue. ***
Comment 2 runner 2007-10-14 16:44:10 UTC
I see it more defect than ehnancement as it brings incosistency to the code 
and behaves in unexpected way.
Comment 3 Jan Becicka 2007-10-15 06:49:04 UTC
We use DEFECT for issues, which behavior is not according to specification. This is 100% valid issue, but it is an
Comment 4 Jiri Prox 2008-03-03 07:39:42 UTC
*** Issue 128858 has been marked as a duplicate of this issue. ***
Comment 5 Jiri Prox 2008-04-11 01:47:06 UTC
moving opened issues from TM <= 6.1 to TM=Dev
Comment 6 Jan Becicka 2008-08-11 13:50:16 UTC
*** Issue 49485 has been marked as a duplicate of this issue. ***
Comment 7 Michel Graciano 2008-08-19 15:23:21 UTC
There is no guidelines for feature so I following my needs and the other users. It should be implemented asap and 'Nice
to have' for 7.0 is not a good option.
Comment 8 _ wadechandler 2009-01-23 22:06:49 UTC
Just a little more information. Don't forget that just renaming a field shouldn't necessarily rename the methods. It
seems a better and specific JavaBean rename action is needed. Thinking about the case where the variable name is shorter
for inner private use. What about when the Bean Info references method names not necessarily matching the patterns from
JavaBeans? This is a feature of a property descriptor. So, it really needs to be thought out well to actually encompass
the JavaBeans specifications and not just POJO use cases.

I have really been hoping to get some time to really work on the beans module. This is the module that provides the
support of the Bean Patterns view in the navigator. So, in that panel in the navigator maybe have some actions that can
then tie into refactoring. 

So, say I want to rename a property. It can bring up a dialog that lets me tell it to 1) change the name of the field or
leave it alone, 2) change the name of the setter or getter independently (canRead versus isReadable as boolean reader
properties), 3) update the BeanInfo and property descriptors, or is this property not going to affect that, but then
that becomes subjective, because the JavaBeans property rename support needs to alert the user that if a property use a
non-JavaBean pattern name that the BeanInfo property descriptors have to be updated because that is the only way to link
a method of such a name to a property.
Comment 9 gekkothelizard 2009-01-25 10:23:36 UTC
I think that the best solution would be a comprehensive javabean editor feature. Such an editor would not only be 
generating code, but would understand it's state so it could also edit it. The current code generation features are 
nice, but may times inadequate. I think that a full javabean editor wouldn't have to replace them in lightweight tasks 
like generating getter/setter methods, but could be used for tasks such as creating a javabean from scratch and 
maintaining existing large beans. The javabean pattern is itself a dated and cumbersome thing, especially if you want 
to be firing property change events also. I repeatedly have the same problem in our firm of convincing junior 
programmers about writing all that boilerplate code. If that code would at least be generated for them (and for me :)) 
it would make my everyday work much more productive (I user entity beans, and beans binding a lot).
Comment 10 Michel Graciano 2009-02-05 19:51:17 UTC
IMO, this issue is a blocker for
What do you think? That issue and wiki page has reference about the content of this issue. IMO, we need to track all
needed refactorings and treat 106831 as a umbrella. I hope this could be the first one.
Comment 11 mperezma 2009-03-28 22:59:55 UTC
*** Issue 90941 has been marked as a duplicate of this issue. ***
Comment 12 Jan Becicka 2011-05-26 10:54:34 UTC
Author:    Jan Becicka <>
Date:      2011-05-26 10:55
Issue #100758 - [65cat] Implement beans refactoring (and improve encapsulate fields)
Comment 13 Quality Engineering 2011-05-27 11:56:07 UTC
Integrated into 'main-golden', will be available in build *201105270401* on (upload may still be in progress)
User: Jan Becicka <>
Log: Issue #100758 - [65cat] Implement beans refactoring (and improve encapsulate fields)
Comment 14 Jiri Prox 2013-01-11 17:25:38 UTC