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
