Re: dependency-detection in java - Take 2

Andreas Leitgeb <avl@xxxxxxxx> writes:
I've got a project tree full of classes (who hasn't?),
some of these contain SFFs, some use SFFs.
Now, someone else of the team checks in com.mycompany.fubar.SomeClass,
and everyone else in the project has it show up as new in
his working space, and rebuild it. (The rebuild might
even be central and automatic). It's a waste of ressources
to recompile the whole tree each time a single .java is
checked in, so we (of course!) use ant.
And now, think this SomeClass that has been checked in might
contain new values for existing SFFs, which are used elsewhere.

Please don't waste your own time with saying, that your SFFs
never change. You just lie to yourself, and your build-process
is unreliable. (or perhaps your project is small enough that
a full-compile doesn't hurt, or you "just know", when to do
a full compile, and when not.
This isn't only about SFFs, but also about classes changing
their interface incompatibly (could be a typo of the developer,
but without compiling the dependents, it may go unnoticed for
a while!)

SFFs should only be used locally, say within a package, so when you rebuild
your SFF, it is not a big hassle to rebuild the package. The problem arises
when you have that constant spread throughout a bigger project. It is, in
effect, a "uncontracted" interface or a global variable, defying all
encapsulation approaches and should be avoided.

Sometimes it can't be avoided fully. These IDL-files with generated constants
are a good example, other external sources, you may not change are others.
You can try and create fascades, i.e. hide the generated code, but provide our
own interface to it, forcing all users of the IDL and it's constant to use a
getter instead.

Even if you get ant or some other semantic analyser to solve that problem for
you, you may still be stuck with the runtime problem, when someone in a
distributed environment compiled against an old constant.

Michael
.