Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@apache.org Received: (qmail 34007 invoked from network); 4 Jan 2002 08:29:59 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 4 Jan 2002 08:29:59 -0000 Received: (qmail 25786 invoked by uid 97); 4 Jan 2002 08:30:03 -0000 Delivered-To: qmlist-jakarta-archive-ant-user@jakarta.apache.org Received: (qmail 25762 invoked by uid 97); 4 Jan 2002 08:30:00 -0000 Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Users List" Reply-To: "Ant Users List" Delivered-To: mailing list ant-user@jakarta.apache.org Received: (qmail 25747 invoked from network); 4 Jan 2002 08:30:00 -0000 Message-ID: <005a01c194f9$ee050b00$0801a8c0@cv.hp.com> From: "Steve Loughran" To: "Ant Users List" References: Subject: Re: newbie question: javac not checking build dependencies? Date: Fri, 4 Jan 2002 00:29:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-ECS-MailScanner: Found to be clean X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ----- 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 sqrt(math.sin(4*Math.PI)*Math.E) 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. -steve -- To unsubscribe, e-mail: For additional commands, e-mail: