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.
Sometimes the PropertyChangeEvent on field's "type" property is not fired after the parser processes the source. The field's type must be set via OpenAPIs to be some reference type name, whose identifier must be specified using correct source and full names. After the source is parsed, PropertyChangeEvent should be fired on the "type" property because the identifier used there transitions from NOT_YET_RESOLVED state to either RESOLVED or UNRESOLVED. This property change event is mistakenly swallowed and never fired.
Created attachment 1245 [details] Patch that solves this problem
The cause is that PropertyChangeSupport.firePropertyChange compares old and new property's values and if they are equal it does not fire anything. In this particular case, this optimization blocks the events from being delivered. I dare not to change Identifier's equals method to include the indicated resolution state. Identifiers are used at many places throughout the IDE. Instead of that, I would patch the ElementImpl class to not use the standard PropertyChangeSupport, but I've copied the necessary code to handle listener list, sychronization and event firing. Please see & comment the attached diff file.
Target milestone -> 3.3
Changing milestone to 3.2.1, this should be fixed for the sake of tools built on top of NetBeans
Setting milestone forth (it's still not integrated). Marking as FIXED (in dev trunk only)
VERIFIED
Resolved for 3.4.x or earlier, no new info since then -> closing.