Can a program depend on a library during compilation but not runtime?

Question

I understand the difference between runtime and compile-time and how to differentiate between the two, but I just don\'t see the need to make a distinction between compile-t

Answer 1

To answer the question "how can a program not depend on something at runtime that it depended on during compilation?", let's look at the example of an annotation processor.

Suppose you've written your own annotation processor, and suppose it has a compile-time dependency oncom.google.auto.service:auto-service so that it can use @AutoService. This dependency is only required to compile the annotation processor, but it is not required at runtime: all other projects depending on your annotation processor for processing annotations do not require the dependency on com.google.auto.service:auto-service at runtime (nor at compile-time nor at any other time).

This is not very common, but it happens.

Answer 2

The runtime scope is there to prevent programmers from adding direct dependencies to implementation libraries in the code instead of using abstractions or façades.

In other words, it enforces to use interfaces.

Concrete examples:

1) Your team is using SLF4J over Log4j. You want your programmers to use the SLF4J API, not the Log4j one. Log4j is to be used by SLF4J internally only. Solution:

• Define SLF4J as a regular compile-time dependency
• Define log4j-core and log4j-api as runtime dependecies.

2) Your application is accessing MySQL using JDBC. You want your programmers to code against the standard JDBC abstraction, not directly against the MySQL driver implementation.

• Define mysql-connector-java (MySQL JDBC driver) as a runtime dependency.

Runtime dependencies are hidden during compilation (throwing compile-time errors if your code has a "direct" dependency on them) but are included during execution time and when creating deployable artifacts (WAR files, SHADED jar files, etc.).

Answer 3

At compile time you enables contracts/api that you are expected from your dependencies. (eg: here you just sign for a contract with broadband internet provider) At run-time actually you are using the dependencies. (eg: here you actually are using the broadband internet)

Answer 4

Generally you are right and probasbly it is the ideal situation if runtime and compile time dependencies are identical.

I will give you 2 example when this rule is incorrect.

If class A depends on class B that depends on class C that depends on class D where A is your class and B, C and D are classes from different third party libraries you need only B and C at compile time and you need also D at runtime. Often programs use dynamic class loading. In this case you do not need classes dynamically loaded by library you are using at compile time. Moreover often the library chooses which implementation to use at runtime. For example SLF4J or Commons Logging can change the target log implementation at runtime. You need only SSL4J itself at compile time.

Opposite example when you need more dependencies at compile time than at runtime. Think that you are developing application that has to work at different environments or operating systems. You need all platform specific libraries at compile time and only libraries needed for current environment at runtime.

I hope my explanations help.