[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
cleaning up the gnu.classpath.Configuration.java.in file
From: |
Dalibor Topic |
Subject: |
cleaning up the gnu.classpath.Configuration.java.in file |
Date: |
Fri, 11 Feb 2005 11:05:00 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 |
Hi all,
after spending a good deal of time trying to get the
gnu.classpath.Configuration.java to build and work as it should, I feel
like eradicating the class completely would be the best thing to happen
to it. Here are the reasons:
a) It attracts code rot.
The constant JAVA_LANG_SYSTEM_EXPLICIT_INITIALIZATION has been rotting
there for more than two months [1]. I'd like to remove it, if noone minds.
b) It attracts people to put stuff in there that's only used once by a
single class, instead of putting right into the class.
default_awt_peer_toolkit, for example, is used only by Toolkit. It would
make more sense to me if it was maintained there, then, as well. It may
make even more sense to turn it into a real GNU Classpath property,
though that seems a bit over-flexible at the moment, as no other toolkit
is in GNU Classpath to select from. So I'd like to remove
default_awt_toolkit and simply set Toolkit.default_toolkit_name striaght
to "gnu.java.awt.peer.gtk.GtkToolkit".
c) It attracts people to put stuff that belongs into a VMSomeClass
interface into the global configuration file.
HAVE_NATIVE_GET_PROXY_CLASS and friends are neither configurable via the
configure script, nor are they used anywhere outside
java.lang.reflection.Proxy. As they are both VM and Proxy specific, they
really belong into java.lang.reflect.VMProxy. So when someone one day
removes all instances of use of VMProxy.HAVE_NATIVE_GET_PROXY_CLASS,
chances are the person will be more likely to look at VMProxy rather
than if the person removed all instances of HAVE_NATIVE_GET_PROXY_CLASS
without the VmProxy prefix.
The latter does not suggest to look somewhere else for the VM-specific
interface constant, so over time we get code rot like in a).
d) It attracts overly generic constants
Configuration.DEBUG is used a handful of times, in pretty unreleted
classes to do the same job that's done in other classes using a private
constant with the same name. It's pretty confusing, as the decription of
the option that generates LIBDEBUG (which is assigned to
Configuration.DEBUG) asks to be defined to 1 if one wants "native
library runtime debugging code enabled", which java code is not. So I'd
like to replace the few uses of Configuration.DEBUG with private DEBUG
constants, like in the large majority of code in the library.
e) It attracts putting things in an interface that belong into a
properties file
CLASSPATH_HOME, CLASSPATH_VERSION, INIT_LOAD_LIBRARY and
GTK_CAIRO_ENABLED make more sense as properties, than hardcoding them in
the class library. The Strings don't give the compiler a chance to
optimize anything away, while the booleans are used in such rare
conditions, that the optimization effect is presumably negligible.
On the other hand, not hardcoding them makes it easier to share one
classpath jar file among various VMs in a distribution, for example
those with different INIT_LOAD_LIBRARIES requirements.
So I'd like to move those constants to a classpath.properties file, to
be created by the configure script.
Then we'd be relieved from the Configuration.java.in file, and it could
go into the Attic along with other worthy files from the good old days.
I'd love to get rid of this file as soon as possible as it messed up my
distcheck when I merged it into kaffe, and automake is running crazy in
circles with it, which is no fun to watch. [2]
cheers,
dalibor topic
[1]
http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/lang/System.java.diff?r1=1.44&r2=1.45
was the removal of last (and only) use.
[2] mkdir -p --
/var/tmp/topic/build/kaffe-1.1.x-cvs/_build/kaffe-1.1.x-cvs/libraries/javalib/gnu/getopt
/var/tmp/topic/build/kaffe-1.1.x-cvs/_build/kaffe-1.1.x-cvs/libraries/javalib/gnu/regexp
/var/tmp/topic/build/kaffe-1.1.x-cvs/_build/kaffe-1.1.x-cvs/libraries/javalib/kaffe/io
cp: cannot create regular file
`/var/tmp/topic/build/kaffe-1.1.x-cvs/_build/kaffe-1.1.x-cvs/libraries/javalib/gnu/classpath/Configuration.java.in':
Permission denied
in other words ... whatever :)
- cleaning up the gnu.classpath.Configuration.java.in file,
Dalibor Topic <=