Error resolution on unsupported Major.minor version 49.0 _java

In the 2 different versions of JDK encountered this problem, on the internet hook a bar! Find a better information to explain.

One: The problem to be solved

We in the taste of early JDK1.5, I believe many people have encountered unsupported Major.minor version 49.0 errors, at that time will be at a loss. Because at the beginning of the time, the relevant Chinese information on the Internet is not much, now good, online find out how to solve, most will tell you to use JDK 1.4 recompile. So as for why, what exactly is that major.minor? This is the content of this article so that the prophets are not mistaken.

I thought I was lucky because I had studied the second edition of "Deep Java Virtual machine" before I met that error, the original title of which was "Inside the Java Machine" (Second Edition), which was known Major.minor Where to hide, but not firsthand, until the actual interview with unsupported Major.minor version 49.0, just to prove to me the fact that.

The first thing we want to build on unsupported Major.minor version 49.0 is that the JDK1.5 compiled class cannot run under JVM 1.4 and must be compiled into a class that can run under JVM 1.4. (Of course, if you're using JVM 1.3 or JVM 1.2, you're going to be compiled into classes that the target JVM can recognize.) This also solves the problem's direction.

II: where Major.minor resides

What is Major.minor and where is it? First perceptual knowledge and find Major.minor to come.

Write a Java Hello world! Code, and then compiled with the JDK 1.5 compiler, Helloworld.java

Package Com.unmi;  
public class HelloWorld  
{public  
  static void Main (string[] args)  
  {  
    System.out.println ("Hello, world!");  
  }  
} 
Package Com.unmi;public class helloworld{public static void Main (string[] args) {System.out.println ("Hello, world!");}

With JDK 1.5 's javac-d. Helloworld.java compiled bytecode Helloworld.class opened with UltraEdit as shown in the following illustration:

From the above we can see what is Major.minor version, which is equivalent to the primary and secondary versions of a software, but here is the main version number and minor version number of a Java Class identified, and we see minor_version as 0x0000, Major_version for 0x0031, converted to 10 system number 0 and 49 respectively, that is, Major.minor is 49.0.

Three: What is major.minor and what is the use

The 第5-8 byte of the Class file is minor_version and major_version. The Java class file format may add new attributes. Once the class file format changes, the version number changes as well. For the JVM, the version number determines the specific class file format, and the JVM is usually able to read the class file only after a given major version number and a series of minor version numbers. If the version number of the class file is beyond the valid range that the JVM can handle, the JVM will not process the class file.

In the Sun's JDK 1.0.2 release, JVM implementations support class file formats from 45.0 to 45.3. JVMs in all JDK 1.1 releases can support version 45.0 through 45.65535 class file formats. In Sun's version 1.2 SDK, the JVM is able to support the class file format from version 45.0 to 46.0.

A version 1.0 or 1.2 compiler can produce a class file with version number 45.3. In Sun's version 1.2 SDK, the Javac compiler defaults to a class file with a version number of 45.3. However, if the-target 1.2 flag is specified on the Javac command line, the 1.2 version of the compiler will produce a class file with a version number of 46.0. The class file generated using the-target 1.2 flag cannot be run on the 1.0 or 1.1 version of the JVM.

The second edition of the JVM implementation modifies the interpretation of the main and minor versions of the class file. For the second edition, the major version number of the class file is consistent with the version number of the Java Platform Main release version (for example, on the Java 2 Platform release, the major version number is from 45 to 46), and the minor version number is related to each release of the particular master platform release. Therefore, although different class file formats can be represented by different version numbers, the version number does not represent a different class file format. The reason for the different version number may be that the class file is created by a different release version of the Java platform, and the format of the class file may not change.

The above three sections are excerpted from the deep Java virtual machine, verbose, JDK 1.2 started the Java 2 era, but that era was still far away from us, and how many of us jumped directly on JDK 1.4, I was similar, but the project requirements had to be wronged on JDK 1.3 for some time. But roughly the information we can get is that each version of the JDK compiler compiles a class file with a version number, a different JVM can accept a range class version number, and an error goes out of scope. But it's generally backwards compatible, do you know that Sun is doing a Solaris mantra? Maintain 100% binary compatibility with previous versions, which is also an investment protection for customers.

Four: Other Major.minor version method to determine class

1 View in Eclipse

Eclipse 3.3 joins the new feature, when a class is not associated with the source code, open it will show more detailed class information, of course, not yet to the source level, look at the figure is open 2.0 Spring.jar Information displayed by Classpathxmlapplicationcontext.class

2) Command Javap-verbose

For the compiled class file with Javap-verbose can display the Major.minor version of the class, see the following figure:

3) MANIFEST File

The class into the JAR package will have file Meta-inf\manifest, this file will generally have compiler information, listed below a few packages of meta-inf\manifest file content you see

