[eclipse-dev] Re: Warning: avoid testing preference names using ==

["Nick Edgar" <Nick_Edgar@xxxxxxx>]

To minimize the risk of this problem, we have decided to intern the 
property name strings when importing preferences, before sending out 
PropertyChangeEvents.
The PR for this is http://dev.eclipse.org/bugs/show_bug.cgi?id=20534

However, senders of PropertyChangeEvent.getProperty() should still be 
changed to use equals rather than ==, to avoid similar problems in the 
future.

Nick

----- Forwarded by Nick Edgar/OTT/OTI on 06/21/02 11:16 AM -----


Nick Edgar
06/20/02 04:52 PM

 
        To:     eclipse-dev@xxxxxxxxxxx
        cc: 
        Subject:        Warning: avoid testing preference names using ==

We have recently seen several instances of a programming error whereby 
implementors of IPropertyChangeListener use == to check the value of 
PropertyChangeEvent.getProperty(), rather than using equals().

This is incorrect because there is no guarantee that the property name in 
the event is a constant.
For example, the Workbench / Preferences / Import... action reads the 
property names and values from a file.  It sends out notifications to any 
activated plugins, but the string read from the file for the property name 
will not be == to the corresponding string constant.
(We considered interning the strings in the preferences import, but this 
is not the right answer and would merely hide the problem until some other 
use case reads property names from a file, not to mention encouraging bad 
programming practices.)

Please ensure that all senders of PropertyChangeEvent.getProperty() use 
equals rather than ==.
Although the class ensures that the property name is not null, a safe 
idiom to use is the following:
if (MY_PROPERTY.equals(event.getProperty())) {
  // update accordingly
}

The preferences facility has recently been pushed down to core runtime 
from JFace, but the JFace APIs still exist and are still commonly used.
So you will need to check references to both:
org.eclipse.jface.util.PropertyChangeEvent.getProperty(), and
org.eclipse.core.runtime.Preferences$PropertyChangeEvent.getProperty()

If this is not fixed, preferences will appear to work normally when being 
adjusted manually in the preference pages.
However, when preferences are exported and reimported, any active plugins 
with listeners using == will not update properly.

We highly recommend testing all your preferences with the new 
import/export facility.

There are existing PRs for known occurrences in the SDK.
See http://dev.eclipse.org/bugs/show_bug.cgi?id=20471

I have filed http://dev.eclipse.org/bugs/show_bug.cgi?id=20758
to clarify the spec for PropertyChangeEvent.getProperty().

Nick