I created a jar file (compiled it using jdk1.7). When I used this jar in a project(using JRE 1.6), I get the following exception- unsupported major.minor version 51.0 (I suppose 51.0 is meant for jdk1.7). I used eclipse IDE for all these operations.
I am wondering whether this exception is a norm (in this kind of situation) or is it coming just because class loading in eclipse works differently
This is expected. Bytecode specifically compiled for a java version, can't be executed on a lower version. This is because it might have bytecode instructions and/or features not supported by an earlier Java version.
To compile for a lower java version, you need to explicitly specify the target version of compilation, eg:
javac -target 1.6 ...
In Eclipse you can set this under Properties > Java Compiler > "Generated .class files compatibility". However in general it is advisable to just use a Java 6 compiler to make sure you are actually only using features and libraries included in Java 6.
Class loading is performed by the JVM, both within eclipse and outside of it. This error simply indicates the the file format of class files has changed in Java 7, and a Java 6 virtual machine does't know the class file format from the future.
You can instruct the Java compiler to use the class file format of a previous java version (in eclipse, you can find the setting under Properties -> Java Compiler -> JDK compliance).
In addition, you'll want to verify that you only use API elements that also existed in JDK 6.
Related
Assuming you have a Java module that defines the following dependencies to SWT:
module com.test.mymodule {
requires org.eclipse.swt.win32.win32.x86;
}
If the module defined above is loaded within a 32-bit based JVM in Windows there are no issues, however within a 64-bit JVM this operation fails as the JVM tries to load native 32-bit libraries within the SWT JAR that then cause the JVM to crash. This will happen on the first line of code that references any SWT class (e.g. if you call Display.getShells). The JARs avaliable on Maven do not define the Atomatic-Module-Name property in the manifest so trying to add the 64-bit version of the library leads to Maven being unable to parse the name of the file correctly.
Furtmore adding a static to the requires has exactly the same effect, as the JVM insists on loading the module specified in the module-info file. Is there any generic SWT module that can be used instead of system-specific modules so that the mymodule module in this sample would load regardless of the bitness/OS of the underlying JVM?
JDK Version:11.0.2, Windows 10 64-Bit
Both the 32-bit and 64 bit versions of SWT binaries are available in Maven Central. The binaries are published to Maven Central for every release.
Links to 64-bit binaries:
https://mvnrepository.com/artifact/org.eclipse.platform/org.eclipse.swt.win32.win32.x86_64
https://mvnrepository.com/artifact/org.eclipse.platform/org.eclipse.swt.cocoa.macosx.x86_64
https://mvnrepository.com/artifact/org.eclipse.platform/org.eclipse.swt.gtk.linux.x86_64
Please note that Eclipse has dropped support for 32-bit since Eclipse 2018-12 (4.10) release.
I used eclipse with jdk 8 to export to jar. Yet i still get this error when start my server sfs
Exception in thread "main" java.lang.UnsupportedClassVersionError: sfs2x/extension/mmo/MMORoomDemoExtension$NPCData has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
Could someone tell me how to fix.
I tried to uninstalled all java and install jdk8 only. But nothing change.
I had a similar problem, what fixed it for me was making sure that jdk8 was selected as the build jdk for that project (right click on your project in Eclipse and click on properties -> Java build path -> JRE System Libraries -> Workspace Default JRE, make ure that jdk8 is selected) and then recompiling. I was able to delete all .class files before recompiling as well, but that may be difficult if this is a project.
Best of luck.
I have created a simple .jar with a class to process a parameter in my Jasper report via scriptlets. I have added the .jar to the build path of the report project.
The .jar has been compiled with JDK 1.7, and the execution enviroment of the Jasper project is set to JRE 1.7, and also the Java Compiler compliance level is 1.7. JAVA_HOME points to jdk 1.7.
Still JasperStudio complains of Unsupported major.minor version 51.0 when trying to access the .jar throught the scriptlet parameter.
Is JasperStudio using jdk 1.6 ?! I think I have ensured it does not by setting all relevant Java properties for the project.
My computer does not even have java 1.6.
There is sth about JasperStudio evidently that still is overriding my jre/jdk choices, but I do not know where/how. Please send me your suggestions on where to look. Thanks a millio
This exception occurs when compiled class version (JDK) does not match with the executing class version (JDK). Jasperserver has a inbuilt JRE within it.
Please confirm the jasperserver JDK Version with the Installed JDK version (Oracle).
To fix the actual problem you should try to either run the Java code with a newer version of Java JRE or specify the target parameter to the Java compiler to instruct the compiler to create code compatible with earlier Java versions.
For example, in order to generate class files compatible with Java 1.4, use the following command line:
javac -target 1.4 HelloWorld.java
Here 1.4 refers to the JDK version of Jasper Server.
I'm trying to overload the GWT "Date_CustomFieldSerializer" ( GWT 2.5.1 with maven2 and java1.6 ).
I've read that it is possible to overload a serializer by creating the same package structure inside your own project.
In my case I reproduce the package com.google.gwt.user.client.rpc.core.java.util to overload the class Date_CustomFieldSerializer but it does not seem to work well.
When serializing the Date, GWT Date_CustomSerializer is used but when the Date is deserialized my own "Date_CustomSerializer" is used.
If I delete the compiled Date_CustomFieldSerializer.class off gwt-user.jar and gwt-servlet.jar then my own Date_CustomFieldSerializer is always used but this is a bad solution, I am after a clean way to say to GWT that uses my own serializer always.
For delvelopment I use jetty and maven with the gwt-maven-plugin and in production mode I use weblogic.
I try to compile my own version of GWT but it fails when I try to run it, the server says:
[ERROR] Unable to initialize static dispatcher
java.lang.UnsupportedClassVersionError: com/google/gwt/core/client/JavaScriptObject$ : Unsupported major.minor version 51.0
How can I set it up to use my own serializer without GWT custom compilation?
Is your version first on the classpath?
It'a the version of Java.
You must compile the GWT Jar and your class with the same version of java.
The version 51 is the Java 7 version. (How to fix java.lang.UnsupportedClassVersionError: Unsupported major.minor version)
But the GWT must be compiled with java 6.
You must set your java source to 1.6
I created a Drools project in Eclipse (Indigo) configured to use JRE 1.7. But I get an error pointing to my .drl file:
com/sample/DroolsTest$Message : Unsupported major.minor version 51.0
The com.sample.DroolsTest.Message class is imported by the .drl file. The Drools runtime was 5.2.1 (also tried with 5.3.0.Final).
Any help would be appreciated. Thanks.
This exception doesn't seem to have to do anything with Drools in particular, but is a generic Java error. It occurs if you try to execute a Java class with a JRE that is older than the JDK that was used to compile it. For example, if you compiled the class with a JDK7 and then tried to execute it with a JDK6, you would get this error.
Just to detail above answer and comment. I had both JRE6 and JRE7 installed, with JRE7 being the default. I had to do two things to remove the error from the drools sample project.
Set the JRE for the project to 1.6
Project properties->Java Build Path->Libraries. Remove JRE System Library 1.7 and Add Library->JRE System Library->Alternate JRE->JRE6
Set the compiler compliance level for the project at 1.6.
Project properties->Java Compiler->check Enable Project specific settings and set Compiler compliance level at 1.6.