Re: cleaning up the gnu.classpath.Configuration.java.in file

[Bryce McKinlay]

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