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 17217 - PCL support/method creation redundant in JComponent classes
Summary: PCL support/method creation redundant in JComponent classes
Status: RESOLVED INVALID
Alias: None
Product: java
Classification: Unclassified
Component: Beans (show other bugs)
Version: 3.x
Hardware: All Other
: P3 blocker with 1 vote (vote)
Assignee: Jan Becicka
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-11-01 20:34 UTC by kevin yong
Modified: 2010-10-08 08:43 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description kevin yong 2001-11-01 20:34:11 UTC 
if i create a class inheritates from Object, and use Bean Patterns to add 
properties to it, the Bean Patterns can generate 'propertyChangeSupport' and 
related 'addPropertyChangeListener' and 'removePropertyChangeListener' methods, 
and add 'propertyChangeSupport.firePropertyChange' call to the property's 'set' 
method. It is ok.

But the issue is: if i create a class inheritates from 'JComponent', 
the 'propertyChangeSupport' and related methods are already built in.
Now, when i use Bean Patterns to add a property:
  1. if i choose 'Generate Property Change Support', it will add everything   
just like in the case when the class is inheritated from Object. But, all those
'propertyChangeSupport' and related methods are DUPLICATIONS with the ones 
already built in JComponent;
  2. if i DONT choose 'Generate Property Change Support', then 
the 'firePropertyChanged' call would NOT added to the property's 'set' method.

Is it possible that the 'Bean Patterns' check the existance 
of 'propertyChangeSupport' and related methods in the class before generate a 
new one? If they exist, then just use the exist ones.

Thank you.
Comment 1 Petr Suchomel 2001-11-02 09:06:49 UTC 
This featurre has been implemented since 3.2. Now it does not work. I 
fix it ASAP.
Comment 2 Jan Chalupa 2001-11-27 10:55:33 UTC 
Target milestone -> 3.3.1.
Comment 3 Svata Dedic 2001-12-14 17:33:23 UTC 
Increasing priority; from a quick look, it can be accomplished with
the current infrastructure.
Comment 4 Svata Dedic 2002-05-21 17:02:02 UTC 
Cleaning up
Comment 5 Marek Grummich 2002-07-19 16:15:40 UTC 
Target milestone was changed from not determined to TBD
Comment 6 Jesse Glick 2002-08-22 06:01:36 UTC 
Improving summary, it was so vague as to be useless before.

If this was really working in 3.2, then it is a regression that it has
been broken in the last two releases, right? Hence DEFECT?
Comment 7 _ rkubacki 2004-05-14 13:44:39 UTC 
I agree that this should be treated as defect. For a Component
subclasses you would need to override all add/remove/fire methods a do
it carefully to correctly notify listeners added in contructor before
new PCS is created in this subclass.

So at least warn user that the action can break existing code if there
are already addPCL/removePCL methods.
Comment 8 Jan Becicka 2010-10-08 08:36:25 UTC 
This issue is not valid any more. PCL support is generated through completion and you see, what is being added and it is up to, what you want.
Comment 9 _ rkubacki 2010-10-08 08:43:56 UTC 
:-(

Alt-Ins | Add property gives me a dialog where I can customize. That's right and at least 'generate PCS' is off by default. OTOH it is bad if the tool helps me to write bad code. Perhaps a hint in editor that overriding {add,remove}PCL is strange can help (code smell).