classpath
[Top][All Lists]
Advanced

[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 :)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]