· Velocity-1.5.jar meta-info\manifest Partial content
         manifest-version:1.0
         ant-version:apache Ant 1.7.0
         created-by : Apache Ant
         Package:org.apache.velocity
         build-jdk:1.4.2_08
         extension-name:velocity

We see it in ant packaging, the build JDK is 1.4.2_08, and the 1.4-compiled class works in the 1.4 JVM, of course. If that person compiles with a JDK of 1.5 and then packs it with JDK 1.4+ant, it's boring.

Meta-info\manifest part of 2.0 Spring.jar

  manifest-version:1.0
         ant-version:apache Ant 1.6.5
         CREATED-BY:1.5.0_08-B03 (Sun Microsystems Inc.)
         Implementation-title:spring Framework

Note that it is compiled with the JDK 1.5来, so does it bring-target 1.4 or-target 1.3来 compiled? Yes, you can view the binaries for the class, which is the safest. The Spring-2.0.jar can also load execution in the 1.4 JVM.

• Meta-info\manifest from a jar pack that you have used with ant in a project

 manifest-version:1.0
         ant-version:apache Ant 1.7.0
         created-by:1.4.2-b28 (Sun Microsystems Inc.)

The JDK 1.4 build is packaged.

The first second way to know clearly major.minor version, and the third method should be no problem, but encounter abnormal construction is difficult to say, such as who put the Meta-info\manifest pack after the change is also unknown. The method of directly viewing the binaries of a class can be extremely guaranteed, accurate, and I recognize the tool tampering.

Five: Compiler comparison and the location of the disease section

The default Minor.major version of class, compiled from JDK 1.1 to the JDK 1.7 compiler, is now a useful idea. (Go to Sun's website and churn out antiques I've never used before)

JDK Compiler version	Target parameter	Hexadecimal minor.major	Decimal Minor.major
jdk1.1.8	Cannot take target parameter	2D	45.3
jdk1.2.2	Not with (default is-target 1.1)	2D	45.3
jdk1.2.2	-target 1.2	2E	46.0
Jdk1.3.1_19	Not with (default is-target 1.1)	2D	45.3
Jdk1.3.1_19	-target 1.3	2F	47.0
J2sdk1.4.2_10	Not with (default is-target 1.2)	2E	46.0
J2sdk1.4.2_10	-target 1.4	00 00 00 30	48.0
Jdk1.5.0_11	Not with (default is-target 1.5)	00 00 00 31	49.0
Jdk1.5.0_11	-target 1.4-source 1.4	00 00 00 30	48.0
Jdk1.6.0_01	Not with (default is-target 1.6)	00 00 00 32	50.0
Jdk1.6.0_01	-target 1.5	00 00 00 31	49.0
Jdk1.6.0_01	-target 1.4-source 1.4	00 00 00 30	48.0
jdk1.7.0	Not with (default is-target 1.6)	00 00 00 32	50.0
jdk1.7.0	-target 1.7	00 00 00 33	51.0
jdk1.7.0	-target 1.4-source 1.4	00 00 00 30	48.0
Apache Harmony 5.0m3	Not with (default is-target 1.2)	2E	46.0
Apache Harmony 5.0m3	-target 1.4	00 00 00 30	48.0

The above comparison is the case of the JDK compiler under the Windows platform, and we can summarize this:

1)-target 1.1 with the minor version number, Target is 1.2 and later only with the major version number, the minor version number is 0

2 The language difference between 1.1 and 1.4 is small, so the default target of 1.2 to 1.4 is not the corresponding version

3) 1.5 syntax changes very much, so the direct default target is 1.5. Also because it uses 1.5 jdk to generate the target 1.4 code, the light has-target 1.4 is not enough, must take-source 1.4 at the same time, specify the compatibility of the source code, 1.6/1.7 JDK generation target is 1.4 code also.

4) 1.6 The compiler appears more radical, the default parameter is-target 1.6. Because the syntax for 1.6 and 1.5 is no different, you don't have to follow-source 1.5 with-target 1.5.

5 note 1.7 The default target for compilation is 1.6

6 other third party JDK generated Class file format version number and corresponding to the Sun version jdk

7 The last point, most importantly, a version of the JVM can accept that the maximum major version number of a class file cannot exceed the version number of the class file that is compiled with the corresponding target parameter of the JDK.

The above sentence is a bit long, read the past is not very good understanding, for example: 1.4 of the JVM can accept the largest class file major version number can not exceed the 1.4 JDK with parameters-target 1.4 when the main version of the class file, that is 48.

Because the 1.5 JDK compiles with a default target of 1.5 and the bytecode Major.minor version is 49.0, 1.4 of the JVM is unacceptable and only throws an error.

So why is it that the JDK upgrades from 1.1 to 1.2, from 1.2 to 1.3, or 1.3 to 1.4, do not happen to unsupported Major.minor version, because 1.2/1.3/1.4 keeps a good binary and Capacitive, look at the default target of 1.2/1.3/1.4 is 1.1/1.1/1.2 know, and is by default 1.4 JDK compiled class files can be loaded under JVM 1.2, not to mention JVM 1.3? (Of course, remove the factors that use the expanded API of the new version)

