Currently the preference mechanism sends out change notification (for both preference value changes and node changes) immediately after the action is performed and before the method returns. In essence, we set the preference value, iterate over all the appropriate listeners, notify each with a constructed change event, and then return from the #setValue method.

There are a few obvious problems with this approach and the Core team is considering moving event notification into a background job to work around these problems. The purpose of this document is to outline the problems at the Core level and to guage the effect on clients at the UI level.

1. Protect against deadlocks. When calling client code, there is always the chance for deadlock. Consider the following block of seemingly innocent code:
   

   synchronized void foo() {
      ...
      preferences.setValue(key, value);
      ...
   }

   With the current code the notification will occur within the sychronized method. This means there is a chance that the client listener code can deadlock.

2. Protect against bad listeners. Consider the following code:
   

   new IEclipsePreferences.IPreferenceChangeListener() {
      public void preferenceChanged(PreferenceChangeEvent event) {
         ...
         preferences.setValue(key, value);
         ...
      }
   }
   

   In the best-case scenerio, the listener is reacting to a change in preference-key-1 and setting a new value for preference-key-2. This will send off another round of notification and that will be the end of it. In the worse-case scenerio the client is making a change to the same preference key that is in the event. In this case, we are looking at a recursive call and, eventually, stack overflow problems.

3. Performance. Clients are able to write whatever they want in their listener code and it may not be performant. If we return immediately from the call to #setValue, then the clients who are calling this method will not have to wait before continuing their execution.

1. Client assumptions about the current code. Although it isn't specified in the API, existing clients could be relying on the current implementation and they could be expecting change events to happen immediately after the change itself, and in a sychronous manner.

1. The JFace API does not explicitly specify that preference changes must happen (and preference change events occur) within the UI thread. In the current code base, any clients who call the JFace preference APIs in the non-UI thread risk having problems occur. Bug 77280 describes this problem. In fact, it has already been acknowledged that there are clients who call this code from the non-UI thread and hence the creation of the IPreferenceStore#putValue API method. This method sets values in the preference store without providing listener notification.

2. The JFace API does not specify whether or not the property change notification happens in the same thread that the change happened.

1. Client assumptions about the current code. Clients may be relying on the fact that by the time they return from their IPreferenceStore#setValue calls, all client listeners will have been notified.