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 7918 - JavaConnections.TYPE_CLASSES_CHANGE | JavaConnections.TYPE_CONSTRUCTORS_CHANGE are fired, but why?
Summary: JavaConnections.TYPE_CLASSES_CHANGE | JavaConnections.TYPE_CONSTRUCTORS_CHANG...
Status: CLOSED INVALID
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P4 normal (vote)
Assignee: issues@java
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2000-10-16 13:09 UTC by Jan Becicka
Modified: 2007-09-26 09:14 UTC (History)
0 users

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 Jan Becicka 2000-10-16 13:09:19 UTC 
[dev-48]
Following pseudo-code cause firing of JavaConnections.TYPE_CONSTRUCTORS_CHANGE |
JavaConnections.TYPE_CLASSES_CHANGE | JavaConnections.TYPE_METHODS_ADD, but
I think only JavaConnections.TYPE_METHODS_ADD should be fired.

JavaDataObject DO = ... createFromTemplate() //e.g. from
Templates/Classes/Class.java
ConnectionCookie cc = (ConnectionCookie) DO.getCookie(ConnectionCookie.class);
MyListener l = new MyListener();
JavaConnections.Type t = new JavaConnections.Type(JavaConnections.TYPE_ALL);
cc.register(t, l);
.
.
clazz.addMethod(...);
.
.
cc.unregister(t,l);
Comment 1 Svata Dedic 2000-10-19 15:14:59 UTC 
It seems that the changes are recorded although no one is really interested in
them.
After you register for javaconnections, diff from the old stored state is fired.
Comment 2 Svata Dedic 2000-10-25 19:19:59 UTC 
It seems that the behaviour you are experiencing is a side effects of delayed
resolution of identifiers in the source. Those events are fired after reparse of
the source text is done. Your listener is registered before the background
reparse scheduled from within createFromTemplate() completes. Then it appears as
the code has to notify about changes, b/c there IS a listener.
Comment 3 Svata Dedic 2001-03-02 07:56:13 UTC 
x
Comment 4 Svata Dedic 2001-03-02 07:58:31 UTC 
From my point of view, the behaviour is OK. You simply attach the listener at wrong time - the implementation decides to fire change events after you attach it. To prevent this behaviour, you can call prepare() on the source and wait for the background parsing to complete. Then any delayed actions (like ident resolution + dependendings) are already scheduled or executed so you should not get those events.
Comment 5 Quality Engineering 2003-07-01 13:12:48 UTC 
Resolved for 3.3.x or earlier, no new info since then -> closing.
Comment 6 Quality Engineering 2003-07-01 13:20:56 UTC 
Resolved for 3.4.x or earlier, no new info since then -> closing.