Please review two corrections for java.time
david.holmes at oracle.com
Tue Sep 10 01:06:38 UTC 2013
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
>>> 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