+10000
Early access to the TCK (in progress) is by far the best way to (1)
catch holes in the TCK and (2) keep it improving.
On Fri 20 Jul 2012 08:10:50 AM CDT, Scott Marlow wrote:
> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>
>
>