Incompatibilities between java versions

Question

There is a complex piece of code that does many complex mathematical operations.

When it is built and tested by maven on jdk 1.7 it passes all the tests. When using jdk 1.8 it fails.

Trying to find the spot where the calculations go wrong in a debugger seems almost hopeless.

What are my options? Is there a tool that can scan for incompatibilities between jdk 1.7 and 1.8 in my code?

Is my best option to run the code in two separate debuggers and see where the difference would be?

EDIT:

@Philipp Claßen That is the most likely cause so far. I was hoping there would be an automated way of checking for this.

@dkatzel The code was not written by me, poorly commented and does scientific calculations that are "woodo" to me.

@Mike Samuel I see no benefit of this approach over running two debuggers in parallel.

Thank you all for helping. Seems that two debuggers is the best way to go.

EDIT 2 The author of the original code was relying on hash map ordering. That was the problem.

Answer 1

Add logging statements to log every intermediate result. You can use something like

static void dumpDoubleWithLineNumber(double d) {
  StackTraceElement[] stack = Thread.currentThread().getStackTrace();
  // Thread.getStackTrace() and this method are elements 0 and 1
  StackTraceElement caller = stack[2];
  System.err.println(
      caller.toString()
      + " : " + d 
      + " / " + Long.toString(Double.toLongBits(d), 16));
}

Then run it once under Java 7, once under Java 8, and diff the results.

Answer 2

Seems like you have a good set of tests that caught the problem. Perhaps a good start would be to compare the tests that pass and the tests that fail. What did the tests that fail do differently?

If the tests that fail do too much, then you need more finer grained tests. Tests should really only test one thing in isolation. This means you should have lots of tests that test each part of the complex calculation.

New versions of Java really try hard not to break old working code so it is unlikely a bug in the JDK...however it is possible...

Answer 3

Look out for sources of nondeterminism.

Especially code that relies on the ordering of elements in Collections like HashMaps is dangerous, as the ordering is unspecified and depends on the JVM.

I have seen it in every JVM upgrade that such (buggy) code worked by luck and broke immediately once the JVM implementation changed.

Answer 4

If there is a specific object, you want to monitor and the points, where the object is changed are not too many, you could try to set conditional breakpoints, which will print out information to System.out instead of supending the Thread. That works fine for eclipse, may be also for other IDEs
For example, to monitor the value d at a specific point of code, you create a breakpoint with the following condition:

System.out.println(Thread.currentThread().getStackTrace()[1] + " value="+d); return false;

This condition is never true but always evaluated, so it prints out something like that:

test.Main.main(Main.java:23) value=1.0

If this works in your IDE, you can run your program with Java 7 and java 8 in the IDE and comparing the output. If you can identify the line where the differences occurs, you may go on with conventional debugging.

May be you can find more here : http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-manage_conditional_breakpoint.htm