JDK-8074025 : JCK test api/java_util/logging/LogRecord/index_Millis starts failing after JDK-8072645
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.logging
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2015-02-27
  • Updated: 2016-06-13
  • Resolved: 2015-03-13
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 9
9Resolved
Related Reports
Duplicate :  
Description
JCK test api/java_util/logging/LogRecord/index_Millis starts failing in corelibs jdk9 nightly testing on all platforms after JDK-8072645.

java version "1.9.0-ea" 
Java(TM) SE Runtime Environment (build 1.9.0-ea-langtools-nightly-h2276-20150226-b53) 

jck suite info: 
JCK version: 9/b07

----------out1:(15/1072)----------
java.lang.ArithmeticException: long overflow
	at java.lang.Math.multiplyExact(Math.java:915)
	at java.time.Instant.toEpochMilli(Instant.java:1232)
	at java.util.logging.LogRecord.getMillis(LogRecord.java:478)
	at javasoft.sqe.tests.api.java.util.logging.LogRecord.MillisTests.LogRecord2011(MillisTests.java:48)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at javasoft.sqe.javatest.lib.MultiTest.invokeTestCase(MultiTest.java:405)
	at javasoft.sqe.javatest.lib.MultiTest.run(MultiTest.java:194)
	at javasoft.sqe.javatest.lib.MultiTest.run(MultiTest.java:126)
	at javasoft.sqe.tests.api.java.util.logging.LogRecord.MillisTests.main(MillisTests.java:26)
LogRecord2011: Failed. Test case throws exception: java.lang.ArithmeticException: long overflow
STATUS:Failed.test cases: 1; all failed; first test case failure: LogRecord2011


Comments
I assume this should be resolved as duplicate rather than being resolved as fixed (confusing to have issues marked as fixed with no corresponding change-set)
13-03-2015

Resolved by JDK-8074032 which was integrated in JDK 9 b54
13-03-2015

I have pushed the fix for JDK-8074032 to jdk9-dev. I will wait until it is integrated in the master before closing this bug as fixed.
03-03-2015

The problem is with the conversion to/from instant with Long.MIN_VALUE+1 (and Long.MIN_VALUE too). The following code: for (Object[] test : new Object[][] { {"Long.MAX_VALUE",Long.MAX_VALUE}, {"Long.MAX_VALUE-1",Long.MAX_VALUE-1}, {"1",1L}, {"0", 0L}, {"-1",-1L}, {"Long.MIN_VALUE+1",Long.MIN_VALUE+1}, {"Long.MIN_VALUE",Long.MIN_VALUE} }) { long millis = (Long)test[1]; System.err.println("Testing with " + test[0] +": "+millis+"L"); Instant i1 = Instant.ofEpochMilli(millis); System.err.println("Instant.ofEpochMilli(): " + i1); long millis2 = i1.toEpochMilli(); System.err.println("Instant.toEpochMilli(): " + millis2); } produces this output: Testing with Long.MAX_VALUE: 9223372036854775807L Instant.ofEpochMilli(): +292278994-08-17T07:12:55.807Z Instant.toEpochMilli(): 9223372036854775807 Testing with Long.MAX_VALUE-1: 9223372036854775806L Instant.ofEpochMilli(): +292278994-08-17T07:12:55.806Z Instant.toEpochMilli(): 9223372036854775806 Testing with 1: 1L Instant.ofEpochMilli(): 1970-01-01T00:00:00.001Z Instant.toEpochMilli(): 1 Testing with 0: 0L Instant.ofEpochMilli(): 1970-01-01T00:00:00Z Instant.toEpochMilli(): 0 Testing with -1: -1L Instant.ofEpochMilli(): 1969-12-31T23:59:59.999Z Instant.toEpochMilli(): -1 Testing with Long.MIN_VALUE+1: -9223372036854775807L Instant.ofEpochMilli(): -292275055-05-16T16:47:04.193Z Exception in thread "main" java.lang.ArithmeticException: long overflow at java.lang.Math.multiplyExact(Math.java:915) at java.time.Instant.toEpochMilli(Instant.java:1232) at stuff.NanoTimeOverflow.main(NanoTimeOverflow.java:55) The issue is with Instant.toEpochMilli() - it should use a different calculation when seconds < 0 & nanos > 0.
27-02-2015