What is the cause for classpath mismatch between compile-time and run-time in a multi-threaded application?

Question

I am writing a Swing desktop application. I compile my program using:

C:\MyJavaPrograms\src>"C:\Program Files\Java\jdk1.7.0_04\bin\javac" SVNTool.java -cp ".;C:\parsers\commons\commons-lang-2.4.jar;C:\parsers\svnkit-1.7.4-v1\lib\svnkit-cli-1.7.4-v1.jar;C:\parsers\svnkit-1.7.4-v1\lib\svnkit-1.7.4-v1.jar"

and I invoke my program using:

C:\MyJavaPrograms\src>"C:\Program Files\Java\jdk1.7.0_04\bin\java" SVNTool -cp ".;C:\parsers\commons\commons-lang-2.4.jar;C:\parsers\svnkit-1.7.4-v1\lib\svnkit-cli-1.7.4-v1.jar;C:\parsers\svnkit-1.7.4-v1\lib\svnkit-1.7.4-v1.jar"

It compiles fine. It starts fine. But when I click on the button, it creates a SwingWorker thread, but this thread failed with NoClassDefFoundError.

I've searched the net, and been able to get around the problem by adding some jar files to the CLASSPATH environment variable using:

C:\MyJavaPrograms\src>set CLASSPATH=%CLASSPATH%;C:\parsers\svnkit-1.7.4-v1\lib\svnkit-1.7.4-v1.jar;C:\parsers\svnkit-1.7.4-v1\lib\svnkit-cli-1.7.4-v1.jar;C:\parsers\commons\commons-lang-2.4.jar

So, what causes the classpath mismatch between compile-time and run-time in a multi-threaded Swing application? Is there a way to make all environment variables and command-line options available to threads?

Answer 1

Threads have nothing to do with your problem. Suppose you use a class Foo from library A.jar in your source file. To compile your class, you need A.jar in the classpath, for the compiler to be able to know about Foo, its methods, fields, etc. But if the code of Foo relies on another class Bar which is in B.jar, you will also need B.jar in the runtime classpath.

In short, you only need the direct dependencies in the classpath to compile. But you need all the transitive dependencies in the classpath to run the program.

You should not mess with the CLASSPATH environment variable. Always use the -cp option to set the classpath of your program.