MMS • Shaaf Syed
Article originally posted on InfoQ. Visit InfoQ
A new Java JAR inspection and insights tool, called Jarviz, helps developers find different bytecode versions in a JAR, querying it for attributes, services, and more. Sonatype statistics show that there are 517,231 unique artifacts on Maven Central. At the same time, a new version of Java is released by the OpenJDK community every six months, with each LTS release supported for a minimum of two years.
A Java application could use a lot of different libraries, and those libraries could depend on many others. It can be challenging to keep track of all the different artifacts a Java application depends on relative to the various Java versions it can run on. Jarviz sets out to solve this problem by providing a user-friendly CLI to inspect different JAR files and their dependencies.
Executing the following command would check which classes in the JAR file use a particular bytecode version. In this example, the command will show that Java 11 has bytecode version 53:
$ jarviz bytecode show --gav com.fasterxml.jackson.core:jackson-core:2.14.1 --bytecode-version 53 --details
Versioned classes 9. Bytecode version: 53 total: 1
module-info
Or check all the different bytecode versions that exist in the JAR file:
$ jarviz bytecode show --gav com.fasterxml.jackson.core:jackson-core:2.14.1
Unversioned classes. Bytecode version: 52 total: 160
Versioned classes 9. Bytecode version: 53 total: 1
InfoQ interviewed Jarviz creator Andres Almiray on the occasion of the recent 0.2.0 release to discuss Jarviz and its future.
InfoQ: What was the inspiration to start this project?
Andres Almiray: I write CLI tools and libraries as a hobby. Of the many aspects that I have to take care of is binary compatibility. We know that tools and libraries may bring additional dependencies, which in turn must conform to the binary compatibility rules set in place. Say, for example, that a Maven plugin sets its bytecode baseline to Java 8 (bytecode 52). This means none of its dependencies must exceed that number. If that were to be the case, then consumers of the plugin would be forced to upgrade to the next compatible Java version, and sometimes that cannot happen for various reasons.
Furthermore, classes have the final say no matter what the source or the documentation may state. The build might pull the wrong dependency without knowing, or a shaded dependency may bring invalid classes. There are other ways in which a class may find its way into a JAR and break your bytecode expectations. This is why inspecting JAR files is the only way to be sure.
Jarviz was created to solve these issues in mind. Once the plumbing mechanism was put in place to inspect a JAR file, it became obvious that additional data could be queried, for example, if a given manifest entry were to be available and extract its value or the names of declarative services (typically found inside
/META-INF/services
) and their given implementations.
InfoQ: Does the Java community need more tools like Jarviz?
Almiray: I think so, yes. I would love to see a resurgence of command-line tools written in Java and/or targeting the JVM ecosystem. GraalVM Native Image makes it simple to build single platform-specific executables if one wants to run said commands without a JVM or if startup time and memory footprint prove to be performance drivers.
Alternatively, these tools could be bundled with a minimal Java Runtime crafted using
jlink
. There is no shortage of options for packaging these kinds of tools. The vastness and reach of Java libraries found at Maven Central, paired with the richness of the Java Standard Library, should make it easier to implement a particular use case.
InfoQ: Are there any specific features that you would like to implement in the near future?
Almiray: Yes, specifically handling multi-resource JARs and Java modules. In this regard, recent versions of the Java SDK (Java 17 and onwards) enhance the capabilities provided by its tools, such as the JAR tool. This is fine as long as you have access to a Java 17 SDK, but if you are stuck with older versions well, then you may be out of luck. Jarviz sets Java 11 as its baseline, thus making it easier for those running older JVMs.
Moreover, reporting at the moment occurs using a plain-text format. It could be enhanced to support additional formats such as JSON, XML, YAML, markdown tables, or others.
InfoQ: What is next for Jarviz?
Almiray: Besides new features, the next step would be offering more options to execute the tool. If you look at the version 0.1.0 release, you’ll notice there are three types of deliverables: universal (plain zip/tar) and a tool-provider as a single executable JAR which requires a Java 11 runtime, and standalone, which includes a bundled Java runtime for 8 different platforms Additional deliverables could be native executables crafted with GraalVM Native Image.
Jarviz also offers more advanced features, such as inspecting or querying the contents of the MANIFEST.MF
file based on attributes. In most cases, it is important to see which services the JAR file depends on without needing to unarchive it and search through it.