Compile time vs Run time Dependency - Java

• Compile-time dependency: You need the dependency in your CLASSPATH to compile your artifact. They are produced because you have some kind of "reference" to the dependency hardcoded in your code, such as calling new for some class, extending or implementing something (either directly or indirectly), or a method call using the direct reference.method() notation.

• Run-time dependency: You need the dependency in your CLASSPATH to run your artifact. They are produced because you execute code that accesses the dependency (either in a hardcoded way or via reflection or whatever).

Although compile-time dependency usually implies run-time dependency, you can have a compile-time only dependency. This is based on the fact that Java only links class dependencies on first access to that class, so if you never access a particular class at run-time because a code path is never traversed, Java will ignore both the class and its dependencies.

Example of this

In C.java (generates C.class):

package dependencies;public class C { }

In A.java (generates A.class):

package dependencies;public class A {    public static class B {        public String toString() {            C c = new C();            return c.toString();        }    }    public static void main(String[] args) {        if (args.length > 0) {            B b = new B();            System.out.println(b.toString());        }    }}

In this case, A has a compile-time dependency on C through B, but it will only have a run-time dependency on C if you pass some parameters when executing java dependencies.A, as the JVM will only try to solve B's dependency on C when it gets to execute B b = new B(). This feature allows you to provide at runtime only the dependencies of the classes that you use in your code paths, and ignore the dependencies of the rest of the classes in the artifact.

The compiler needs the right classpath in order to compile calls to a library (compile time dependencies)

The JVM needs the right classpath in order to load the classes in the library you are calling (runtime dependencies).

They may be different in a couple of ways:

1) if your class C1 calls library class L1, and L1 calls library class L2, then C1 has a runtime dependency on L1 and L2, but only a compile time dependency on L1.

2) if your class C1 dynamically instantiates an interface I1 using Class.forName() or some other mechanism, and the implementing class for interface I1 is class L1, then C1 has a runtime dependency on I1 and L1, but only a compile time dependency on I1.

Other "indirect" dependencies which are the same for compile-time and run-time:

3) your class C1 extends library class L1, and L1 implements interface I1 and extends library class L2: C1 has a compile-time dependency on L1, L2, and I1.

4) your class C1 has a method foo(I1 i1) and a method bar(L1 l1) where I1 is an interface and L1 is a class that takes a parameter which is interface I1: C1 has a compile-time dependency on I1 and L1.

Basically, to do anything interesting, your class needs to interface with other classes and interfaces in the classpath. The class/interface graph formed by that set of library interfaces yields the compile-time dependency chain. The library implementations yield the run-time dependency chain. Note that the run-time dependency chain is run-time dependent or fail-slow: if the implementation of L1 sometimes depends on instantiating an object of class L2, and that class only gets instantiated in one particular scenario, then there's no dependency except in that scenario.

An easy example is to look at an api like the servlet api. To make your servlets compile, you need the servlet-api.jar, but at runtime the servlet container provides a servlet api implementation so you do not need to add servlet-api.jar to your runtime class path.