Java file version number

How to fix java.lang.UnsupportedClassVersionError: Bad version number in .class files? Example

«java.lang.UnsupportedClassVersionError: Bad version number in .class file» is a common error in Java programming language which comes when you try to run a Java class file which was compiled by different version of Java compiler than then JRE version you are using to run it. In our last article, we discussed that how to resolve Java.lang.UnSupportedClassVersionError and found that it comes when a major and minor version of the class is not supported by Java virtual machine or JRE running the program. Though » java.lang.UnsupportedClassVersionError: Bad version number in .class file » is a little different than that of its manifestation and Cause, both are related to the mismatch in compiler javac and runtime java version.

The UnsupportedClassVersionError is not as difficult as Java.lang.OutOfMemoryError and neither its solution is too complex but what is hard is thinking in the right direction because the cause of different types of UnsupportedClassVersionError is different.

Cause of java.lang.UnsupportedClassVersionError: Bad version number in .class file

» java.lang.UnsupportedClassVersionError: Bad version number in .class file » comes when you compile a Java class in higher version of Java Compiler and run it on a lower version of Java virtual machine or JRE. For example, if you have compiled your Java class using Java SE 17 compiler and then you try to run it on Java SE 11 or Java SE 8 then you will get this error.

Similarly, you can get the Bad Version number in class file error if you compile your Java source file by Java SE 11 compiler, which comes when you install Java 11 JDK in your machine and then you try to run it but there is a lower version of JRE is configured in PATH or it comes first in the PATH if you have multiple JRE installed in your machine.

The key here is you need to run your Java program or class file in the version greater than or equal to the version which is used to compile your Java program. Java is backward compatible which means a JAR file created by Java 1 will still work in Java SE 17 but a JAR File created by Java SE 17 cannot work in Java 1 as it doesn’t have all the new enhancements.

It’s more of a common sense than any rocket science but just finding which version of Java is used to compile and run the program can take time and requires experienced to troubleshoot and think in the right direction.

java.lang.UnsupportedClassVersionError: Bad version number in .class file

To understand this UnsupportedClassVersionError better let’s reproduce it via a simple example in Java:

2) Run Loan.class with JRE 1.5 or any version lower than Java 17 like Java 8 or Java 11. I have used Java 5 here

Solution:

Now you know that your source is compiled for a higher version of JRE or Java runtime if it doesn’t work in JDK 1.5 then try to run on JDK 1.6 and you will be able to remove «Bad version number in .class file«. The same problem can come to any other Java version for example, a class file compiled by JDK 11 will not run on Java 8 or Java 9 JRE. Similarly, a class file compiled by Java 17 compiler will not run on Java SE 11 JRE.

Источник

Major Version Numbers for Java Class File Formats: A Compilation

To resolve the issue, I came across a helpful resource — the Wikipedia page that explains the format of Java class files. It contains a list of various Java class file versions along with the corresponding Java Virtual Machine. If you’re looking for class file version 51.0 (Java 7), you can identify it by examining the opening bytes, which are 0xcafebabe for the magic bytes, 0x0000 for the minor version, and 0x0033 for the major version, located under byte offset 6 and 7.

List of Java class file format major version numbers?

In a previous post, I came across a compilation of significant version numbers for Java.

• Major version 46 is utilized by Java 1.2.
• The major version utilized by Java 1.3 is 47.
• The major version used by Java 1.4 is 48.
• Java 5 uses major version 49
• Java 6 uses major version 50
• Java 7 uses major version 51
• Java 8 uses major version 52
• Java 9 uses major version 53
• Java 10 uses major version 54
• Java 11 uses major version 55
• Java 12 uses major version 56
• Java 13 uses major version 57
• Java 14 uses major version 58
• Java 15 uses major version 59
• Java 16 uses major version 60
• Java 17 uses major version 61
• Java 18 uses major version 62
• Java 19 uses major version 63

