>> I think this is crucial as I have seen tickets in implementors bug trackers with comments that bugs won't be fixed if the TCK doesn't actually bark. This way, it's actually not the spec driving the features/bugs of the implementation but a TCK not even members of the expert group get access to. This effectively creates a shadow spec which is a sub-optimal thing to see I think.
>
> If you could help in pointing these out, that would be very useful. Our team certainly wants to know about such
> problems.
There's been a couple of comment threads in implementors bug trackers which I've stumbled above. The quickest one I could find was one inside the Hibernate bugtracker [0]. This is by no means finger pointing at Steve, as ironically he and all the other leads of the implementations actually can't do much more than follow the TCK. If it leaves holes and the spec is not as tight as it should be, they essentially have no choice.
One practical example of these is that EntityManager.createNamedQuery(…) didn't throw an exception in case of an invalid query name provided for *two major versions* (2.0 and 2.1). This actually relates to the discussion we have in the separate thread which I'll respond to in a bit. Yet another example is again Hibernate [2] (sorry Steve, I owe you a beer :), which didn't implement Metamodel.managedType(…) correctly by throwing an exception for embeddables and mapped superclasses. Once again, I think the TCK could have caught that, making our lives (the implementor as well as the clients) a bit easier.
Essentially this boils down to two categories: one is slight ambiguities in the spec which need to be discussed and improved (and which we probably won't ever get rid off entirely). The other - even worse - are things that actually *are* defined in detail by the spec but not enforced and then potentially show up to anger users and implementors. They are not worse because they are more crucial. They are worse because it would have been easy to catch them early on if the TCK actually underwent the same open discussion as the spec does.
Regards,
Ollie
[0]
https://hibernate.onjira.com/browse/HHH-1134
[1]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=322579
[2]
https://hibernate.onjira.com/browse/HHH-6896
>> Am 17.07.2012 um 20:36 schrieb Harald Wellmann:
>>
>>> Am 17.07.2012 11:22, schrieb Oliver Gierke:
>>>>
>>>> Where can one get access to the standalone version of the JPA 2.0
>>>> TCK?
>>>>
>>>
>>> The TCK is still closed source, AFAIK.
>>>
>>> Over the past two years, I've found numerous spec-related bugs in all 3
>>> certified JPA 2.0 implementations (Eclipselink, Hibernate, OpenJPA) that
>>> should have been caught by the TCK.
>>>
>>> Some 18 months ago, when there was not even a public mailing list, I
>>> sent a request to the write-only list jsr-317-feedback_at_sun.com to
>>> release the TCK to the public.
>>>
>>> There is also the sad story of a fourth persistence provider who has
>>> given up on certification after trying in vain to get access to the TCK:
>>>
>>> http://datanucleus.blogspot.de/2011/01/jpa-tck-request-and-jpa21.html
>>>
>>> It is good to see that the current JCP is more open than former
>>> versions, but of course a community process that really deserves the
>>> name would open source all TCKs for all JSRs, no exceptions.
>>>
>>>> 2. How can we actually help out to improve the TCK?
>>>
>>> Well, we can't as long as the TCK isn't open. That's the main point why
>>> it doesn't make sense to keep it closed.
>>>
>>> The CDI TCK has been Open Source from the very beginning, part of the
>>> same Java EE 6 umbrella release and governed by the same JCP.
>>>
>>> I really don't see why this shouldn't work for JPA just as well.
>>>
>>> Best regards,
>>> Harald
>>>
>>>
>>>
>>>
>>>>
>>>> Cheers, Ollie
>>>>
>>>> [0] https://bugs.eclipse.org/bugs/show_bug.cgi?id=322579 [1]
>>>> https://hibernate.onjira.com/browse/HHH-6896 [2]
>>>> http://jcp.org/en/jsr/detail?id=317
>>>>
>>>
>>>
>>
--
/**
* @author Oliver Gierke - Senior Member Technical Staff
*
* @param email ogierke_at_vmware.com
* @param phone +49-351-30929001
* @param fax +49-351-418898439
* @param skype einsdreizehn
* @see http://www.olivergierke.de
*/