+1
On Wed, Jul 25, 2012 at 2:32 PM, Steve Ebersole
<steve.ebersole_at_redhat.com>wrote:
> +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<https://hibernate.onjira.com/browse/HHH-1134>
>>> [1] https://bugs.eclipse.org/bugs/**show_bug.cgi?id=322579<https://bugs.eclipse.org/bugs/show_bug.cgi?id=322579>
>>> [2] https://hibernate.onjira.com/**browse/HHH-6896<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<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<https://bugs.eclipse.org/bugs/show_bug.cgi?id=322579>[1]
>>>>>>> https://hibernate.onjira.com/**browse/HHH-6896<https://hibernate.onjira.com/browse/HHH-6896>[2]
>>>>>>> http://jcp.org/en/jsr/detail?**id=317<http://jcp.org/en/jsr/detail?id=317>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>
>>
--
mailto:matthew_at_matthewadams.me <matthew_at_matthewadams.me>
skype:matthewadams12
googletalk:matthew_at_matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams