I am trying to add jersey to our (old) jboss project but I get "Unsupported classversion" when deploying to jboss - which points to a compile vs runtime version mismatch. In production and on our test servers, the application runs on java 6 but it is built using java 7. Corporate bureaucracy means that it will take months to upgrade the servers to java 7 but the code itself no longer compiles in java 6 due to some javaws dependencies. So for the foreseeable future, I am stuck with these versions.
All my changes work fine if they are compiled and run in java 7 but don't deploy if compiled in java 7 but run in java 6.
I have tried using the maven-compiler-plugin to force the target to be 1.6 but then I run into "source release 1.7 requires target release 1.7" errors.
I can see that at least one the jersey jar artifacts that is downloaded by maven is compiled with java 7 (51.0) and that presumably is the cause. Anyone have any tips as to how I can go forward with this?
Indeed, Downgrading the version of jersey to one compiled with java6 sorted the issue (kinda - I get some jersey problems now instead).
I extracted the class files from the .jar and ran "file" on one and I found that 2.6 version of jersey was the last to support java 6
Related
On the main page I noticed that JJWT is supposed to run on all JDK, which - since our project for all sorts of reasons is still stuck on v1.6 - sounded great.
With the last version maven retrieves however, the class version is not compatible.
And afterwards in the build wiki I noticed it specifies version 7.
Anyone have a clue what does run on v1.6.
Can I use an older version, or should I compile it myself maybe.
On the main page I noticed that JJWT is supposed to run on all JDK ...
That is definitely incorrect / inaccurate. The initial commits for the JJWT project were for JDK 1.6. And I can see that the code uses generics, so compiling / running for earlier than JDK 1.5 will be impossible.
The POM.xml file for the latest version of the project sets the source and target version for the project to JDK 1.7. So certainly the artifacts that a standard build will generate now will NOT run on a Java 6 platform. The class file version will be too recent for a Java 6 JVM to understand.
Now you could try changing the JDK level to 1.6 in the POM file in the HEAD version. However, the JDK version for JJWT was bumped past 1.6 four years ago, so there are liable to be build issues if you wind back. (The developers could have introduced Java 7+ dependencies; e.g. using try with resources syntax or Java 7+ APIs.)
A better idea would be to use an old version of JJWT. You should be able to figure out what version you need to use (or build) for JDK 1.6 compatibility by looking at the project's git history on Github. Look at the relevant changes to the POM file and when they happened. I think it is version 0.9.0 or thereabouts.
Of course a better solution would be "unstick" your project. JDK 1.6 is 8 years past its end of life, and 3 years past the end of Oracle's JDK 1.6 (paid) extended support.
My web application runs fine on JDK 1.7 but crashes on 1.8 with the following exception (during application server startup with Jetty 8). I am using Spring version: 3.2.5.RELEASE.
Exception:
org.springframework.core.NestedIOException: ASM ClassReader failed to parse class file - probably due to a new Java class file version that isn't supported yet
I assume that problem occurs because of spring and "asm.jar" library on which it depends.
How do I resolve this?
As #prunge and #Pablo Lozano stated, you need Spring 4 if you want compile code to Java 8 (--target 1.8), but you can still run apps on Java 8 compiled to Java 7 if you run on Spring 3.2.X.
Check out
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/new-in-4.0.html
Note that the Java 8 bytecode level (-target 1.8, as required by -source 1.8) is only fully supported as of Spring Framework 4.0. In particular, Spring 3.2 based applications need to be compiled with a maximum of Java 7 as the target, even if they happen to be deployed onto a Java 8 runtime. Please upgrade to Spring 4 for Java 8 based applications.
If you encounter this error even if you compile with -target 1.7, please note that this is because of a bug in Spring Framework which causes ASM classreader to load jdk classes (java.* or javax.*), which are, of course, compiled with -target 1.8.
This, combined with the old ASM version in spring 3.2.8 and below, which does not support parsing of 1.8 class files, can also lead to this error.
More info about the issue can be found here: https://jira.spring.io/browse/SPR-11719
This should be fixed in Spring Framework version 3.2.9, which is due to be released soon.
Of course, upgrading to Spring Framework 4 will also resolve the issue, as it already contains a newer version of ASM.
However, if for some reason you can't upgrade to version 4 yet, it's good to know there's an alternative (soon).
I had the same problem and solved it. I am using spring 3.x with java 8. If above solutions are not working change the jars and search whether those jars are compatible with the java version you are using or not. spring 3.x is not compatible with java 8.
I had the same problem,
1.Go to:
maven -> executive maven goal -> mvn clean
It helps :)
2.Invalid caches..
This problem might because of wrong selection of environments. I tried changing JRE to Java SE 1.8 which is the Java version installed.
Project>>Right click>>Properties>>Java Build Path>>Libraries>>Double click JRE system Library>>Execution Environment to JAVA VERSION INSTALLED.
if you use java 8 or next version you need to upgrade spring version and spring version should be 4.xxx
Spring 4 can be used for java 8 to resolve this issue. I just tested it and it works.
This issue is fixed since Spring 3.2.9-RELEASE version.
Fast-ClassPath-Scanner
https://github.com/lukehutch/fast-classpath-scanner using latest version.
On executing(get names of all classes in war which includes all jars and classes)
new FastClasspathScanner(basePackage).scan().getNamesOfAllClasses()
getting:
unsupportedclassversion error with jre 6
Please provide a solution to it or alternative to perform same.
FastClasspathScanner is compiled for java 1.7
When you try to load it in a 1.6 (JRE6) environment it fails with an UnsupportedClassVersionError. This error indicates that the class version (here 1.7) is not compatible with the JVM version (here 1.6).
Java 7 is not backwards compatible with Java 6. You could try to build the FastClasspathScanner library yourself unter 1.6 (not sure if that's possible). Or upgrade your project to Java 7.
Correct, I am the author of FastClasspathScanner, and it's not a goal to get this working with JRE6. However, patches for supporting 1.6 are welcome.
My web application runs fine on JDK 1.7 but crashes on 1.8 with the following exception (during application server startup with Jetty 8). I am using Spring version: 3.2.5.RELEASE.
Exception:
org.springframework.core.NestedIOException: ASM ClassReader failed to parse class file - probably due to a new Java class file version that isn't supported yet
I assume that problem occurs because of spring and "asm.jar" library on which it depends.
How do I resolve this?
As #prunge and #Pablo Lozano stated, you need Spring 4 if you want compile code to Java 8 (--target 1.8), but you can still run apps on Java 8 compiled to Java 7 if you run on Spring 3.2.X.
Check out
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/new-in-4.0.html
Note that the Java 8 bytecode level (-target 1.8, as required by -source 1.8) is only fully supported as of Spring Framework 4.0. In particular, Spring 3.2 based applications need to be compiled with a maximum of Java 7 as the target, even if they happen to be deployed onto a Java 8 runtime. Please upgrade to Spring 4 for Java 8 based applications.
If you encounter this error even if you compile with -target 1.7, please note that this is because of a bug in Spring Framework which causes ASM classreader to load jdk classes (java.* or javax.*), which are, of course, compiled with -target 1.8.
This, combined with the old ASM version in spring 3.2.8 and below, which does not support parsing of 1.8 class files, can also lead to this error.
More info about the issue can be found here: https://jira.spring.io/browse/SPR-11719
This should be fixed in Spring Framework version 3.2.9, which is due to be released soon.
Of course, upgrading to Spring Framework 4 will also resolve the issue, as it already contains a newer version of ASM.
However, if for some reason you can't upgrade to version 4 yet, it's good to know there's an alternative (soon).
I had the same problem and solved it. I am using spring 3.x with java 8. If above solutions are not working change the jars and search whether those jars are compatible with the java version you are using or not. spring 3.x is not compatible with java 8.
I had the same problem,
1.Go to:
maven -> executive maven goal -> mvn clean
It helps :)
2.Invalid caches..
This problem might because of wrong selection of environments. I tried changing JRE to Java SE 1.8 which is the Java version installed.
Project>>Right click>>Properties>>Java Build Path>>Libraries>>Double click JRE system Library>>Execution Environment to JAVA VERSION INSTALLED.
if you use java 8 or next version you need to upgrade spring version and spring version should be 4.xxx
Spring 4 can be used for java 8 to resolve this issue. I just tested it and it works.
This issue is fixed since Spring 3.2.9-RELEASE version.
I would like to know if it is possible to launch a war which have to run with the JDK 1.5 (not compliant with JDK 1.6) under Webpshere 7.
It is not possible/supported to run WebSphere Application Server 7.0 process with any other JDK than the one that is bundled with the product.
I guess I'm confused by your question. JRE's are to be backwards compatible. So the 1.6 JRE within IBM WebSphere Application Server V 7.x.x.x will run Java EE code as far back as Java EE 1 (which I think might be Java 1.2 compliant) and should support Java SE code as far back as 1.1. (Why you'd want to go that far back, I'm not sure....).
There really is no trouble to it. Just compile your code with a 1.5 JDK (that's what we do), or if you want you could compile it with a 1.6 compiler and flag the compiler to use 1.5.
Your code doesn't have to be 1.6 compliant. It just has to be 1.5 compliant and it will run fine. That is the whole point of abstracting and backwards compatibility with the JDK and JRE.
As an example for you, we have an enterprise application that we compile with Maven 2 using Sun/Oracle's 1.5 JDK. We package in several open source project jars, some of which are even as old as 1.3 compliant and/or compiled.
We package all of this up as an EAR using Maven 2 and we deploy it to IBM's WebSphere Application Server (and we run 7.0.0.9). Our code runs just fine. We even have some modules that we do compile with JDK 1.6 to leverage certain functions in 6, but most of the code is compiled as 1.5. And it runs fine.
So I guess I'm confused what you are asking. Could you provide a more concrete example of what you are trying to do? Because from what you have told me, you should be able to run just fine in WAS 7 without compiling at JDK 6.