Compile time vs Run time Dependency - Java

What is the difference between compile time and run time dependencies in Java? It is related to class path, but how do they differ?

• 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.

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.

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.

Java doesn't actually link anything at compile time. It only verifies the syntax using the matching classes it finds in the CLASSPATH. It's not until runtime that everything gets put together and executed based on the CLASSPATH at that time.

Compiletime dependencies are only the dependencies (other classes) which you use directly in the class you're compiling. Runtime dependencies covers both the direct and indirect dependencies of the class you're running. Thus, runtime dependencies includes dependencies of dependencies and any reflection dependencies like classnames which you have in a String, but are used in Class#forName().

For Java, compile time dependency is your source code's dependency. For instance, if class A calls a method from class B, then A is dependent to B at the compile time since A has to know about B (type of B) to be compiled. The trick here should be this: Compiled code is not a complete and executable code yet. It includes replaceable addresses (symbols, metadata) for the sources which are not yet compiled or existing in external jars. During linking, those addresses must be replaced by actual adresses in the memory. To do it properly, correct symbols/adresses should be created. And this can be done with the type of the class (B). I believe that's the main dependency at the compile time.

Runtime dependency is more related with the actual flow-of-control. It involes actual memory addresses. It's a dependency that you have when your program is running. You need class B details here like implementations, not only the type info. If the class not exists, then you will get RuntimeException and JVM will exit.

Both dependencies, generally and shouldn't, flow the same direction. This is a matter of OO design though.

In C++, compilation is a bit different (not just-in-time) but it has a linker too. So the process might be thought similar to Java I guess.

From @Jason S answer I derive mine with other words, in case it helps:

A runtime dependency of an app is actually a dependency (let's call it L2) of a compile-time dependency (L1) of this app. It may not be declared as a dependency if it won't be used by the app.

• If L2 happens to be used by the app (through L1) while not declared as a dependency, there will be a NoClassDefFoundError.

• If L2 is declared as a compile-time dependency of the app, and not used at runtime, it uselessly makes the jar larger and compile-time longer than needed.

Declaring L2 as a runtime dependency allows the JVM to lazy-load it, only when needed.