I decided to update my eclipse to 4.4 (luna release). When I try to launch it however, I get an error stating that eclipse requires 1.7 or later of java jvm.
Just wanted to see if this is true and if it is possible to get it running with 1.6 (specifically 1.6.0_65)
If there is an explicit message stating that 1.7 or later is required when you run it with 1.6, I expect this to be a strong (ie blocking) minimum requirement. Eclipse Luna (4.4) is the first release requiring 1.7:
http://wiki.eclipse.org/Eclipse/Installation
And still, if you still doubt it you can verify for which version it was compiled. For every Eclipse classes run the following command:
javap -verbose EclipseClass.class
Look for Major Version. If value is 51 this means it was compiled for java 1.7, so you are out of luck for 1.6. The magic numbers for major versions are :
J2SE 8 = 52 (0x34 hex),
J2SE 7 = 51 (0x33 hex),
J2SE 6.0 = 50 (0x32 hex),
J2SE 5.0 = 49 (0x31 hex),
JDK 1.4 = 48 (0x30 hex),
JDK 1.3 = 47 (0x2F hex),
JDK 1.2 = 46 (0x2E hex),
JDK 1.1 = 45 (0x2D hex).
and are described here:
http://en.wikipedia.org/wiki/Java_class_file#Magic_Number
Thing is, each eclipse bundle have different minimum requirements, so this may not be a good option for a platform as big as Eclipse. Anyway, I mention it because its good to know.
I also had this problem during the IDE Luna installation. In my case, to solve this problem, I had that change the system variables in win 7. In my computer was the variable that was did referenced the jdk 6... after that I changed it, I could open it again.
This link helped me:
It is requesting to install latest JDK. This is the link
http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
I have installed jdk1.7.0_67 and its running successfully.
Related
while building through Intellij Idea, I got the following message:
Error:scalac: 'jvm-1.10' is not a valid choice for '-target'
Error:scalac: bad option: '-target:jvm-1.10'
later, after a Java upgrade
Build, Execution, Deployment -> Build Tools -> Gradle -> Gradle JVM:
1.8 Build, Execution, Deployment -> Complier -> Scala Complier -> Scala Compile Server -> JDK: 1.8
in build.gradle
compileScala.targetCompatibility = 1.8
ScalaCompileOptions.metaClass.useAnt = false
Nothing helps!
upd:
this helps: in build.gradle
tasks.withType(ScalaCompile) {
scalaCompileOptions.useAnt = false
}
not needed:
compileScala.targetCompatibility = 1.8
ScalaCompileOptions.metaClass.useAnt = false
"Error:scalac: 'jvm-1.10' is not a valid choice for '-target' Error:scalac: bad option: '-target:jvm-1.10'"
In the JDK compatibility notes as mentioned below, it also indicates
that the Java 10 is not fully supporting Scala 2.12.6 JDK 9 & 10
compatibility notes
As you were saying you build this through IntelliJ IDEA, I suspect
you haven't configure your java version (Java 10) or scala version
(2.12.6) inside running configuration project settings.
And also please try out building/compile your application through
commandline in order to check whether you are getting the same error
with that (Otherwise this is just bad configuration in IDEA tht you
need to change)
JDK 9 & 10 compatibility notes (Mentioned in Scala Docs)
JDK 9 & 10 compatibility notes
As of Scala 2.12.6 and 2.11.12, JDK 9 & 10 support is incomplete. Notably, scalac will not enforce the restrictions of the Java Platform Module System, which means that code that typechecks may incur linkage errors at runtime.
JDK 9 & 10 support requires minimum sbt version 1.1.0, or 0.13.17 in the 0.13.x series.
For more information on JDK 9 & 10 compatibility, watch the “Support JDK 9” issue on GitHub.
The same issue can happen with mixed multi-module gradle projects that use java 11 and scala 2.12.10.
In that case, it may help to reconfigure IntelliJ (2019.2) via
Settings > Build, Execution, Deployment > Scala Compiler
by removing the targets defined in Additional compiler options for the affected scala modules.
I stumbled over this issue when having the same problem with Java 11. The reconfiguration comment of Roland Ewald solved the problem. It is important to mention, that this reconfiguration has to be made for all modules of the project (at least for me this was necessary) as well as that IntelliJ sometimes hides parts of the Additional compiler options, so be sure to click on expand even if they seem empty or correct.
I changed the Java Compiler in my eclipse workspace to 1.8 and marked the JRE 1.8 as my default.
This change took affect over all java projects in my workspace (I can see that the JRE System Library is pointing to 1.8).
Now I want to generate new jars from these projects with Java 8, but when checking classes version it still points to Java SE 7 = 51 (0x33 hex) !
I made sure by opening classes on hex editor and checking the 6,7 bytes (https://en.wikipedia.org/wiki/Java_class_file#General_layout)
or by running this command:
C:\Program Files\Java\jdk1.8.0_151\bin>javap -verbose < myclass >.class | findstr major
major version: 51
example of one project:
I've just plainly imported the jar files and this error has appeared. I've tried multiple ways online but couldn't solve it.
This is the classpath that i've imported.
In JDK 9, the module java.corba which contains the interface org.omg.CORBA.portable.IDLEntity is not resolved by default and has to be manually added:
Add the module java.corba to the Explicitly included modules as described in this answer for java.xml.bind or use a Java 8 JRE/JDK.
See blog post Prepare for JDK 9 by Yolande Poirier (emphasis by me):
Six Java EE libraries in JDK are no longer shared by default in JDK 9.
Those Java EE deprecated APIs are java.corba, java.transaction,
java.activation, java.xml.bind, java.xml.ws, java.xml.ws.annotation.
They have been deprecated in JDK 9 and will be removed in a future
release. They are disabled by default in JDK 9. Their packages will
not compile in Java 9 and give an error message. The documentation
gives you migration options to enable those libraries in JDK 9. This
should be a temporary solution because they are scheduled to be
removed in a future release.
I am trying to use the Spring Tool Suite 3.8.3 on Ubuntu 16.04. Upon startup I get this error:
An internal error occured during: "Initializing Java Tooling"
with the detailed message:
An internal error occurred during: "Initializing Java Tooling". Unable
to find Asm for stackmap generation (Looking for
'aj.org.objectweb.asm.ClassReader'). Stackmap generation for woven
code is required to avoid verify errors on a Java 1.7 or higher
runtime when weaving type org.eclipse.jdt.core.search.SearchPattern
when weaving classes when weaving
I have to admit that I have no idea what I should do here and I failed to find any pointers online. Any advice or hint is welcome.
It was for me due to the scala plug-in which I have installed a few days back. Uninstall the scala plugin and change to JDK 8 or JDK 11 it will work.
If anyone is still having a similar problem with Eclipse and needs to use Java 11 or higher (Eclipse nowadays seems to require Java 11) then have a look into this plugin as it seems to be required for the kotlin plugin.
https://marketplace.eclipse.org/content/aspectj-development-tools
I think you have installed Java 9 on your system. That's why you are facing compatibility issue and getting the stated errors. I therefore suggest you to degrade your java version to 8 for which it will work well and you wont be facing any error issue in that.
You can install java8 from this link!
I had to downgrade the JRE used to run Eclipse. Downgrading from Java 15 to Java 11 solved the problem.
Use the -vm option in eclipse.ini, eg.
-vm
c:\Dev\jdk-11\bin
My STS did not even start after installing scala plugin. I had to manually delete scala jars and folders from the STS /plugins. After that it started working.
I used to do the following command line in Java 6:
java -cp "d:\mylib\*" com.my.package.program
Now I upgraded to JDK 7 u1 64 bit and it started to complain that a jar can not be found. The jar IS in the mylib folder.
I looked in http://download.oracle.com/javase/7/docs/technotes/tools/windows/java.html
There is nothing specific written for Java 7. But is the info there up to date?
Java 7 single entry classpaths under windows seem to be broken. To work around this issue I split my classpath, because for some odd reason, java 7 classpaths under windows do work if they consist of 2 or more entries.
For example:
java -cp "d:\mylib\*;d:\myLib" com.my.package.program
or even
java -cp "d:\mylib\*;" com.my.package.program
would work with java 7. I am aware that this is by no means a very elegant solution, but at least the programs run.