The problem with the public static final boolean variable is, you have
to edit the source every time you want to change it. With a
preprocessor-style define, you can control it from the compiler or
preprocessor with -D. In other words, I want to build the whole thing
with -DNO_SANITY_CHECKS and then build again without it, and I want
different results without editing every file that has the ifdef in it.
I don't care the mechanism is used, as long as I can control what code
gets output without having to edit the source. I am going to look into it
now.
Paul, I know you were opposed to this sort of thing earlier, but in the
case of 1.1 vs. 1.2 compilation, as well as this sanity check thing, there
is a lot of good that would be done.
--John Keiser
> -----Original Message-----
> From: Bernd Kreimeier [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 04, 1998 6:16 AM
> To: Classpath
> Subject: 1.1 vs. 1.2 revisited
>
>
> John Keiser writes:
> > I have one use for conditional compilation of Java classes
> that I would
> > like to employ. I do a lot of sanity checking in the
> JavaBeans classes, and
> > that code is rather bulky. -DNO_SANITY_CHECKS would be kinda nice.
> > There must be some macro preprocessor out there, m4 or
> something (I don't
> > know much about m4).
>
> Am I missing something here? I was under the impression
> that Java more or less guarantees that
>
> class Config {
> public static const boolean SANITY_CHECK = false;
> }
>
>
> if( SANITY_CHECK ) {
> // Insanity here.
> }
>
> will provide conditional compilation. I only looked
> at the changes in bytecode size, not the bytecode
> itself, but this seems to work.
>
> I would love to see some template preprocessor for some
> pseudo-Java, but I am not sure that introducing CPP to
> "Glasspath" or any other project to get nothing but
> C-style conditional compilation is a good idea. In
> any case - shouldn't a (free) JavaCC be the tool of
> choice?
>
>
>
> b.
>
>
>
