ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: newbie question: javac not checking build dependencies?
Date Fri, 04 Jan 2002 08:29:27 GMT

----- Original Message -----
From: <>
To: "Ant Users List" <>
Sent: Thursday, January 03, 2002 19:58
Subject: Re: newbie question: javac not checking build dependencies?

> >1) Is it only the static final constants that have this discontinuity in
> >javac's dependency checking? Usually such constants are used as manifest
> >constants, in the old K&R C language sense, and rarely are changed.
> Yes, even though javac has other problems [see the post by Misha
> Dmitriev], none of them are insurmountable, except for this one [AFAIK].
> The static final issue may not be a big deal to some, but I use ANT for
> building enterprise software [$$$] and make damn sure the production
> builds are produced out of a "clean" state so that nothing is incremental.
> >2) I couldn't find any documentation to support that this is possibly a
> >language issue, that it is consistent with the language definition.
> Anybody
> >disagree?
> Perhaps my statement could have been more precise: this issue is caused by
> the combination of Java language, .class format, and Java bytecode specs.
> Ostensibly, at the language level this allows us to have a limited support
> for conditional compilation [i.e. the block in "if (DEBUG) {....}" does
> not result in any bytecode emitted if DEBUG is static final but not so if
> it is merely static or has a runtime init expression]. At the .class and
> bytecode leveIs this conversion of constants to literals makes tableswitch
> and lookupswitch opcodes work [used for Java "case" statements]. I can't
> provide any "official" spec references right now but you can check out
> "Compile-Time Resolution of Constants" in chapter 8 of "Inside the JVM" by
> Bill Venners.

I always thought it was there for compile time optimisation of things;
conditional compilation simply being a side effect publicised as the 'how to
live without #ifdef' solution.

Without compile time evaluation of constants you wouldnt be able to precalc
functions like


instead it would get done every time encountered. So it is a good thing. But
it'd be nice if origin information is preserved, which was what Misha
hinted. Personally I'd prefer extensible introspectable metadata like in C#,
but that's another issue.

You are free to write your code without such constants, using methods you
write like getPI() to ensure that they are always evaluated at run time, and
so are explicitly linked in. Sometimes we do this, but I still clean build
on a regular basis.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message