users@javaee-spec.java.net

[javaee-spec users] Re: How can serious TCK issues be addressed?

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Mon, 21 Oct 2013 11:25:51 -0700

arjan tijms wrote on 10/21/13 10:45 AM:
> Hi,
>
> On Monday, October 21, 2013, Mark Struberg wrote:
>
> Yes, you can challenge those TCK tests if they contradict the spec and a
> sane mind would call it broken or unspecified. Of course only if the exact
> behaviour was not already tested in old TCKs as well ;) Just create a JIRA
>
>
> Indeed, I have in fact created a bunch of JIRA issues in the past about
> several TCK issues, but I was always under the impression that they would be
> done for the next major spec revision at the earliest (like most JIRA issues
> for spec things).
That's the common case.

> I'm particularly curious though if a TCK is ever updated before a next major
> version of a spec is released. For instance, Java EE 7 has recently been
> released, and only 2 servers have been certified yet. If any TCK of it would
> be updated, then this would be applicable only for not-yet certified products
> I guess, but is there any process that covers this situation? Is it even
> possible to still update a Java EE 7 TCK?
I answered most of this in my previous message.

If the TCK is updated, existing products don't need to be retested, but new
releases of those products need to pass the updated version of the TCK.

> Perhaps indirectly it's not much different from when the spec itself is
> updated via an errata. When this happens the spec doesn't get a new version,
> does it? I mean, as a user I can't easily see that a given server is certified
> against Java EE 7 or Java EE 7-errata1, can I?
Errata aren't supposed to change the meaning of the spec, although they may
clarify the meaning. They certainly won't add new requirements.