How about storing them in the database? Always works for me.

i saw the exact same issue, and went through many of the same steps. our application is exploded in the filesystem, so we hoped to be able to change one class and not have to redploy the whole thing. this interesting side effect caused us the same headaches of having to redeploy anything that may have used our Constants class.

1. taking "final" off keeps it from happening, but also then doesn't protect it from accidental changes.

2. using new String("principal") would have avoided the actual value being inlined, since it's more dynamic.

3. externalizing the strings in the Constants object into a props file can fix this as well, and allows reconfiguration without recompilation.

this is an odd case where the compiler inlines the actual value instead of the normal reference to the object. I'm not sure ant should have been expected to recognize that to know to recompile. everything else is dynamically linked at runtime, so it normally wouldn't have required a recompile.

Dude, ant and javac do pretty much NO dependancy analysis. There is no -MM for javac that will let you actually figure out the real dependancies, even the static ones. Simple fact is, if you change Constants.java, every class that refers to it must be recompiled. A real build system would figure that out for you. Unfortunately, Java has no such thing (available for C since the 80s).

I've been caught by this before, too. It's a real killer when a vendor provides their own version of a "standard" API with all the right methods and variables, but different values for a few key constants.

From the JLS, section 13.4.8, "The best way to avoid problems with 'inconstant constants' in widely-distributed code is to declare as compile time constants only values which truly are unlikely ever to change."

http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#45139

Section 15.28, explains what is and isn't compiled into a class as a literal value:
http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#5313

1. Ant has a depend task that does calculate dependencies when you change a class.
Quicker than doing a full rebuild.

2. Stuff for distribution to a live server really, really should be compiled from a fresh checkout from source control though - thereby forcing a clean build every time.

3. Constants.java, I remember the meeting at work where we all decided they were a crap idea and scrapped them - joy. :-)

There *is* a build system for Java that (I think) would handle this: it's called Javamake (http://developers.sun.com/dev/coolstuff/javamake).

Simon, I bet it was not so much the fact you got to say "I told you so" as much as the look of glee and self-richeousness on your face that nearly got you lynched at work ;-)

Yup, I think that fragging the build directory and doing a rebuild is the safest way.

Nuke the site from orbit. It's the only way to be sure. ;-)

Thanks for the tips, guys.

And Mark - I *know* that people who are always right can be annoying, but I can't help it. ;-)

Exposing any constant from any class can cause this issue.
I don't see how putting constants in meaningful classes would help with this issue.

This makes your I told you so wrong.

I think you should do real builds from a clean directory to prevent other potential issues.

I would say you learned less than would be ideal.

Hey, lighten up, Brendan. ;-) Yes, I realise that *all* constants are potentially affected by this - but in our case, the constant was only used in one place, so having it in the client class *would* have helped.

But as I said: "Make your dist target dependent on your clean target" is the real fix for this.