Is there a source for this list, preferably one that includes minor versions?

The aforementioned (class version) is the source of these errors. Attempting to run java 6 compiled code on a java 5 runtime will result in an error message stating that the class versions are incompatible. The error message typically reads «got 50, expected 49» or something similar.

Refer to byte offset 7 to obtain additional information.

Here is where you can access supplementary information as well.

On the Wikipedia page that explains the class File Format, I came across a compilation of various versions of Java class files.

The general layout of a Java class file can be found on the Wikipedia page for Java class file.

The Java VM versions corresponding to the byte offset 6 & 7 are listed.

The designated authority for the primary version identification.

Here is where to locate the most recent release of the JVM specification.

If encountering an issue with the «error compiler of class file,» it can be remedied by adjusting the JRE of the project to match through Eclipse.

1. Build path
2. Configure build path
3. Update the library to match the table that your friend recently displayed.
4. Generate a «jar file» followed by compiling and running it.

Java — Bad version number in .class file, One way to catch almost all class definitions is to use a Java Agent using the Instrumentation API. This API allows to transform all byte codes before …

Tool to read and display Java .class versions

Is there a program available that can locate .class files and exhibit their compiled variants?

I’m aware that it’s possible to examine them one by one using a hex editor, but due to the large number of class files in my extensive application, I need to find a way to review them more efficiently. This is because something in my application is being compiled to Java6, and I need to identify the cause.

Utilize the javap utility that is included in the JDK, which allows you to obtain the version number of the class file by selecting the -verbose option.

> javap -verbose MyClass Compiled from "MyClass.java" public class MyClass SourceFile: "MyClass.java" minor version: 0 major version: 46 . 

WINDOWS> javap -verbose MyClass | find "version" LINUX > javap -verbose MyClass | grep version 

By simply reading the initial 8 bytes, one can easily obtain the values without relying on any external API to interpret the class file signature.

The initial bytes for the class file version 51.0 (Java 7) are:

The magic bytes, represented by 0xcafebabe, are accompanied by the minor version 0x0000 and the major version 0x0033.

import java.io.*; public class Demo < public static void main(String[] args) throws IOException < ClassLoader loader = Demo.class.getClassLoader(); try (InputStream in = loader.getResourceAsStream("Demo.class"); DataInputStream data = new DataInputStream(in)) < if (0xCAFEBABE != data.readInt()) < throw new IOException("invalid header"); >int minor = data.readUnsignedShort(); int major = data.readUnsignedShort(); System.out.println(major + "." + minor); > > > 

It is effortless to search for class files in both directories (File) and archives (JarFile) by walking through them.

Joe Darcy, from Oracle, has published a blog post that outlines the correspondences between class versions and JDK versions, including those for Java 7.

Target Major.minor Hex 1.1 45.3 0x2D 1.2 46.0 0x2E 1.3 47.0 0x2F 1.4 48.0 0x30 5 (1.5) 49.0 0x31 6 (1.6) 50.0 0x32 7 (1.7) 51.0 0x33 8 (1.8) 52.0 0x34 9 53.0 0x35 

The output displays both the file type and its version. Here’s an example of how it appears:

On a Unix system, a simple solution would be to perform a single action.

find /target-folder -name \*.class | xargs file | grep "version 50\.0" 

In my file, the Java 6 classes are indicated as «compiled Java class data, version 50.0».

Class vs .java, 6. A .java file contains your Java source code while a .class file contains the Java bytecode produced by the Java compiler. It is your .class files …

Java naming convention for a class with version in its name?

Assuming I am tasked with handling various versions of a protocol that may have varying interfaces, such as the hypothetical My Protocol (MYP), I would need to work with different classes.

MYP has been released in various versions, including 1.0, 1.1, 2.0, 2.2, and more.

Here are a few examples of possible names that come to mind:

The codes, including MYP10Handler , MYP11Handler , MYP20Handler , MYP22Handler , and so on, are listed.

