Community
Participate
Working Groups
I noticed an issue which looks remarkable similar to: Bug 55138 - [runtime] prefs: pref change events not backwards compatible + A preference listener registered like: Preferences preferences = ResourcesPlugin.getPlugin().getPluginPreferences(); preferences.addPropertyChangeListener(this); When a client does: ResourcesPlugin.getPlugin().getPluginPreferences().setValue(RefreshManager.PREF_LIGHTWEIGHT_AUTO_REFRESH, true); The event listener receives an event with value type _Boolean_. When a client uses the new API: InstanceScope.INSTANCE.getNode(ResourcesPlugin.PI_RESOURCES).putBoolean(RefreshManager.PREF_LIGHTWEIGHT_AUTO_REFRESH, true); An event is fired with new value of _String_. Effectively this could break existing plugin preference listeners when clients use the new non-deprecated API. Test to be attached.
Created attachment 191923 [details] test 1 Test for the issue.
Unfortunately this is a known issue. There is a reference here in an old doc: http://www.eclipse.org/eclipse/platform-core/documents/user_settings/pref_apis.html It was a consequence of trying to jump through hoops to maintain backwards compatibility but still move forward. At the time there were 3 APIs that we needed to play nice together. So we determined that it was best to update the old javadoc and move forward with the new API. (which contained un-typed values and was similar to the APIs in OSGi and the JDK)
Ok, thanks. In the case of the example it would be possible to fire an event of the right type as I'm explicitly doing a typed put: InstanceScope.INSTANCE.getNode(ResourcesPlugin.PI_RESOURCES).putBoolean(RefreshManager.PREF_LIGHTWEIGHT_AUTO_REFRESH, true); However as it's been this way for so long (and no one else has complained) perhaps I was unlucky in writing code that expected this.
