Don't store stuff in the application bundle - as you've found,
it won't work if the Applicaiotns folder is write-protected or
it's on a CD or mounted over the network. Put stuff in one of
the "Library/Application Support" folders instead, or, if it's
not much, use the java.util.prefs API which will put stuff in
your ~Library/Preferences folder. Personally, I hate the hidden-
files-in-the -home-folder thing.
Using the java.util.prefs mecanism is easy and efficient... until
you have to have your app de-install properly in a portable way.
My apps have to run on Linux, Windows and Mac. The Unix
$HOME/.apprc hack is the only way I have found that allows me to
get the user to wipe the app completely from the HD (with
file.delete()). How do you erase the Windows registry entry, the
Linux $HOME/.java/whatever and the Mac $HOME/Library/Preferences/
app without conditional code for each platform? Maybe you can but
I have found out how. If I would, I certainly would adopt the
prefs immediately!
The Java Preferences API is designed to be platform-agnostic. How
it's implemented depends on the underlying JVM. In Linux, it
results in a .java directory in the user's home and various
subdirectories (for user preferences). In Windows, it goes into
the registry. But in Mac OS X, it's contained entirely in a
single file, ~/Library/Preferences/
com.apple.java.util.prefs.plist. Simply removing this file is not
wise, of course, as it contains all preferences at the user level
(and I don't know where system-level preferences get placed, never
having tried it, but I wouldn't be surprised if it's in /Library/
Preferences by a similar name).
You can avoid this problem by making your preferences node name
have more than three levels. So, for instance, com.foo.thing goes
into the single preferences files, but com.foo,bar.thing goes into
its own plist file of the same name. How they came up with a scheme
as weird as this is anyone's guess.
removeNode() is the closest to what I would like to achieve, but it's
not perfect. Consider this:
1. I have a class in a package called com.example.package
2. Creating a Preferences object goes like this :
Preferences prefs = Preferences.userNodeForPackage(getClass());
- On Mac: this creates a file in $HOME/Library/Preferences called
'com.example.package.plist' + an entry in $HOME/Library/Preferences/
com.apple.java.util.prefs.plist
- On Windows: this creates an entry in the registry under
'HKEY_CURRENT_USER\Software\JavaSoft\Prefs\com\example\package'
3. Now if I remove the node with prefs.removeNode():
- On Mac: this actually removes the file in $HOME/Library/Preferences/
com.example.package.plist and the entry in $HOME/Library/Preferences/
com.apple.java.util.prefs.plist (this is perfect)
- On Windows: this removes the last node (called 'package') but not
the above tree (i.e. 'com\example') (this could be better and remove
the whole thing).
I couldn't try on Linux today so I don't know how this behaves there.
I guess I like the $HOME/.apprc trick because I am used to Linux. But
you're right, Preferences is definitely the way to go.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
