JDK-8004066 : TEST_BUG: test/java/lang/Math/DivModTests.java assumes ArithmeticException message
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-11-27
  • Updated: 2013-04-07
  • Resolved: 2012-12-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8 b68Fixed
Related Reports
Relates :  
JDK-6282196 - There should be Math.mod(number, modulo) methods
Description
~/jdk/test/java/lang/Math$ java -Xint -showversion DivModTests
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b65)
OpenJDK 64-Bit Shark VM (build 25.0-b11-internal, interpreted mode)

FAIL: long Math.floorDiv(4, 0) = java.lang.ArithmeticException: / by long zero; expected java.lang.ArithmeticException: / by zero
FAIL: long StrictMath.floorDiv(4, 0) = java.lang.ArithmeticException: / by long zero; expected java.lang.ArithmeticException: / by zero
FAIL: long Math.floorMod(4, 0) = java.lang.ArithmeticException: / by long zero; expected java.lang.ArithmeticException: / by zero
FAIL: long StrictMath.floorMod(4, 0) = java.lang.ArithmeticException: / by long zero; expected java.lang.ArithmeticException: / by zero
Exception in thread "main" java.lang.RuntimeException: 4 errors found in DivMod methods.
	at DivModTests.main(DivModTests.java:49)
Comments
This is a test bug which is checking implementation specific exception message. This message may vary among different VM implementations, so for now it's better to make the test more lenient and accept any ArithmeticException without checking its message.
30-11-2012
Alan - I don't have any problem with testing the implementation. But as you said, checking exception messages in tests make them fragile, especially when the error message is not coming from JDK code, but from the VM instead, which would take more efforts to coordinate changes. Anyway, we all agree this particular test needs changing for sure.
30-11-2012
Krystal - the tests in the jdk repository are *not* conformance/JCK tests, it's normal for the jdk tests to tests implementation specifics, you'll find a significant number of tests are testing behavior that is not in the Java SE specification.You will periodically run into tests that check exception messages and other highly implementation specific behavior. This does make these tests somewhat fragile when the implementation changes but as they are in the same forest then it shouldn't be a problem to do so when updating the implementation. In this specific case I don't think anyone has a problem with changing it as it looks like it is now being used implementations that have a different exception message. The changes to the test should be brought to core-libs-dev@openjdk for review.
30-11-2012
I concur with Christian. The error message isn't specified, so it could be anything (or nothing). In fact, our HotSpot VM ran into the same problem in nightlies with a slightly different behavior. In this test case, there were enough exceptions thrown in Math.floorDiv(). When HotSpot Server Compiler compiled Math.floorMod(), it inlined Math.floorDiv(), noticed it threw ArithmeticException a lot, and then used a preallocated ArithmeticException object for this "hot throw". The generated code clears the detailMessage field to null, which leads to a NullPointerException in this test case: java.lang.NullPointerException at DivModTests.resultEquals(DivModTests.java:390) at DivModTests.testIntFloorMod(DivModTests.java:126) at DivModTests.testIntFloorDivMod(DivModTests.java:103) at DivModTests.testIntFloorDivMod(DivModTests.java:68) at DivModTests.main(DivModTests.java:45) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:474) at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) at java.lang.Thread.run(Thread.java:722) We really shouldn't be checking the contents of unspecified error messages this way, at least in this test case.
29-11-2012
As the exception message is coming from the VM then it is checking the VM implementation. I think that when VMs or changes to HotSpot are in OpenJDK then this test should be updated to handle them (as it's an implementation test, not a conformance tests, clearly a JCK/conformance test shouldn't do this).
29-11-2012
But in this case the test doesn't test the JDK implementation but the JVM. SAP (and soon IBM) are using our JDK implementation but have a different JVM. I think SAP even has internationalized exception messages.
28-11-2012
We have several tests that check the exception message, they are okay because they are testing the implementation, they aren't conformance tests. For this specific issue then I think the Shark folks should update the test to take account of the different exception message.
28-11-2012
The test in question was added by JDK-6282196.
28-11-2012
The message of java.lang.ArithmeticException is not specified so the test is wrong.
27-11-2012