users@jpa-spec.java.net

[jpa-spec users] Re: [jsr338-experts] Re: Improving the TCK

From: Steve Ebersole <steve.ebersole_at_redhat.com>
Date: Fri, 31 Aug 2012 08:07:22 -0500

While "more openly accessible" is certainly desirable, as a provider
what would be far more desirable is early access. For example, I
already have through the latest spec drafts implemented in Hibernate;
it would be amazing to be able to test that work against the TCK as it
stands thus far. That serves 2 purposes:
1) Helps me validate my work (making providers better)
2) Helps identify TCK problems earlier (making providers more
consistent).


On Fri 31 Aug 2012 04:00:11 AM CDT, Oliver Gierke wrote:
> As quite a few people of the expert group agree about that the TCK should be more openly accessible and we didn't see an official reply yet, let me summarize my questions up:
>
> 1. What's preventing us from changing the TCK license to e.g. Apache 2.0? Other JavaEE specifications (e.g. CDI [0]) have been on that track for years.
> 2. Can the current license still be changed in the course of the 2.1 specification or do we have to wait for 2.2?
> 3. If there's no way to open up the TCK for 2.1, what is the process to track discovered TCK glitches? The JSR JIRA?
>
> Cheers,
> Ollie
>
> Am 27.07.2012 um 16:24 schrieb Matthew Adams <matthew_at_matthewadams.me>:
>
>> +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
>> [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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> mailto:matthew_at_matthewadams.me
>> skype:matthewadams12
>> googletalk:matthew_at_matthewadams.me
>> http://matthewadams.me
>> http://www.linkedin.com/in/matthewadams
>>
>