Java get jar version

Get a JAR Version Programmatically in Java

A jar file is simply a group of class files and their associated resources compressed in one file. When a defect occurs, one of the first questions we ask is what is the deployed version of a specific jar file During an application startup, it might be a good idea to log the version numbers of all used jars. This can be very useful for debugging problems later on. Some high-level information about a jar can be found in the MANIFEST file, which is basically, a text file included with each jar. The MANIFEST file usually includes version information. We can get this information programmatically using methods of the Package class.

How to read manifest file from jar using java

For example, we can have a method, called during the application startup, that gets the version information from the Manifest. Let’s suppose that our application is using a Student object, whose class is in a separate jar

public void getVersionFromManifest()< //we need to build an instance of Student, whose class is in the target jar Student object = new Student(); //get the corresponding package object Package objPackage = object.getClass().getPackage(); //getting information from the package object System.out.println("Package Implementation version: " +objPackage.getImplementationVersion()); System.out.println("Package specification version: " +objPackage.getSpecificationVersion()); >

What is the Difference between Specification version and Implementation version?

  • getImplementationVersion returns t he version of this implementation. It consists of any string assigned by the vendor of this implementation and does not have any particular syntax specified or expected by the Java runtime
  • getSpecificationVersion : Returns the version number of the specification that this package implements. This version string must be a sequence of non-negative decimal integers separated by “.”‘s and may have leading zeros.
Читайте также:  Get call stack python

Источник

Guide to Find the Java .class Version

announcement - icon

The Kubernetes ecosystem is huge and quite complex, so it’s easy to forget about costs when trying out all of the exciting tools.

To avoid overspending on your Kubernetes cluster, definitely have a look at the free K8s cost monitoring tool from the automation platform CAST AI. You can view your costs in real time, allocate them, calculate burn rates for projects, spot anomalies or spikes, and get insightful reports you can share with your team.

Connect your cluster and start monitoring your K8s costs right away:

We rely on other people’s code in our own work. Every day.

It might be the language you’re writing in, the framework you’re building on, or some esoteric piece of software that does one thing so well you never found the need to implement it yourself.

The problem is, of course, when things fall apart in production — debugging the implementation of a 3rd party library you have no intimate knowledge of is, to say the least, tricky.

Lightrun is a new kind of debugger.

It’s one geared specifically towards real-life production environments. Using Lightrun, you can drill down into running applications, including 3rd party dependencies, with real-time logs, snapshots, and metrics.

Learn more in this quick, 5-minute Lightrun tutorial:

announcement - icon

Slow MySQL query performance is all too common. Of course it is. A good way to go is, naturally, a dedicated profiler that actually understands the ins and outs of MySQL.

The Jet Profiler was built for MySQL only, so it can do things like real-time query performance, focus on most used tables or most frequent queries, quickly identify performance issues and basically help you optimize your queries.

Critically, it has very minimal impact on your server’s performance, with most of the profiling work done separately — so it needs no server changes, agents or separate services.

Basically, you install the desktop application, connect to your MySQL server, hit the record button, and you’ll have results within minutes:

announcement - icon

DbSchema is a super-flexible database designer, which can take you from designing the DB with your team all the way to safely deploying the schema.

The way it does all of that is by using a design model, a database-independent image of the schema, which can be shared in a team using GIT and compared or deployed on to any database.

And, of course, it can be heavily visual, allowing you to interact with the database using diagrams, visually compose queries, explore the data, generate random data, import data or build HTML5 database reports.

announcement - icon

The Kubernetes ecosystem is huge and quite complex, so it’s easy to forget about costs when trying out all of the exciting tools.

To avoid overspending on your Kubernetes cluster, definitely have a look at the free K8s cost monitoring tool from the automation platform CAST AI. You can view your costs in real time, allocate them, calculate burn rates for projects, spot anomalies or spikes, and get insightful reports you can share with your team.

Connect your cluster and start monitoring your K8s costs right away:

We’re looking for a new Java technical editor to help review new articles for the site.

1. Overview

In this tutorial, we’ll look at how to find the Java release version for a .class file. Additionally, we’ll look at how to check the Java version in jar files.

2. .class Version in Java

When a Java file is compiled, a .class file is generated. In some cases, we need to find the Java release version of the compiled class file. Each Java major release assigns a major version for the .class file it generates.

In this table, we map the major version number of .class to the version of the JDK where that class version was introduced, and we show the hexadecimal representation of that version number:

Java Release Class Major Version Hex
Java SE 18 62 003e
Java SE 17 61 003d
Java SE 16 60 003c
Java SE 15 59 003b
Java SE 14 58 003a
Java SE 13 57 0039
Java SE 12 56 0038
Java SE 11 55 0037
Java SE 10 54 0036
Java SE 9 53 0035
Java SE 8 52 0034
Java SE 7 51 0033
Java SE 6 50 0032
Java SE 5 49 0031
JDK 1.4 48 0030
JDK 1.3 47 002f
JDK 1.2 46 002e
JDK 1.1 45 002d

3. javap Command for .class Version

Let’s create a simple class and build it with JDK 8:

In order to identify the version of the class file, we can use the Java class file disassembler javap.

Here’s the syntax for the javap command:

Let’s check the version for Sample.class as an example:

javap -verbose Sample //stripped output .. .. .. Compiled from "Sample.java" public class test.Sample minor version: 0 major version: 52 .. .. 

As we can see in the output of the javap command, the major version is 52, indicating that it’s for JDK8.

While javap gives many details, we’re only concerned with the major version.

