This problem that has bitten me in the ass a few times, and I’d love to hear any bright ideas on how y’all avoid it.<\/p>\n
Suppose you have an interface that defines some useful constants:<\/p>\n
and a class that uses those constants:<\/p>\n All well and good, until you realize that five isn’t really 6, it’s 5. Whoops, change the But, if you’re like the other 99% of the java development world, and you use a build tool, like ant<\/a>, smart enough to look at timestamps, you’ll still get 6 for the output of public interface foo {
\n int five = 6;
\n}<\/code><\/p>\npublic class bar {
\n public static void main(String[]args) {
\n System.out.println(\"five: \"+foo.five);
\n }
\n}<\/code><\/p>\nfoo<\/code> java file and rebuild, right? Well, if you use javac *.java<\/code> to do this (as you might, if you only have the foo<\/code> and bar<\/code> files), then you’ll be alright. <\/p>\njava bar<\/code>. Ant is smart enough to look at the timestamps of .class and .java files to determine which .java files have changed since it last did a compilation. But it is too dumb to realize that the bar<\/code> class has a dependency on foo<\/code>, and should thus be recompiled even though bar.java<\/code> is older than bar.class<\/code>. (I haven’t looked at the byte code, but I expect that the value of five<\/code> is just inlined into the bar<\/code> class because it’s a final variable.) If you’re using a make based build system, I believe you can use javadeps<\/a> to build out the correct dependency list, but I haven’t seen anything similar for ant. Another options is to just remember to blow away your build directory anytime you change your ‘constants’.<\/p>\n