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:
clock.ui
's Activator
: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);
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.)