Home

JarHC - JAR Health Check

JarHC is a static analysis tool to help you find your way through "JAR hell" or "classpath hell".

Its main purpose is to analyze a set of JAR files (*.jar) and check whether they are compatible on a binary level, and whether they contain any "unpleasant surprises" for you.

Motivation

If you don't know what JAR hell is, check out these articles:

• What is JAR Hell? at DZone
• JAR Hell at CodeFX

How JarHC works

The input to JarHC is a set of JAR files, called the "classpath". This is usually a bunch of third-party libraries used in a Java project. JarHC analyzes these JAR files and generates a report for various aspects:

• JAR Files: List of JAR files found in classpath with information like file size, number of classes and resources, whether the JAR file is a multi-release JAR or a JPMS module, the SHA-1 checksum, and Maven artifact coordinates (if the checksum is found on Maven Central).
• Class Versions: Java versions for which the classes in the JAR files have been compiled. This allows you to find the "minimum Java version" required to run all classes.
• JAR Dependencies: Dependencies between JAR files ("uses" and "used by").
• Packages: List of packages per JAR file. Also checks for split packages (packages found in multiple JAR files) and "fat JARs" (JARs with a mix of very different packages, potentially because multiple JAR files have been merged).
• Duplicate Classes: Java classes which exist in more than one JAR file and Java classes found in the classpath shadowing classes with the same name in the underlying JDK/JRE implementation. Also checks how "similar" those duplicate classes are (exact copy, same API, ...). Resources (files other than Java class files) found in more than one JAR file under the exact same path and name.
• Binary Compatibility: Validates superclass and interface contracts, method calls, and field access. Reports missing classes, methods, or fields. Validates access permissions.
• Blacklist: Use of dangerous, unsafe, unstable, or deprecated classes and methods, like "sun.misc.Unsafe" or "System.exit(...)", or annotations like @Beta or @Deprecated.
• Java Runtime: Information about the Java runtime installation.

Planned:

• Report usage of native code.
• Check if JAR files are signed. Report signing information and validate the signatures.
• Report unused JAR files.
• Check if JAR files have known vulnerabilities (based on NVD database).