Listed below are several MSDT codes, including MYP1_0Handler , MYP1_1Handler , MYP2_0Handler , MYP2_2Handler , and so on.

In case the first option is chosen, there could be uncertainties if the protocol is upgraded to a higher version, such as version 11.0 (eleven).

Which version are you referring to, MYP11Handler Version 1.1 or Version 11.0?

Which version should be used, 11.0 or 1.10? MYP110Handler

The second choice, nonetheless, appears to violate the Camel Case convention.

What is the typical approach for naming this type of class? Are there any recommended practices for improving it?

To organize the program’s components based on their version, it is recommended to place all the corresponding files/classes in a package that bears the name of that particular version.

To add a new version of your protocol, it’s necessary to create a new package. Then, you can copy all the old files and begin working on the new material. It’s important to ensure that all files and classes have identical names in each package, as shown in com.yourname.myprotocol14.MyProtocolHandler , and not as in com.yourname.myprotocol14.MyProtocolHandler14 .

The precision with which you write the version on the package name is your choice. You can either include only the major version ( com.yourname.myprotocol10 for version 10.X , com.yourname.myprotocol12 for version 12.X ), or opt to include the minor version as well ( com.yourname.myprotocol10 for version 1.0 , com.yourname.myprotocol12 for version 1.2 ).

To allow the user to choose the version of the library they want to use, they can simply import com.yourname.myprotocol[version number] . Consequently, it is essential to keep all the library files in each package.

Java Classes and Objects, Java Classes/Objects Java is an object-oriented programming language. Everything in Java is associated with classes and objects, along with its attributes and …

Getting Java version at runtime

I have to find a solution to a Java issue that exists in JDK 1.5 but has been resolved in 1.6. To address it, I am utilizing the subsequent criterion:

if (System.getProperty("java.version").startsWith("1.5.")) < . >else

Is there a possibility that this will function on alternative JVMs? Is there an alternate method to confirm this?

Every JVM has a system property known as java.version , which can have one of two possible formats.

• For Java versions 8 or earlier, the following codes are applicable: 1.6.0_23 , 1.7.0 , 1.7.0_80 , and 1.8.0_211 .
• For Java 9 and above, the following codes are applicable: 9.0.1 , 11.0.4 , 12 , and 12.0.1 .

To extract the major version, follow this trick: if the version string is of 1.x.y_z type, take the second character of the string. If it is of x.y.z type, truncate the string at the first occurrence of a dot character, if any.

private static int getVersion() < String version = System.getProperty("java.version"); if(version.startsWith("1.")) < version = version.substring(2, 3); >else < int dot = version.indexOf("."); if(dot != -1) < version = version.substring(0, dot); >> return Integer.parseInt(version); > 

You can now easily verify the version with greater comfort.

How about retrieving the version information from the package’s metadata?

String version = Runtime.class.getPackage().getImplementationVersion(); 

Prints out something like:

Runtime.version()

Beginning with Java 9, you have the option to utilize Runtime.version() to obtain a Runtime.Version .

Runtime.Version version = Runtime.version(); 

According to these articles, using the prefix 1.5 or 1.6 is recommended as it adheres to the correct version naming convention.

Sun Technical Articles

• The naming convention for JRE version strings is denoted by j2se sdk.
• Which one is it — Version 1.5.0 or 5.0?
• «J2SE also keeps the version number 1.5.0 (or 1.5) in some places that are visible only to developers, or where the version number is parsed by programs»
  • » java.version system property»
  • Developers are utilizing Version 1.6.0, as indicated by
  • «Java SE keeps the version number 1.6.0 (or 1.6) in some places that are visible only to developers, or where the version number is parsed by programs.»
    • » java.version system property» .

    Java equivalent of .NET’s Version class?, To get a system/modules version e.g. String.class.getPackage ().getImplementationVersion () If you want to specify your own version, create a …

    Источник