1

Is there a way to determine if all needed runtime dependencies for a Java application exist in the class path?

I guess running the application multiple times through all the possible execution paths, and checking no "Class not found" exceptions are thrown would one way to make sure all needed classes are in the class path, but that's not always an option for complex applications of course.

J B
  • 311
  • 4
  • 12
  • 1
    If it's that vital, create a fat JAR: https://stackoverflow.com/questions/574594/how-can-i-create-an-executable-jar-with-dependencies-using-maven – Michael Jan 18 '18 at 15:16

4 Answers4

2

You can use tools jdeps for check dependencies in classpath (if before JDK 9), but it can not help you check all source code, only apply with standalone Java class.

Since JDK 9, you can use modular, with keyword requires inside file module-info.java of module. When compiling Java code, it will check dependencies at compile time.

Read more at

https://www.oracle.com/corporate/features/understanding-java-9-modules.html (Search keyword requires)

https://docs.oracle.com/javase/8/docs/technotes/tools/unix/jdeps.html

Vy Do
  • 46,709
  • 59
  • 215
  • 313
2

Is there a way to determine if all needed runtime dependencies for a Java application exist in the class path?

This is not possible in the general case, because it may be that the accessible class files do not contain all the necessary information. In particular, it is possible for an application to depend on classes that are identified to it only at runtime.

The java command -- though not itself implemented in Java -- is illustrative: it accepts the name of the application's main class as a command-line argument. Therefore, what classes it will require cannot be statically determined; they depend on the command line arguments. Java programs can do similar, and such use is routine in certain areas. For example, JDBC drivers are often loaded reflectively by name, and it is common for the driver name to be recorded in a configuration file instead of hard-coded.

On the flip side, it is possible for classloaders to load classes from remote sources and to synthesize classes on the fly, so even if you don't see a particular class anywhere on the filesystem, it is difficult to be certain that it will not be available at runtime. And there are other fun classloader games that are sometimes played.

Now, for applications that are not subject to class loading considerations such as the above, it is possible, in principle, to determine all the needed classes by recursive examination starting with the application's main class, and to attempt to load all those classes to verify that they are available. Even then, however, it is possible to run into trouble with mismatched versions of classes, so that even though all the wanted (by name) classes are available, they do not work properly together.

So overall, the only sure way to perform an ex post facto determination such as you describe is to test all code paths, with all relevant data variations that can affect which classes are needed.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
-2

Sounds like you need a linter. I'm unsure what IDE you're using, but I'd recommend SonarLint as it's one of the most popular linters out there.

Maltanis
  • 513
  • 1
  • 5
  • 13
-2

I would suggest using a dependency manager like:

Those type of managers download the jars you need and all of the jars they require from a central repository, and does all of this for you.

Stav Saad
  • 589
  • 1
  • 4
  • 13