Hi! All the paperwork is signed, so this can be committed as is (if accepted).
Fixed from the last (not committed) release is the fact that I'm currently turning the native implementation to reuse libraries in Classpath, most notably, now the native peer uses "jcl.h". The idea is to integrate the library into classpath, following the gtk peer example. Know issues: The backend works, but there are few problems when using some kinds of keys, most notably, keys with white spaces and other "special" characters (ie. "<" and ">"). There are a couple of workaround to this, but they all require to change the keys inside the gconf database (an example, to use the schema to store the real key name, while storing the key with underscores instead of spaces). This seems to me not acceptable, so I decided to leave things as they are. This problem is gconf related, and there is at least one bug entry in the gnome bugzilla: http://bugzilla.gnome.org/show_bug.cgi?id=161209 I'll file a RFE to see if we can have a little support from the gconf team about this. The GConf module default node is located under: user root: /apps/java system root: /system These prefix are added to the node names, but are not exposed to users. This means that, whichever backend is used, a root node of "/my/app" is exposed always as "/my/app", even though the gconf backend uses "/apps/java/my/app" as real node. These prefixes can be changed using the following two system properties: gnu.java.util.prefs.gconf.system_root gnu.java.util.prefs.gconf.user_root Finally, the backend is chosen setting this property: java.util.prefs.PreferencesFactory = gnu.java.util.prefs.GConfBasedFactory Though I worked a bit on it, there are surely some other caveats I am missing, but until now, all tests done passed. I also have a mauve test for the preference api, the test does not assume to use the gconf backend, and infact, was used to compare results of the gconf and the default file based preference implementation. The default backend is still the file based one, I suggest to enable the gconf one after a bit more of testing. Mario ----- Here is the Changelog: 2006-0-12 Mario torre <[EMAIL PROTECTED]> * gnu/java/util/prefs/GConfBasedPreferences.java: new class. * gnu/java/util/prefs/GConfBasedFactory.java: new class. * gnu/java/util/prefs/gconf/GConfNativePeer.java: new class. * gnu_java_util_prefs_gconf_GConfNativePeer.h: generated header file. * classpath/native/jni/gconf-peer/GConfNativePeer.c: new C file. * configure.ac: update to introduce new files. Added options to build gconf native peer used by the GConf preference backend. * include/Makefile.am: update to introduce new files. * native/jni/Makefile.am update to introduce new files. * scripts/check_jni_methods.sh: added three new ignored file from check. * native/jni/gconf-peer/Makefile.am: new Makefile needed to build gconf-peer shared library. -- Lima Software, SO.PR.IND. s.r.l. http://www.limasoftware.net/ pgp key: http://subkeys.pgp.net/ Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/
GConf_preference_backend.patch.tar.gz
Description: application/compressed-tar
