CODEWITHSUNDEEP
javamaven
letmaik
letmaik

Reputation: 3500

Can I detect target>1.6 dependencies in a <=1.6 project?

In a specific project I am (at the moment) only allowed to use JRE6 for execution of a Java application. Therefore, I configured maven-compiler-plugin with 1.6 for both source and target.

In my Maven dependencies, I included a dependency that itself targets 1.7 and also uses 1.7 features like try-with-resources -- which I assumed would lead to some compile-time error or warning in my own project (I'm using Eclipse). But it doesn't, so my question is: Is it possible to detect such problems before running the application (or tests) on the specific target JRE which in my case is JRE6?

Upvotes: 5

Views: 274

Answers (2)

letmaik
letmaik

Reputation: 3500

Although just a partial answer, I found a solution for Mihai's mentioned issue with different library signatures. There is the Animal Sniffer Maven Plugin which lets you specify a certain Java runtime that it checks against in some phase (e.g. test).

But this doesn't solve the class file version problem, as Maven simply swallows (-nowarn) those warnings from javac, as explained in a comment to this question.

Upvotes: 1

Mihai Danila
Mihai Danila

Reputation: 2348

(I'll make this an interactive answer; I don't have an answer just yet.)

Kind of tricky. I know of a Ning plugin that can comb through dependency versions, but I didn't see any options to check the class file versions. I know that javac will complain if it finds a linked class having a too new version - can you trace the Maven output and confirm the javac options?

You aren't 100% safe anyway, even with the error. I will have to post an answer, running out of space here. Here is an anecdotal account that I encountered. It features Java 1.4 and Java 5, but it will serve to clarify why you can still get in trouble.

The anecdote will serve to back the opinion that you should strive to keep your libraries on the same (or lower) level than their consumers, and always compile with the proper JDK.

Anyway, here goes. Say you compile the line new java.math.BigInteger(1) for Java 1.4. You use the Java 5 compiler with a 1.4 target, so all sounds good. But the Java 5 core libraries include a BigInteger constructor that takes an int argument, so your class will be built with a reference to that constructor. Unfortunately, Java 1.4 does not have this version of the BigInteger constructor and you will get a runtime error if you later run this code in a 1.4 JVM. What would have happened with a proper Java 1.4 compiler is that an internal cast from int to double would have been produced by the compiler to serve the proper constructor taking a double.

Upvotes: 0

Related Questions