Win a copy of Microservices Testing (Live Project) this week in the Spring forum!

Patrick Ewing

Greenhorn
+ Follow
since Aug 26, 2016
Cows and Likes
Cows
Total received
2
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
1
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Patrick Ewing

Jesper de Jong wrote:
It's possible to compile code using JDK 1.7 with the "-source" and "-target" options to make it compatible with Java 6, but if you do that you can't use Java 7 language features in the source code, and it does not protect you from one problem: if the code calls something in the standard library that was new in Java 7, then it will crash when you try to run it on Java 6, because the method you are calling isn't found in the standard library of Java 6.



One other comment... I'm surprised the compilation is successful in this situation. I'd have thought that if "source" and "target" are set to 1.6, it will fail compilation if it tries to compile a call to something new in Java7 in the standard library. I'll have to watch out for that.
5 years ago

Jesper de Jong wrote:Welcome to the Ranch.

Java versions are backward compatible: code built on an older version will almost always run without any problems on a newer version. So, code built with JDK 1.6 will run on a Java 7 or 8 JRE without any problems. (Sun and Oracle have always been extremely careful to keep it backward compatible, but there might be small incompatibilities).

However, the other way around does not work. Older versions of Java do not work with code compiled with newer versions. If you have libraries that were compiled with JDK 1.7 and you are using JDK 1.6 to compile your code with these libraries on the classpath, then whoever compiled those libraries must have specified that they should be compatible with Java 6, otherwise you would have gotten an UnsupportedClassVersionError (or something similar) when JDK 1.6 tries to load the classes in the JAR files. If the maintainer of the library didn't specify that it should be compatible with Java 6, then your code wouldn't even compile with these libraries on the classpath.

It's possible to compile code using JDK 1.7 with the "-source" and "-target" options to make it compatible with Java 6, but if you do that you can't use Java 7 language features in the source code, and it does not protect you from one problem: if the code calls something in the standard library that was new in Java 7, then it will crash when you try to run it on Java 6, because the method you are calling isn't found in the standard library of Java 6.

Java 6 and Java 7 are both already quite old. See if you can upgrade your systems to compile and run on Java 8.



Hi and thank you for the response. So as long as the project code compiles with those jars, I shouldn't have any issues at runtime with the 3rd party libraries? That's good to know. As I said I feared there could be a runtime problem that just hadn't been discovered yet.

I've also found a project that compiles in the ant script with source and target set to 1.6, but first builds a dependent project where source and target are set to 1.7. I suppose that's a similar situation to using the 3rd party libraries though. Since there are no compilation issues, it's okay.

With regards to compiling with JDK 7 set to JDK 6 compatibility, it sounds like with the 3rd party libraries I have to trust that they coded it correctly and didn't include any new Java7 functionality when they decided to make it compatible with Java 6. Hopefully that's something I can count on.

I'd love to move everything to Java 8, but unfortunately that's outside of my control.
5 years ago
Hi all,
I'm working on a project that's being compiled with JDK 1.6 (via target and source settings in the ant script) that is pulling in some 3rd party jars that were compiled with JDK 1.7. It still compiles and isn't currently having any obvious problems when executing the code. I'm concerned that it could be an issue though. Am I right to be concerned? Or since it compiles, am I good to go?

I'm thinking that if it tries to execute code in a 3rd party jar that uses Java 1.7 features, it may compile, but it will blow up during runtime. Unless testing happens to execute that code though, the issue could be overlooked. So what do you think? Do I need to make sure that none of the 3rd party jars are compiled with a newer Java version than my project is?
Thanks!
5 years ago