Please review two corrections for java.time

David Holmes david.holmes at
Tue Sep 10 01:06:38 UTC 2013

Hi Roger,

On 9/09/2013 10:48 PM, roger riggs wrote:
> Hi David,
> I found even on my VirturalBox machine it frequently came close to the
> .1ms target
> and failed in one case.  Raising the time was to reduce/prevent
> intermittent failures.
> Are other timing tests also sensitive to the Xcomp, how should tests be
> written to be insensitive to that JVM option?

Xcomp can be very detrimental to timing. What _should_ happen with 
timeout/delay factors in tests (if they are unavoidable) is that a base 
delay should be chosen and it should be multiplied by a scaling factor 
that can be passed in via the test harness based on the execution 
environment (slow machine, use of Xcomp etc). This is rarely done 
however. :( I'm not sure what the JCK mechanism would be for that.

> Are you otherwise ok with the changes?

I can only comment on the timeout change.


> Thanks, Roger
> 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
>>> machine;
>>>      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.
>> Thanks,
>> David
>>> - 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:
>>> Thanks, Roger

More information about the core-libs-dev mailing list