users@javaee-spec.java.net

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

From: Edward Burns <edward.burns_at_oracle.com>
Date: Wed, 23 Oct 2013 06:31:32 -0700

>>>>> On Tue, 22 Oct 2013 07:12:45 -0500, Pete Muir <pmuir_at_bleepbleep.org.uk> said:

PM> One idea we had for CDI, which we never actually followed through
PM> on, was to release some sort of "TCK addendum", which contained
PM> tests that it would be good if an implementation passed, as we knew
PM> they were gaps in our initial TCK coverage. Of course, this wouldn't
PM> be an official thing at all! But we never got around to doing it.

I'm going to come down against the TCK addendum idea. It dilutes the
"compatibility is a boolean property" value proposition that I think is
foundational to everything we do with JCP.

Instead, I propose something similar to what we do already with JSF.
There, we have a large body of automated tests that are entirely
implementation agnostic. These tests go well beyond the TCK, and are
actively developed with TDD. They are, in all ways but name, a TCK
addendum. I've been suggesting to the MyFaces folks for years that they
take our automated tests and run them against their impl. I don't know
if they've tried it, but technically there is nothing stopping them from
doing so.

I don't want to formalize the TCK addendum idea. Instead, we should:

1. Support the concept that implementations should be just as open with
their test harness as they are with their source code.

2. Encourage TDD in impls.

3. Reduce the barriers to entry for contributing new tests to the impl's
test harness.

This has the added benefit of completely sidestepping any legal concerns
about the TCK because you are only dealing with whe the impl source code
license.

Ed