Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@jakarta.apache.org Received: (qmail 8860 invoked by uid 500); 28 Sep 2001 13:59:49 -0000 Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Reply-To: ant-user@jakarta.apache.org Delivered-To: mailing list ant-user@jakarta.apache.org Received: (qmail 8844 invoked from network); 28 Sep 2001 13:59:49 -0000 Message-ID: <502326F46B08D41191C400508B6D70C10235C616@nvision01.rubus.com> From: Les Hughes To: "'ant-user@jakarta.apache.org'" Subject: RE: static final string. Date: Fri, 28 Sep 2001 14:56:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Externalise your strings into resouce bundles then nothing needs to be rebuilt if you change your constants :-) > -----Original Message----- > From: Peter Donald [mailto:donaldp@apache.org] > Sent: 28 September 2001 08:31 > To: ant-user@jakarta.apache.org > Subject: Re: static final string. > > > On Fri, 28 Sep 2001 16:17, Tarun Garg wrote: > > public static final String mesg="hello"; > > > > Now class B uses this string for some purpose of its own. > > Lets say it just prints the message. > > class B { > > public static void main(String args[]) > > { > > System.out.println(A.mesg); > > } > > } > > Theres no clean way to do it as it will get inlined in other > class. You could > wrap the constant in another object (because the other object wont be > inlined). You could also put in ugly hacks like one of > > class B > { > private static Class CLASS_HACK_REF = A.class; > } > > or perhaps make it runtime final like > > class A > { > public static final String mesg = > System.getProperty( "some.key.that.not.exist", "hello" ); > } > > or just do clean builds all the times when you notice such changes. > > -- > Cheers, > > Pete > > ---------------------------------------------------------------- > Fools ignore complexity. Pragmatists suffer it. > Some can avoid it. Geniuses remove it. > -- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982 > ---------------------------------------------------------------- >