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.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With