RFC: patch to make gconf as default preference backend
This patch makes gconf the default backend.
The patch works adding a new configure option that let the user to
specify a default implementation (like FileBased or GConfBased ones).
If the user does not provides this option, than the preference backend
is FileBased (current default).
Only if the GConf backend is built, than it is used, unless the flag
specify a different default.
To make this possible, I have added a new field to
gnu.classpath.Configuration.in, this is inherited from the configure.ac.
Not sure if it is the right place but this avoid to check for the
existence of a class generating exceptions that can slow down the code.
The final change is in java.util.prefs.PreferencesFactory: the
getFactory method now gets the system property from the Configuration
class.
There are no other change in this last class, I left the ability to
revert to a sane default if the user supply an invalid backend.
The property is accessed by this class and not by SystemProperties to
allow checks from the security manager.
Please, remember that I do not have cvs write access: someone should
commit this one for me (and the old one too!!)...
This is the ChangeLog:
2006-07-01 Mario Torre <[EMAIL PROTECTED]>
* configure.ac: Added new option --enable-default-preferences-peer
to pass user specified default preference backend.
The default backend in now GConf.
* gnu/classpath/Configuration.java.in (DEFAULT_PREFS_PEER): added new
field inherited from configure.ac
* java/util/prefs/Preferences.java: New inclusion for
gnu.classpath.Configuration.
(getFactory): gets java.util.prefs.PreferencesFactory system property
from Configuration class.
--
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/
Index: configure.ac
===
RCS file: /sources/classpath/classpath/configure.ac,v
retrieving revision 1.168
diff -u -r1.168 configure.ac
--- configure.ac 30 Jun 2006 11:39:15 - 1.168
+++ configure.ac 1 Jul 2006 22:29:13 -
@@ -83,6 +83,18 @@
AM_CONDITIONAL(CREATE_CORE_JNI_LIBRARIES, test "x${COMPILE_CORE_JNI}" = xyes)
dnl ---
+dnl Default Preference Backend
+dnl ---
+AC_ARG_ENABLE(default-preferences-peer,
+ AS_HELP_STRING([--enable-default-preferences-peer],
+ [fully qualified class name of default Preferences API Backend]))
+DEFAULT_PREFS_PEER=$enable_default_preferences_peer
+if test "$DEFAULT_PREFS_PEER" = ""; then
+ DEFAULT_PREFS_PEER=gnu.java.util.prefs.FileBasedFactory
+fi
+dnl AC_SUBST(DEFAULT_PREFS_PEER)
+
+dnl ---
dnl GConf native peer (enabled by default)
dnl ---
AC_ARG_ENABLE([gconf-peer],
@@ -100,7 +112,6 @@
dnl ---
AC_ARG_ENABLE([gconf-peers],,AC_MSG_ERROR([No --enable-gconf-peers (or --disable-gconf-peers) option; you want --enable-gconf-peer]))
-
dnl
dnl Whether to compile with -Werror or not (disabled by default)
dnl
@@ -456,6 +467,13 @@
PKG_CHECK_MODULES(GCONF, gconf-2.0 >= 2.11.2)
AC_SUBST(GCONF_CFLAGS)
AC_SUBST(GCONF_LIBS)
+dnl check if the config value was given form the command line,
+dnl if not, overwrite the default if we have the gconf backend
+dnl compiled in
+USE_GCONF_PREFS_PEER=$enable_default_preferences_peer
+if test "$USE_GCONF_PREFS_PEER" = ""; then
+ DEFAULT_PREFS_PEER=gnu.java.util.prefs.GConfBasedFactory
+fi
fi
dnl Check for AWT related Qt4
@@ -745,6 +763,10 @@
fi
AM_CONDITIONAL(ENABLE_LOCAL_SOCKETS, test "x$ENABLE_LOCAL_SOCKETS" = "xyes")
+dnl ---
+dnl Add the default preference peer
+dnl ---
+AC_SUBST(DEFAULT_PREFS_PEER)
dnl ---
dnl output files
Index: gnu/classpath/Configuration.java.in
===
RCS file: /sources/classpath/classpath/gnu/classpath/Configuration.java.in,v
retrieving revision 1.18
diff -u -r1.18 Configuration.java.in
--- gnu/classpath/Configuration.java.in 25 May 2006 15:29:36 - 1.18
+++ gnu/classpath/Configuration.java.in 1 Jul 2006 22:29:15 -
@@ -84,6 +84,14 @@
*/
String default_awt_peer_toolkit = "@default_toolkit@";
+ /**
+ * This flag is used by the Preference API to define the implementation
+ * to use
+ * Actually, the value of DEFAULT_PREFS_P
Re: Random list of AWT TODOs
On Sat, 2006-07-01 at 10:53 +0100, Andrew John Hughes wrote: > Wasn't there talk a while back about having an ImageMagick ImageIO > plugin? I don't know what happened to it, but this would handle a lot > of these obscure formats. Yup. Still, pure-java plugins are still desirable though, I'm not really sure the need for an ImageMagick plugin is as great now that most of the usual suspects (GIF/PNG/JPEG) are coming along in pure java. > Is there also no way that Gtk+ or Qt image support could be leveraged > for our purposes? Yes, we currently do use this, there's a IIO plugin based on Gdk-pixbuf (which sucks, however.. something's wrong with it.) and both the Toolkits use the native libraries for createImage(). However, neither lib is really that great; Qt supports PNG/JPEG/GIF and Gdk has additional support for pcx, ras, ico, wmf and xpm/xbm.* None of which is really a hard format to support. (Actually I might have a PCX decoder lying around somewhere that I wrote 10 years ago (when that was still a popular format)) /Sven
RFC about making the gconf preference backend the default
Hopefully, today few fixes will be finally in the cvs, so the next question is: How to make this backend the default without breaking things? There are 3 solution possibile, two of which are fine : * To add a new defaultFactoryClass to the java.util.prefs.Preference An attempt is made to load this class by name, if it fails then a default backend (FileBased) is instantiated. This approach adds a few lines of code that pollute a bit the implementation, so it is just listed here, but I don't like it. * To add a configuration property to gnu.classpath.Configuration That is, if the gconf backend is not built, this property is not set at all, so everything is just like always. Right now this is what I would do. * To add a property file to resources/META-INF. This one makes sense as the preference api is not different by concept from the sound api, and sound api configurations are there. But there is a problem with it, as far as i understand it, this property would be valid always, being the gconf backend built or not. This means that each time a preference is instantiated, the first test to see if the java.util.prefs.PreferencesFactory system property is defined would throw an exception (the property is always defined) if the gconf backend is not available. It then reverts to the FileBased, but there is a small performance impact here. On system where the gconf backend is not used, maybe for performance reasons, this may be annoying. What do you think it would be the best? Mark, Tom? Thanks, Mario -- 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/ signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Re: [cp-patches] FYI: X peers
On Sat, Jul 01, 2006 at 08:22:46PM +1000, Raif S. Naffah wrote: > hello Michael, > > On Saturday 01 July 2006 20:05, Michael Koch wrote: > > On Sat, Jul 01, 2006 at 10:33:10AM +0200, Roman Kennke wrote: > > > Am Samstag, den 01.07.2006, 09:24 +1000 schrieb Raif S. Naffah: > > > > On Friday 30 June 2006 01:27, Roman Kennke wrote: > > > > > I checked in the Escher-based X peers and added some configury > > > > > for enabling it. To build the X peers you need the most recent > > > > > Escher library, to be found here: > > > > > > > > > > http://kennke.org/~roman/escher-0.3.0.jar > > > > > > > > > > Configure with: --with-escher=/path/to/escher-0.3.0.jar > > > > > --enable-local-sockets > > > > > > > > would it make sense to create a new folder, say "external-jars" > > > > and include the latest escher (and other java-only external > > > > dependencies) jar(s) there. --with-escher can use that > > > > jar/location by default, otherwise the full path to a > > > > distro's/user's location of that jar can be fed to configure. > > > > > > This makes sense. I am all for it. > > > > > > Mark proposed to put jars that are (optionally) needed for > > > classpath on http://builder.classpath.org/ somewhere. What do > > > others think? > > > > Don't put jars without sources into classpath releases. Otherwise > > Distros will need to alter the upstream tarball and remove this. And > > altering removes the feature that people can easily check if the > > upstream sources used by a distro is really what upstream released. > > would including the jar of the sources --e.g. escher-0.3.0.jar and > escher-0.3.0-src.jar-- address that concern. Not for Debian as this makes it impossible to patch security issues easily. Cheers, Michael -- http://www.worldforge.org/
Re: [cp-patches] FYI: X peers
hello Michael, On Saturday 01 July 2006 20:05, Michael Koch wrote: > On Sat, Jul 01, 2006 at 10:33:10AM +0200, Roman Kennke wrote: > > Am Samstag, den 01.07.2006, 09:24 +1000 schrieb Raif S. Naffah: > > > On Friday 30 June 2006 01:27, Roman Kennke wrote: > > > > I checked in the Escher-based X peers and added some configury > > > > for enabling it. To build the X peers you need the most recent > > > > Escher library, to be found here: > > > > > > > > http://kennke.org/~roman/escher-0.3.0.jar > > > > > > > > Configure with: --with-escher=/path/to/escher-0.3.0.jar > > > > --enable-local-sockets > > > > > > would it make sense to create a new folder, say "external-jars" > > > and include the latest escher (and other java-only external > > > dependencies) jar(s) there. --with-escher can use that > > > jar/location by default, otherwise the full path to a > > > distro's/user's location of that jar can be fed to configure. > > > > This makes sense. I am all for it. > > > > Mark proposed to put jars that are (optionally) needed for > > classpath on http://builder.classpath.org/ somewhere. What do > > others think? > > Don't put jars without sources into classpath releases. Otherwise > Distros will need to alter the upstream tarball and remove this. And > altering removes the feature that people can easily check if the > upstream sources used by a distro is really what upstream released. would including the jar of the sources --e.g. escher-0.3.0.jar and escher-0.3.0-src.jar-- address that concern. cheers; rsn pgpMCTxdlwulF.pgp Description: PGP signature
Re: [cp-patches] FYI: X peers
On Sat, Jul 01, 2006 at 10:33:10AM +0200, Roman Kennke wrote: > Hi Raif, > > Am Samstag, den 01.07.2006, 09:24 +1000 schrieb Raif S. Naffah: > > hello Roman, > > > > On Friday 30 June 2006 01:27, Roman Kennke wrote: > > > I checked in the Escher-based X peers and added some configury for > > > enabling it. To build the X peers you need the most recent Escher > > > library, to be found here: > > > > > > http://kennke.org/~roman/escher-0.3.0.jar > > > > > > Configure with: --with-escher=/path/to/escher-0.3.0.jar > > > --enable-local-sockets > > > > would it make sense to create a new folder, say "external-jars" and > > include the latest escher (and other java-only external dependencies) > > jar(s) there. --with-escher can use that jar/location by default, > > otherwise the full path to a distro's/user's location of that jar can > > be fed to configure. > > This makes sense. I am all for it. > > Mark proposed to put jars that are (optionally) needed for classpath on > http://builder.classpath.org/ somewhere. What do others think? Don't put jars without sources into classpath releases. Otherwise Distros will need to alter the upstream tarball and remove this. And altering removes the feature that people can easily check if the upstream sources used by a distro is really what upstream released. Michael -- http://www.worldforge.org/
Re: Random list of AWT TODOs
On Sat, 2006-07-01 at 01:09 +0200, Sven de Marothy wrote:
...
> We can never have enough plugins! If anyone wants there's all kinds of
> obscure formats left to support. TIFF, PICT, Targa, ICO, CUR, Sunraster,
> XBM, XPM, PCX, Amiga IFF. Whatever you feel like (some of these are
> really simple).
>
Wasn't there talk a while back about having an ImageMagick ImageIO
plugin? I don't know what happened to it, but this would handle a lot
of these obscure formats.
Is there also no way that Gtk+ or Qt image support could be leveraged
for our purposes?
> /Sven
>
Thanks,
--
Andrew :-)
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }
signature.asc
Description: This is a digitally signed message part
Re: [cp-patches] FYI: X peers
Hi Raif, Am Samstag, den 01.07.2006, 09:24 +1000 schrieb Raif S. Naffah: > hello Roman, > > On Friday 30 June 2006 01:27, Roman Kennke wrote: > > I checked in the Escher-based X peers and added some configury for > > enabling it. To build the X peers you need the most recent Escher > > library, to be found here: > > > > http://kennke.org/~roman/escher-0.3.0.jar > > > > Configure with: --with-escher=/path/to/escher-0.3.0.jar > > --enable-local-sockets > > would it make sense to create a new folder, say "external-jars" and > include the latest escher (and other java-only external dependencies) > jar(s) there. --with-escher can use that jar/location by default, > otherwise the full path to a distro's/user's location of that jar can > be fed to configure. This makes sense. I am all for it. Mark proposed to put jars that are (optionally) needed for classpath on http://builder.classpath.org/ somewhere. What do others think? /Roman -- “Improvement makes straight roads, but the crooked roads, without Improvement, are roads of Genius.” - William Blake signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Java2d Benchmarking
On Fri, 2006-06-30 at 16:16 -0400, Francis Kung wrote: > To finish off this topic, I've also created a benchmarker in native code > using a GTK widget - with some interesting results. I've included the > detailed results below, but it seems that JNI overhead is doubling the > times for simple java2d operations. Which VM was that? Could you do that timings with different VMs? I'd be interested... TWISTI
