Open source TCK was: JDK 9: General Availability
Geir Magnusson Jr.
geir at pobox.com
Sun Sep 24 20:02:08 UTC 2017
> On Sep 24, 2017, at 2:46 AM, Andrew Haley <aph at redhat.com> wrote:
> On 24/09/17 00:51, David Herron wrote:
>> You make a compelling case and I largely agree with the goal of "open
>> sourcing" the TCK's. Doing so would go a long way towards truly opening
>> the OpenJDK project.
>> There is a practical question regarding the primary use for the
>> TCK's - which is to certify compliance with the specifications.
>> An open source software project is free to be downloaded, modified,
>> and the modified version distributed at will.
> Not necessarily: there are variants of free licences which don't
> permit some sections to be changed. But it doesn't really matter what
> licence is used for the TCK itself: the Java Compatible badge would be
> reserved for implementations which had passed TCK Version n.n, as
> posted at java.net. That would be the canonical one true TCK. Sure,
> people would be able to hack their own copies of the TCK, but what
> would be the point? The purpose of passing the TCK is to ensure
> compatibility with other implementations. There isn't any motive to
> claim compliance with a private version of the TCK.
Generally agree. Only quibble is that there may be plenty of motive (for example, AIUI, the Java SE TCK still has limiting constraints when licensed to third parties…), but still, no benefit. A private version of the TCK wouldn’t be the TCK as a derivative work of the TCK isn’t the TCK.
Only the software suite defined by and distributed by the spec lead is the TCK.
(Similar parallel with OpenJDK. Derivatives aren’t the OpenJDK.)
>> For the purpose of sharing of test results, open sourcing the TCK's would
>> be great. The TCK's have a different purpose than just verifying
>> Hence, if someone tested with a modified TCK how can there be certainty
>> about the result? Can the results of testing with a modified TCK be
>> trusted for certification of compliance?
> No, and no.
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the discuss