You are here

Java and the registry

1 post / 0 new
techgurufloyd
Offline
Last seen: 13 years 5 months ago
Joined: 2011-05-31 23:03
Java and the registry

Let's store java preferences in a file instead of storing them in the registry as noted in the launcher guide:

One way of storing settings in Java applications is with java.util.prefs. This stores its settings in the registry, in HKCU\Software\JavaSoft\Prefs\[package path]

The Basics
Java makes it fairly simple to change how it stores settings. I just replace the thing that stores settings in the registry with something else that stores them in a file.

I've compiled a simple jar (containing only two classes) that replaces the WindowsPreferencesFactory implementation with a FilePreferencesFactory that I got from Sonatype Nexus (see the java files here and here which are based on code from this page).

Why bother?
I am working on a launcher for Eclipse-based SpringSource Tool Suite (STS). As it is based on Eclipse, I get to customize it with a variety of Eclipse plugins that make my life easier. So far, one of the default parts of STS uses java.util.prefs. As I install more plugins, I don't want to continually watch the registry to make sure I've included all of the registry keys in the launcher ini file. I wanted something a little more robust than PAL's (admittedly excellent) registry handling.

Installation and Usage
In the launcher ini file, I set CommandLineArguments to -vm "%JDK_HOME%\bin" -vmargs -Duser.home="%PAL:DataDir%" -Xbootclasspath/a:%PAL:PortableAppsDir%\CommonFiles\JavaPrefs\prefs-1.0.0.1.jar;%PAL:PortableAppsDir%\CommonFiles\JavaPrefs\slf4j-api-1.6.1.jar
(all on one line).

Stepping through this, we see the following:

-vm "%JDK_HOME%\bin"
This tells eclipse to use my JDK - I'll talk about what I did to set the JDK_HOME var in another forum thread.
-vmargs
Everything after this point is sent by eclipse to java.exe
-Duser.home="%PAL:DataDir%"
This tells java to use PAL:DataDir to store things in. This is used, for example as the default location for the file that replaces the registry: .fileprefs
-Xbootclasspath/a:%PAL:PortableAppsDir%\CommonFiles\JavaPrefs\prefs-1.0.0.1.jar;%PAL:PortableAppsDir%\CommonFiles\JavaPrefs\slf4j-api-1.6.1.jar
This is the line that instructs Java to use the new preferences storage mechanism instead of the default. It includes prefs-1.0.0.1.jar as well as it's only dependency slf4j-api-1.6.1.jar. You could also include any of the slf4j bindings if you want it to actually log something (By default, it doesn't log anything).

By default, the preferences are stored in @user.home\.fileprefs. You can override this setting by putting -Dcom.portableapps.prefs.file=<your file here> in your CommandLineArguments.

Downloads

Future
I think these would be a good addition to the jPortable package. Just put the jars in CommonFiles/JavaPrefs and let all of the apps that use java include this instead of tracking down registry settings. Of course, an app developer will still need to verify that nothing else is stored in the registry, but this should take care of a lot (most?) of the java apps, as they just store their preferences with java.util.prefs. It would have to be enabled on an per app basis to make sure the app doesn't re-include the slf4j jars (for example). Another option would be to create a PA.c installer just for these files.

I would like to use something more like what is on Linux and Solaris: FileSystemPreferences. This stores settings in a tree of files instead of in one massive file like FilePreferences does. That could give us a common PortableApps preferences store for all of the apps. If anyone wants to tackle this: the *nix file locking needs to be removed from the FileSystemPreferences.java.

License
AFAICT, this is under the GPL - they've included it in the Sonatype Nexus (which was under the GPL, not AGPL, for the file version I checked out). David Croft didn't say which license the original code is released under. I can contact him to make sure GPL is good if there is enough interest in this.