• Post Reply Bookmark Topic Watch Topic
  • New Topic

Project built with older JDK than some of the jars it uses  RSS feed

 
Patrick Ewing
Greenhorn
Posts: 3
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Patrick Ewing
Greenhorn
Posts: 3
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Patrick Ewing
Greenhorn
Posts: 3
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The "-source" option checks that you are using source code that is compatible with the specified version (so, if you use Java 7 language features with "-source 1.6", it's not going to work). But it does not check for method calls to standard library methods, so if you call a method that's new in Java 7, then it's going to break at runtime when you run it on Java 6.

The "-target" option makes the compiler output *.class files in the version of the class file format that the specified Java version understands.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!