Även om beteendet hos IPreferenceStore i AbstractUIPlugin#getPreferenceStore()
inte har ändrats har vi uppdaterat specifikationerna för IPreferenceStore så att beteendet som vi erbjuder definieras på ett explicit sätt.
Typning av PropertyChangeEvents
Alla händelser med egenskapsändringar från en IPreferenceStore måste ha ett gammalt och ett nytt värde av samma typ som är konsekvent med det setValue-anrop som genererade det.
Om du till exempel anropar IPreferenceStore#setValue(strängnamn, långt värde)
kommer båda värdena som genereras i PropertyChangeEvent från denna metod att vara av typen java.lang.Long
.
putValue
Anrop till #putValue
genererar ingen PropertyChangedEvent
.
Anrop till olika #setValue
-metoder gör det.
Relationer mellan OSGI-preferenser och en IPreferenceStore
IPreferenceStore som tillhandahålls av AbstractUIPlugin#getPreferenceStore()
är en förekomst av ScopedPreferenceStore
som använder org.osgi.service.prefs.Preferences
som en back end. org.osgi.service.prefs.Preferences
sprider endast ändringshändelser som String.
ScopedPreferenceStore
paketerar de OSGI-händelser som genereras av IPreferenceStore#setValue(strängnamn, strängvärde)
och sin egen PropertyChangeEvents
och vidarebefordrar händelsen till sina lyssnare. I andra implementeringar av IPreferenceStore#setValue
kommer ScopedPreferenceStore
att skapa sin egen händelse av rätt typ och inte sprida händelserna från OSGI-preferenser.
Lyssnare till en ScopedPreferenceStore
bör vara beredda på både typdefinierade värden och strängvärden i sina ändringshändelser eftersom händelser fortfarande kan fås via OSGI-preferenser (under till exempel en import av preferenser).
OSGI-händelser är alltid av typen java.lang.String.
Det har alltid varit möjligt att få en null org.eclipse.swt.widgets.Shell från den befintliga IWorkbenchWindows i Eclipse SDK. Vi har nu explicit definierat villkoren där detta inträffar, nämligen när ett skal har skapats eller när IWorkbenchWindow har stängts.