-2

My java application refers to a set of jars, both built with jdk 1.6 and maven 2.2.1. There is a need to upgrade our java version to 1.8 for a particular functionality. So, I tried to point my application to jdk 1.8.0_144 and tried to run it. I get following error:

* stderr:Annotation processing got disabled, since it requires a 1.6 compliant JVM The type java.util.Map$Entry cannot be resolved. It is indirectly referenced from required .class files

Note: The application and the dependency jars are still built with jdk 1.6 (the dependency jars are legacy code and I prefer to not compile with new java version)

What am I missing? I read some solutions that require Eclipse upgrade. But, it is not eclipse that directly seem to be a problem here. I also came across some discussion about upgrading ecj.jar. But, I am not sure if I need to do that.

All the help is highly appreciated.

Jparak
  • 19
  • 1
  • 3
  • 'point my application to jdk 1.8.0_144' How did you do that? – Oleg Sep 20 '17 at 02:29
  • just pointed the JAVA_HOME to jdk1.8 – Jparak Sep 20 '17 at 02:36
  • 2
    That's not enough, it doesn't do anything. This is why you have a problem you still use java 6 but something that relies on `JAVA_HOME` uses java 8 – Oleg Sep 20 '17 at 02:43
  • I am starting my application with jdk1.8. for sure, if that is what you implied. Sorry, if that is not what you meant. – Jparak Sep 20 '17 at 02:46
  • I tried upgrading the ecj.jar to 4.3.1 (from 3.5.1). that got me to the next step but got this error: Cannot find annotation method 'value()' in type 'java.lang.annotation.Retention': bad class file: java/lang/annotation/Retention.class(java/lang/annotation:Retention.class) class file has wrong version 52.0, should be 50.0 Please remove or make sure it appears in the correct subdirectory of the classpath. – Jparak Sep 20 '17 at 02:47
  • 1
    JAVA_HOME is used by Tomcat and various IDEs, but not by Java. You don't need to set the CLASSPATH at all for Java, and if you have it set to include some Java installation, remove that part of it. And make sure that the PATH variable contains references to the Java 1.8 bin directories, not an earlier version. – user207421 Sep 20 '17 at 02:54
  • 3
    And the fact that it expects version 50 is clear proof that you are running 1.6, not 1.8. – user207421 Sep 20 '17 at 02:59
  • I am now explicitly using java 1.8 in the startup command, not relying on JAVA_HOME, but same problem. I also set the PATH variable to point to 1.8 bin: java -version java version "1.8.0_144" Java(TM) SE Runtime Environment (build 1.8.0_144-b01) Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode) – Jparak Sep 20 '17 at 03:18
  • I have been running this application with java 1.6 for years now and it still runs like that in prod servers. Its only when I am trying to run with java 1.8 that I am coming across these issues – Jparak Sep 20 '17 at 03:34
  • 1
    Try to remove 1.6 completely from your computer and see if you get a different error. Something still uses it. – Oleg Sep 20 '17 at 03:46
  • what does `mvn -v `show? – P.J.Meisch Sep 20 '17 at 04:00
  • mvn -v Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400) Java version: 1.6.0_07 Default locale: en_US, platform encoding: UTF-8 OS name: "linux" version: "2.6.18-164.9.1.el5" arch: "amd64" Family: "unix" – Jparak Sep 20 '17 at 04:09
  • I am building the application with this version of mvn but running the application on a different server that does not have mvn. – Jparak Sep 20 '17 at 04:10
  • Oleg, moved all the java folders and only kept jdk1.8 but still the same. – Jparak Sep 20 '17 at 04:26
  • 3
    Look, if you get the message "class file has wrong version 52.0, should be 50.0" then it's a fact that you use a class compiled with java 8 with java 6. It's impossible to get that message with java 8. – Oleg Sep 20 '17 at 04:47
  • 2
    `java/lang/annotation/Retention` is part of the JRE. If it is reported to have version 52, then it **is** Java 8. The problem is the *tool* which can’t process the class file, either, still an old version of ECJ, or there’s another bytecode processing tool in the chain. This perfectly fits into the original error message of the question, where a tool is complaining about not finding a “a 1.6 compliant JVM”, not realizing that the JVM is 1.8 compliant, hence, supports all features of 1.6 – Holger Sep 20 '17 at 07:16

1 Answers1

2

There are clear signs that you are already using the Java 8 environment. The message “Annotation processing got disabled, since it requires a 1.6 compliant JVM” indicates that the tool producing this message didn’t recognize the JVM as “1.6 compliant”, which is a typical sign for tools failing to recognize a “1.8 compliant” JVM as being compatible with 1.6.

Further, you cited in this comment an error message of

Cannot find annotation method 'value()' in type 'java.lang.annotation.Retention': bad class file: java/lang/annotation/Retention.class( java/lang/annotation:Re‌​tention.class) class file has wrong version 52.0, should be 50.0.

This indicates that you have a Java 8 environment, as java.lang.annotation.Retention is part of the JRE and is reported to have version 52. But the tool generating this error message does not support processing class files of that version number. In this specific case, it’s not ECJ, as older ECJ versions try to process class files ignoring a higher version number and only bail out when they hit a feature that they don’t understand (as described in this answer).

There is a general pattern behind this. You not only have to update tools with an embedded compiler, like Tomcat or Eclipse or the compiler ECJ specifically, you have to update every tool that does byte code processing.

A lot of tools are settling on a bytecode processing library like ASM, so updating ASM could solve a lot of issues, however, it’s not worth going through all tools of your chain and reason about whether they do byte code processing or not and whether they implement it directly or using another library, just to find out that there is another tool with problems after updating that one.

Instead, update maven completely, including all plugins. It doesn’t pay off to update only a few libraries and keep everything else in that ancient state. And update all tools of your chain you might not have mentioned yet.

Holger
  • 285,553
  • 42
  • 434
  • 765
  • Holger, Is there a way to directly address the first error without upgrading ECJ or any other tool? I also tried using latest version of ECJ but the class version error still persist. This brings to your point of upgrading the maven completely rather than trying out different tools. Upgrading the maven will require building all the application and legacy code. Is that what you suggest? Do I also need to build with Java 1.8? Will this also require using latest ECJ? – Jparak Sep 20 '17 at 13:19
  • 1
    The first error should be solvable by updating the very tool that produces the cited error message. But I doubt that this will be enough to get rid of all problems, it looks like you will end up with another tool producing another error message. I don’t see why upgrading Maven should “require building all the application and legacy code”, as Maven does not depend on your code. I’d say, in an ordinary setup, the ECJ shipped with Maven should get updated automatically when you’re upgrading everything. Also, there should be no need for building it yourself, using prebuilt binaries should be fine. – Holger Sep 20 '17 at 13:39