On 07/19/2012 01:03 PM, Oliver Gierke wrote:
>>> 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.
In my experience, one of the issues is timing. When the EE TCK becomes
available, the priority for the vendors implementing EE, is to pass the
TCK. In theory, when vendors initially get the early EE TCK snapshots,
that would be a good time to report to Oracle, that a certain SPEC
requirement is not covered but that is probably not going to happen as
much (since vendors are focused on passing the TCK instead of improving
it). I'm all for a more open/transparent TCK process but I'd like to
read how we actually want to improve the process and work backwards from
there (if there is interest). For example, I would like to see more
non-vendor eyeballs on the EE TCK java sources and have a way for bug
reports to be opened (that include patches for the TCK). This doesn't
have to be the entire TCK but would include the test classes.
I also agree that ambiguities in the spec, should be discussed and
improved. I see this as a related issue and am just guilty as others,
for remaining silent on some issues. I think that this could be
improved, if we all want to put effort into it. I think part of this,
could be helped with phone call meetings (either quarterly or when
requested).
I would also like to see us get to a point, where we agree that the
priority is delivering the best specification for users and achieving
more portability between vendor implementations. Sometimes it seems
that we instead push that our (vendor) implementation is the correct way
(when ambiguities come up for discussion).
Scott
>
> 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
>>>>>
>>>>
>>>>
>>>
>