Please review two corrections for java.time
roger.riggs at oracle.com
Mon Sep 9 12:48:13 UTC 2013
I found even on my VirturalBox machine it frequently came close to the
and failed in one case. Raising the time was to reduce/prevent
Are other timing tests also sensitive to the Xcomp, how should tests be
to be insensitive to that JVM option?
Are you otherwise ok with the changes?
On 9/8/2013 10:43 PM, David Holmes wrote:
> Hi Roger,
> On 7/09/2013 3:58 AM, roger riggs wrote:
>> Please review for two corrections:
>> - The java/time/tck/java/time/TCKLocalTime test failed on a slow
>> the test should be more lenient. The test is not appropriate for
>> a conformance test
>> and is moved to java/time/test/java/time/TestLocalTime.
> As per the bug report the issue is not slow machines per-se but the
> use of Xcomp when running the test. I don't think the jck should ever
> be run with Xcomp. It will be interesting to see if the change from
> 100ms to 500ms cures the problem on all machines.
>> - The javadoc for the JapaneseEra.MEIJI era should indicate the start
>> date is 1868-01-01
>> to be consistent with java.util.Calendar. Note that java.time does
>> not permit dates before Meiji 6
>> to be created since the calendar is not clearly defined until then.
>> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
>> Thanks, Roger
More information about the core-libs-dev