Java SE 8 (JSR 337) Final Release Specification, RI, and TCK: DRAFT

[mark.reinhold at oracle.com]

2014/1/22 16:54 -0800, Andrew Haley <aph at redhat.com>:
> On 01/23/2014 12:21 AM, mark.reinhold at oracle.com wrote:
>> 2014/1/21 21:04 -0800, Andrew Haley <aph at redhat.com>:
>>> There are some JCK failures in the draft RI.
>>> 
>>> compiler tests: all ok
>>> devtools tests: all ok
>>> runtime tests: 68928 passed, 68 failures, 0 errors
>>> 
>>> Failures:
>>> api/org_ietf/jgss/GSSContext/* (14 total):
>>> all caused by missing support for AES256, so I'd say it's expected
>> 
>> Hrm, maybe you expect them but they're not known failures.  Could you
>> please send me (privately) the relevant .jtr file and also a description
>> of the system on which you're running the JCK (OS, kernel version,
>> hardware, etc.)?  I'll forward that information on to the JCK team for
>> analysis.
> 
> OK.

The JCK team is still looking into the AES256 issue.  We don't think
these tests should be failing.

>>> api/java_util/Base64/Decoder/* (20 total):
>>> caused by missing methods in the package java.util.base64
>>> 
>>> api/signaturetest/sigtest.basic.html#basic[java] (1 total):
>>> dtto caused by missing methods in the package java.util.base64

Due to JDK-8028397.  The changes for that bug were in build 120, but
the corresponding JCK tests hadn't caught up by the time we posted
the draft JCK.

>>> many (almost all) other failures:
>>> +-infinity returned instead of NaN in Double/double computations

This bug was introduced in build 120, fixed in 124 (JDK-8030212).

>> We think these are known failures, but again if you could send along the
>> relevant .jtr files then we can make sure.
> 
> What do you mean by "known failures"?  If there are known failures
> in the draft RI, then it is not fit for purpose.

Indeed!

The JCK, as you can see from the examples above, can be out of sync
with the changes in the code base.  The "known failures list" we made
available to you along with the draft JCK was, due to an oversight,
itself out of sync.  (You can give that list to the JCK test harness
as an "exclude list" and it will exclude the listed tests.  Had you
done so then you'd not have seen the java.util.base64 failures, but
you would still have seen the stream Infinity/NaN failures since the
list was stale.)

We're in the process of preparing an updated draft RI and JCK pair
that should be much closer, if not perfectly, in sync.  We'll let
you know when it's ready.

- Mark