VI: Find a solution to the problem

So now if you have a problem with this, how do you know how to solve it, and like some brothers I've seen, go find a 1.4 JDK download installation and recompile all the code with it? In fact, can not do so much trouble, we must remember Javac also have a-target parameter, yes, you can continue to use the 1.5 JDK, compile-time with parameters-target 1.4-source 1.4 OK, but you must be on which API is 1.5 JDK plus Come in at your fingertips, you can't get your class file to the JVM 1.4 and you will not be found. If the target JVM is 1.3, the compilation option is-target 1.3-source 1.3.

Accordingly, if ant is used, its Javac task can also select target and source

<javac target= "1.4" source= "1.4" ............................/>

If it's in development, it's certainly true that the JAVA IDE now has a compilation option to set the target code for the project. For example, the Java Compiler settings in the Eclipse's project properties, as shown in

Since you have set the compile options, you will see that the generated class files compatibility and Source compatibility are also changing, and you can manually adjust those two compiler compliance level. , manually set up after you do not care about what version of the compiler, just ask him to generate the byte code we want on the line, and then extend that even if the source code is written in VB, as long as the JVM can be compiled into the execution of bytecode does not matter. The corresponding Settings dialog box can be found in other Ides.

At other times, you must know what version of the current JVM is and what the main version number of the bytecode is acceptable (which can be compared to the previous table). There are two ways to obtain the current JVM version:

First: If you are executing programs directly in the console with Java commands, you can use Java-version to view the current JVM version, and then determine the acceptable class file version

Second: If you are executing in a container without knowing exactly which JVM to use, you can add code system.getproperty ("Java.runtime.version") to the program that executes in the container. or System.getproperty ("java.class.version") to obtain the JVM version and the version number of the acceptable class.

The last trick, if you don't want to recompile all the code with the target parameter for the lower version of the JVM; if you still want to continue using the new API in your code, and even if you use the new features of JDK 1.5, such as generics, automatic disassembly boxes, enumerations, and so on, then you use-target 1.4- SOURCE 1.4 can not compile through, have to reorganize the code. So to tell you the last move, you don't have to start with the source code, directly convert the bytecode you normally compile, continue to enjoy the new features, the new API, That is: Please refer to a previous log: Retrotranslator lets you write with JDK1.5 characteristics of the code can run in JVM1.4, I was so used, do a good test will not have problems.

Vii. a further discussion of a related problem that actually occurred

This is a unsupported Major.minor version 49.0 error caused by copying Tomcat. The scenario is: I installed JDK 1.5 locally, and then I found an EXE on the web with a Tomcat installation file installed and available. Later colleagues want a tomcat, do not want to download or install, so according to my previous experience is the entire directory of my Tomcat to him should be on the line, the result is to get him there browse JSP files appear unsupported Major.minor version 49.0 error, It is certain that he installed the 1.4 JDK, but I am still a little puzzled, the previous confidence in this issue I was dumbfounded. Inertia thinking is a compiled class file to get a lower version of the JVM will appear as an exception, can now be not used with JDK 1.5 compiled classes to execute AH.

Later look at the exception information, finally found%tomcat_home%\common\lib\tools.jar this look, because the JSP file needs to rely on it to compile, call this Tools.jar in a class file to see, 49.0, and soon I realized that this file was installed on my machine by the Tomcat installer from the%jdk1.5%\lib directory to the Tomcat's Lib directory, which resulted in a 1.4 JVM with 49.0 when compiling the JSP on a colleague's machine. Tools.jar, that can make no mistake, so find to 1.4 JDK Tools.jar replaced Tomcat's OK.

Eight: summary

In fact, understanding major.minor is like we can imagine, the same is the micro-software program, 32-bit applications can not get the 16-bit system execution.

If we get to the target JVM version before we publish, and know how to see the Major.minor version from the Java class file, we don't have to wait for the server to report an exception before we start to solve it, and we can anticipate the problems that may occur.

Other times encountered this problem should be specifically resolved, in short the root of the problem is that the lower version of the JVM can not load the high version of the class file caused by finding a high version of the class file to deal with the line

The following is a solution to the unsupported Major.minor version 52.0 error when Tomcat runs the first servlet

Running the first servlet program with Tomcat occurs as if it were a graph error:

Finding the data is due to the fact that a project compiled with a high version of JDK runs on a lower version of the JRE, and the solution is that the compiled JDK is consistent with the version of the JRE running.

Check that the JRE used by Tomcat does not match compile-time usage (two JDK was originally installed);

Later, the Tomcat's JRE is changed to 1.8 to function:

No art, however minor, demands less than total dedication if your want to excel in it.