Can you provide reproducible steps? I don't see it in 7.3 logs.

I did not have any reproducible steps two years ago so I certainly do not now. Just something I noticed in my log file.

Unclear to me how the listener got added since there is no add/removePCL method in this class or its superclasses. Probably someone mistakenly wrote

PropertyChangeListener pcl = …;
NbEditorDocument doc = …;
SomeOtherThing thing = …;
thing.addPropertyChangeListener(WeakListeners.propertyChange(pcl, doc));

Probably a Jackpot hint could be written to detect mismatches between the claimed and actual event source, i.e. something like (unsure of syntax):

$actual.addPropertyChangeListener(WeakListeners.propertyChange($l, $claimed)) :: $actual != $claimed => <warning>;

and of course also including other weak listener factories.

Thank you for reply. You are right, that can be one reason that it happens sometimes. If somebody reopen with recent log file, I will do some investigation.

Created attachment 158793 [details]
Log file from NetBeans 8.1 showing the "Can't remove java.beans.PropertyChangeListener" warning

Uploading a recent NetBeans 8.1 log file showing the following warning:

WARNING [org.openide.util.WeakListenerImpl]: Can't remove java.beans.PropertyChangeListener using method org.netbeans.modules.editor.NbEditorDocument.removePropertyChangeListener from org.netbeans.modules.editor.NbEditorDocument@48496435, mimeType='text/x-java', kitClass=null, length=6027, version=1, file=org.netbeans.modules.java.JavaDataObject@4d447d3[AbstractFileObject@58324cb9[javax/swing/text/EditorKit.java]]

I also get this message in my NetBeans Platform application--it started when I upgraded it from 8.0 to 8.1.

Reopening the bug per Milutin's previous comment. (Or happy to create a new bug.)

This bug now seems easy enough to reproduce; I can produce the message by opening a Java editor, closing all editors, and then invoking a GC with by double-clicking the memory meter in the "Performance" toolbar item.

Storing a stacktrace in WeakListenerImpl.ListenerReference on creation and then printing it on the failed removal shows the place where the problematic listener is added:

java.lang.Exception
	at org.openide.util.WeakListenerImpl$ListenerReference.<init>(WeakListenerImpl.java:554)
	at org.openide.util.WeakListenerImpl.<init>(WeakListenerImpl.java:109)
	at org.openide.util.WeakListenerImpl.<init>(WeakListenerImpl.java:99)
	at org.openide.util.WeakListenerImpl$PropertyChange.<init>(WeakListenerImpl.java:187)
	at org.openide.util.WeakListeners.propertyChange(WeakListeners.java:282)
	at org.netbeans.modules.editor.lib2.view.DocumentViewOp.checkSettingsInfo(DocumentViewOp.java:937)
	at org.netbeans.modules.editor.lib2.view.DocumentViewOp.checkViewsInited(DocumentViewOp.java:622)
	at org.netbeans.modules.editor.lib2.view.DocumentView.getPreferredSpan(DocumentView.java:251)
	at javax.swing.plaf.basic.BasicTextUI$RootView.getPreferredSpan(BasicTextUI.java:1353)
	at javax.swing.plaf.basic.BasicTextUI.getPreferredSize(BasicTextUI.java:919)
	at javax.swing.JComponent.getPreferredSize(JComponent.java:1662)
	at javax.swing.JEditorPane.getPreferredSize(JEditorPane.java:1333)
	at org.netbeans.modules.editor.NbEditorUI$LayeredEditorPane.getPreferredSize(NbEditorUI.java:475)

The problem is on this line of DocumentViewOp:

o.n.modules.editor.lib2.view.DocumentUtilities.addPropertyChangeListener(doc, WeakListeners.propertyChange(this, doc));

The DocumentUtilities.addPropertyChangeListener is a special API for allowing property change listeners to be attached to BaseDocument instances (see #181073). Since it doesn't actually add addPropertyChangeListener/removePropertyChangeListener methods to BaseDocument, it doesn't work with WeakListeners.

As far as I can see, the only place that actually uses DocumentUtilities.addPropertyChangeListener is the single line i DocumentViewOp above.

I would propose adding a removedPropertyChangeListener method to BaseDocument that delegates to DocumentUtilities.removePropertyChangeListener (or performs the equivalent logic itself). This way the WeakListener will find the method it expects when the listener is due to be removed, and the property change events will still have the Document instance as the event source instead of the delegate PropertyChangeSupport, as is probably desired.

An alternative is to make WeakListeners aware of the special setup wrt. property change listeners on BaseDocument instances. But that seems like an abstraction violation.

Added this bug to the new Apache JIRA here: https://issues.apache.org/jira/browse/NETBEANS-406