Please review two corrections for java.time

[David Holmes]

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.

David

> 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: http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
>>>
>>> Thanks, Roger
>>>
>>>
>