For any Linux-based system, we can use the following command to obtain only the major version:

javap -verbose Sample | grep major

Similarly, for a Windows system, here’s the command we can use:

javap -verbose Sample | findstr major

This gives us the major version, 52, in our example.

It’s important to note that this version value doesn’t indicate that the application was built with the corresponding JDK. A class file version can be different from the JDK used for compilation.

For example, if we build our code with JDK11, it should produce a .class file that has version 55. But, if we pass -target 8 during compilation, then the .class file will have version 52.

4. hexdump for .class Version

It’s also possible to check the version using any hex editor. Java class file follows a specification. Let’s look at its structure:

Here, the types u1, u2, and u4 represent an unsigned one, two, and four-byte integer, respectively.
The u4 is a magic number identifying the class file format. It has the value 0xCAFEBABE, and the u2 is the major version.

For a Linux-based system, we can use the hexdump utility to parse any .class file:

> hexdump -v Sample.class 0000000 ca fe ba be 00 00 00 34 00 22 07 00 02 01 00 0b 0000010 74 65 73 74 2f 53 61 6d 70 6c 65 07 00 04 01 00 . truncated 

In this example, we compiled using JDK8. The 7 and 8 indexes in the first line provide the major version of the class file. Therefore, 0034 is the hex representation, and JDK8 is the corresponding release number (from the mapping table we saw earlier).

As an alternative, we can directly get the major release version as a decimal with hexdump:

> hexdump -s 7 -n 1 -e '"%d"' Sample.class 52

Here, output 52 is the class version that corresponds to JDK8.

5. Version for jars

A jar file in the Java ecosystem consists of a collection of class files bundled together. In order to find out which Java version the jars are built or compiled, we can extract the jar file and use either javap or hexdump to check the .class file versions.

There is also a MANIFEST.MF file in the jar file, which contains some header information about the JDK used.

For example, the Build-Jdk or Created-By header stores the JDK value depending on how the jar is built:

5. Conclusion

In this article, we learned how to find the Java version for a .class file. We saw the javap and hexdump commands and their usage for finding the version. Additionally, we looked at how to check the Java version in jar files.

announcement - icon

Slow MySQL query performance is all too common. Of course it is. A good way to go is, naturally, a dedicated profiler that actually understands the ins and outs of MySQL.

The Jet Profiler was built for MySQL only, so it can do things like real-time query performance, focus on most used tables or most frequent queries, quickly identify performance issues and basically help you optimize your queries.

Critically, it has very minimal impact on your server’s performance, with most of the profiling work done separately — so it needs no server changes, agents or separate services.

Basically, you install the desktop application, connect to your MySQL server, hit the record button, and you’ll have results within minutes:

Источник

Java get jar version

It’s often important to know which version of a jar file is being used by an application. For example, upon startup, an application might find it useful to log the version numbers of all of its known jars. This can be very useful for debugging problems later on.

The MANIFEST file is a text file included with each jar, which specifies high-level information about its contents. The MANIFEST file usually includes version information. That version information is, in turn, accessible at run time using methods of the Package class.

The following example extracts the name and version of the package containing the class InternetAddress . (If the javax.mail.internet package is not on your class path, you can easily modify this code to examine some other package.)

import javax.mail.internet.InternetAddress; /** Display package name and version information for javax.mail.internet. As long as you can build on object of some known class, you may get its related package info in this way. */ public final class ReadVersion < public static void main(String. args)< ReadVersion readVersion = new ReadVersion(); readVersion.readVersionInfoInManifest(); > public void readVersionInfoInManifest()< //build an object whose class is in the target jar InternetAddress object = new InternetAddress(); //navigate from its class object to a package object Package objPackage = object.getClass().getPackage(); //examine the package object String name = objPackage.getSpecificationTitle(); String version = objPackage.getSpecificationVersion(); //some jars may use 'Implementation Version' entries in the manifest instead System.out.println("Package name: " + name); System.out.println("Package version: " + version); > >
Package name: JavaMail(TM) API Design Specification Package version: 1.3

Java Practices 3.012
© 2023 John O’Hanley
Source Code | Contact | License | RSS
Individual code snippets have a BSD license
Over 1,000,000 unique IPs last year
Last updated 2023-01-03
— In Memoriam : Bill Dirani —

Источник

Java: how to check jar version at runtime

Class loading issues can happen in complex execution environments. Situation gets worst when there are different versions of the same library “loaded” and we are not sure which our application is picking up.

To help debugging this issue, we could check at runtime which version of the library is loaded with the our application.

A code like the following can help:

// Example using HTMLEmail from Apache Commons Email Class theClass = HtmlEmail.class; // Find the path of the compiled class String classPath = theClass.getResource(theClass.getSimpleName() + ".class").toString(); System.out.println("Class: " + classPath); // Find the path of the lib which includes the class String libPath = classPath.substring(0, classPath.lastIndexOf("!")); System.out.println("Lib: " + libPath); // Find the path of the file inside the lib jar String filePath = libPath + "!/META-INF/MANIFEST.MF"; System.out.println("File: " + filePath); // We look at the manifest file, getting two attributes out of it Manifest manifest = new Manifest(new URL(filePath).openStream()); Attributes attr = manifest.getMainAttributes(); System.out.println("Manifest-Version: " + attr.getValue("Manifest-Version")); System.out.println("Implementation-Version: " + attr.getValue("Implementation-Version"));

The above code shows how to find jar file path and how to read the contents of a file (it is usually the Manifest) to read some info from it.

Источник

Оцените статью