Dalibor Topic wrote:
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.
I agree completely. Note that as it was originally conceived, Configuration.DEBUG meant to compile debugging code in to the library. Because it was a final constant, potentially large/expensive debugging code could be completely removed from optimized builds. The idea was that additional, more specific, runtime flags would be used in addition to DEBUG, so that if you built a library with DEBUG you would then also set a system property or something that would enable debugging for the specific feature you're interested in.
But, in hindsight, debuggers are good enough, classpath is relatively bug free :), and the situations where this has been useful are pretty rare. I have no problem with seeing it go.
I also agree that we will be better off moving the other flags to a Classpath.properties file, or, depending on the flag, a System property set by the VM or Classpath itself during initialization.
Bryce
_______________________________________________ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
