Although JFace defines IPreferenceStore, there's a lower-level interface called IEclipsePreferences
. The key difference between IPreferenceStore and IEclipsePreferences is that the latter has support for arbitrary nodes similar to nested HashMaps. IEclipsePreferences is also based upon the OSGi Preferences service and can be used without any UI or JFace involvement. When the IPreferenceStore is obtained from AbstractUIPlugin, it lazily creates a ScopedPreferenceStore using InstanceScope and the bundle's symbolic name as the node name. Perform the following steps:
- Modify
clock.ui'sActivator:int launchCount = getPreferenceStore().getInt("launchCount"); IEclipsePreferences eclipsePreferences = InstanceScope.INSTANCE. getNode(PLUGIN_ID); int launchCount2 = eclipsePreferences.getInt("launchCount",-1); System.out.println("I have been launched " + launchCount + " times and " + launchCount2); - Run the Eclipse instance and open the Time Zone View.
- In the host Eclipse instance, go to the Console view, and the output should show the same value being displayed I have been launched 6 times and 6.
The same preference value was accessed through both as JFace's IPreferenceStore, which is used by UI plug-ins and extension points such as the PreferencePage and through the IEclipsePreferences API that can be used by headless plug-ins.
To pass in an existing IEclipsePreferences to an API (like the preference page), an inverse adaptor can be created using the following code:
public class EclipsePreferencesScope implements IScopeContext {
private IEclipsePreferences preferences;
public EclipsePreferencesScope(IEclipsePreferences preferences) {
this.preferences = preferences;
}
public String getName() {
return "";
}
public IPath getLocation() {
return new Path(preferences.absolutePath());
}
public IEclipsePreferences getNode(String qualifier) {
return preferences;
}
}Finally the IEclipsePreferences interface is a subtype of Preferences, which is a standard OSGi service. To compile against just the OSGi runtime, use Preferences as the declared type for variables instead of IEclipsePreferences. That way, the code can be compatible with both Eclipse and standard OSGi libraries.
Eclipse's internationalization support is provided by a plugin.properties file. In the plugin.xml, instead of using strings for the values, use %keys. The % instructs the engine to look up a corresponding entry in plugin.properties to display the value.
To support different languages use plugin_fr.properties, plugin_de.properties for French and German respectively (don't forget to add these to build.properties otherwise they won't be found). The keys are still the same, but the values can be localized appropriately. The search keywords are an example of something that can be searched as well, so use an online translation service or make-up a translation to test out the effect of running Eclipse in a different language. (Eclipse can be launched in different languages with eclipse -nl de on the command line.)