Re: Dependency resolution in Java builds
On Feb 8, 2:26 pm, Markus Gessner <nos...@nospam.com> wrote:
Hello all!
Having recently started working with Java, coming from C++, I am now
taking part in a Java project, the build of which is managed by Maven.
I frequently run into a very basic situation exemplified by the two
follwing classes, each of which is implemented in its own file:
----------------------------------------------------------------------
public interface Foo
{
void method1();
}
public class FooImpl implements Foo
{
void method1() { ; }}
----------------------------------------------------------------------
After compiling, I make the follwing change, i.e., only change the
interface:
----------------------------------------------------------------------
public interface Foo
{
void method1();
void method2();
}
public class FooImpl implements Foo
{
void method1() { ; }}
----------------------------------------------------------------------
When building, I see only a recompilation of Foo.java, which
indicates, that only a simple comparison of the respective timestamps
of *.java and *.class files is undertaken. From my C++-work, based on
gcc/make, I am accustomed to a setup, which in the analogous scenario
for C++ detects the dependence of FooImpl on Foo and initiates a
recompilation of FooImpl as well (in this example leading to a compile
time error).
Moreover, from the Java guys i frequently here something like "when in
doubt, clean the project and rebuild".
Although this is a matter of the build tools rather than the language, I
would like to ask the experienced Java developers out here: is this to
be put up with, or are there build mechanisms obviating this, concisely
taking into account the interdependence of classes (like "gcc -M" in a
make-based build system for C++).
I've been looking for the same thing.
In short, all commonly available build systems suck. It's just a
difference of degree. That includes the idiomatic solution of
"Recursive Make Considered Harmful" with gnu make and gcc -M on c++
code. Ex: Try removing a cpp file, and see if your link output gets
rebuilt. See what happens when you add a new header file which hides
another header file on an include search path.
So, the modern commonly available Java build systems handle even less
of these dependencies than the common "Recursive Make Considered
Harmful" handles. I've been working on my actually incrementally
correct build system on the side which does /correct/ incremental
Java, but don't expect anything soon. (It also relies on Sun JVM's
compiler interface, which isn't Java standard but Sun standard, so
don't expect it to work on other platforms which don't have the Sun
JVM. However, the output bytecode is portable and can run
everywhere.)
I think you'll just have to make do with full clean builds. That's
also the advice I've heard from basically all Java people to whom I've
talked on this subject.
Builds is one of the most under-appreciated aspects of programming.