I have a project using scala for several microservices. We are planning to move to Java 8, but due to the limitation of gradle's Scala plugin and the compatibility between scala and Java 8, those micro services will still be compiled on JDK 7. My question is will they run on JVM 8 without any modification or specific configurtion?
Scala 2.11 which is just released is not yet compatible with Java 8 bytecode. However JVM 8 is backward compatible, so as long as you are still compiling your Scala code on JDK 7 and you just drop it in JVM 8, everything will be working fine.
Might not be applicable to you, but latest Scala only works with JDK 6+, so nothing lower than JDK 6.
Yes, they will. So will those compiled on Java 6 or 5. I am not sure about earlier versions, but would still expect them to work.
Related
Can I use a jar, compiled in Java 7 as a dependency in a project that is compiled for compatibility with Java 6? I do not have the source code of the dependency. I have the compiled jar as a maven dependency.
Can I use a jar, compiled in Java 7 as a dependency in a project that is compiled for compatibility with Java 6?
Let's unpick this:
You have a project that is compiled so that will run on a Java 6 JRE. (Lets suppose that you only use Java 6 APIs in that project.) The .class files for this project must have a classfile format major version less or equal to 50 ... otherwise a Java 6 JRE won't be able to load them.
Then you have a dependency that is "compiled in Java 7". That could mean one of two things:
It could have been compiled using a Java 7 tool chain but with a target version of Java 6.
It could have been compiled using a Java 7 tool chain for Java 7.
In both subcases above above, you should be able to use the dependency in your Java 6 project if you run the project on a Java 7 JRE1. A Java 7 JRE can load and run classfiles compiled for Java 6. In one of the subcases, you will be loading classes with two (or more) class version numbers. But that is OK.
On the other hand, if you try to run the code on a Java 6 JRE, then:
Subcase 1 will work provided that the Java 7 dependency doesn't make use of any Java 7 (or later) APIs; i.e. it only uses Java standard classes, methods, etc that were present in Java 6 or earlier.
Subcase 2 will not work. The Java 6 JRE won't be able to load the dependency. Indeed, if the dependency is static (i.e. the project source code has compile time dependencies on the APIs of the dependent), then the project code won't build ... because the Java 6 compiler should refuse to read the dependency's newer version classfiles.
The most advisable approach is to migrate your project and your execution platform to Java 7. Or better still to Java 8 or Java 11, since Java 7 is EOL'd
If you can't do that, the next best thing would be to avoid using the Java 7 dependency ... until you can upgrade.
If you have customers who insist they you continue to support Java 6, then they are impeding your ability to progress your product line. They should be charged a premium for that.
If you have decided to avoid upgrading your Java platform for internal reasons, this decision is accumulating technical debt ... that your organization will need to "pay down" that debt in the long term.
1 - .... or JDK. A JDK is equivalent to a JRE for the purposes of running code.
In your case you actually ask if there is Forward Compatibility between Java 6 and Java 7. Generally speaking Java does not support Forward Compatibility as the 1.7 JVM cannot run code compiled with 1.6. This happens mainly because the version of 1.7 compiled Java bytecode is not known by the older version (1.6).
We are planning to upgrade our J2EE application, I worked with a lot of jars before and I know that the version mismatch can be a hard problem to debug. We have all the jars(internal to company and built by some other team so cannot recompile with latest version ) compiled using 1.6 jdk and we are bumping up our application version to 1.7, but we are planning to use 1.6 version jars in our app. Does this work well? If not what should I do to make it compatible?
I'm sure that it will work well but, need some expert opinion on this.
Thank yo
As you can see on Oracle's homepage regarding compatibility of Java 1.7 it should be compatibale except for the following things
Binary Compatibility
Java SE 7 is binary-compatible with Java SE 6 except for the
incompatibilities listed below. Except for the noted incompatibilities,
class files built with the Java SE 6 compiler will run correctly in Java SE 7.
Quote from oracle
When I programme I don't take care if I'm using the features in Java 7 or Java 5. But as far as I think if I use only Java 5 features my complied byte codes should be run also on a JRE version 5. But how can I check if my compiled code will be compatible with JRE v. 5 or even earlier or no.
I'm interested to know the answer of this question more generally for Web and Enterprise applications.
You can compile your code with a specific version using the -target option
Try compiling with different targets to see which compiles and which doesn't
http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html
My question is if Java JDK and JREs have to be compatible to run?
I mean: will Java applications written using JDK version 8 in future work with current JRE's?
It is possible to use cross-compilation options when compiling. Do that and it will be possible to compile code with SDK 8 that is compatible with Java 1.1. It won't be very advanced code for 1.1, but it will run.
The short answer is No.
If you develop your application in JDK 8 and run it with JRE 7, you would get an UnsupportedClassVersionError.
This question is two part:
JDK vs JRE
forward / backward compatibility.
JRE is the acronym for Java Runtime Environment. JDK is the acronym for Java Development Kit: a set of tools which you use to develop Java programs. The JDK also contains a full JRE. In general there is no compatibility issue between the two. But you might want to take care not to use libraries which are only available in the JDK (for example code generation or the tools.jar)
Java itself is compiling to bytecode, which is forward compatible. That means you can use bytecode of any Java version and run it with any newer version. The other way around generally doesn't work and is checked by using the class file version ("java.lang.UnsupportedClassVersionError: Test : Unsupported major.minor version 51.0").
Then there are Java libraries, including the core libraries. So far there was never anything removed from them, so they are forward compatible. This is probably going to change with Java 9 where a very small usually unused library functions are removed.
Regarding to backwards compatibility, this is possible by setting the Java compiler to produce Bytecode of an older version. Up until Java 8, the compiler was always able to produce bytecode of the last two major versions as well. However, you might successfully compile a Java 8 source to Java 6, but not be able to run it. That is the case when you use libraries that are only available on a never Java. For such cases there is for example the maven animalsniffer plugin which will verify that when you compile against an older version, you actually only use libraries existing in said version.
I'm using Ant to compile Java.The project has to be compiled using JDK 1.5 , however some part of the code references a package compiled with JDK 1.6 version.
I set the JAVA_HOME to 1.5 , error is thrown at this reference as
[javac] class file has wrong version 50.0, should be 49.0
What is the way out without downgrading the reference version to 1.5
What you are asking isn't possible. You should compile your library with JDK 1.5.
Once Java has been compiled at a certain version, you cannot use that version on older versions of Java.
The package you are using might have a version available which is suitable for an older version of Java, alternatively you may be able to get the source code and recompile with the older version (if it doesn't use any Java 6 libraries / features).
Think this way:
The library you use has been compiled using JDK 6. It may be using some features introduced in Java 6 (that were not part of previous versions of Java)
When you use JDK 5 to compile and run, what do you expect the compiler (and the runtime) to do when this "new" feature is encountered? The JDK 5 does not know this feature and will be "confused"
To avoid this confusion at runtime, the compile itself fails.
You have two options:
Compile your project using JDK 6.
Get a JDK 5 compiled version of your library
If your project were using JDK 6 and the library was compiled with JDK 5, then you wouldn't have faced this issue because of backwards compatibility.