There are quite a few OSS TCKs available now:
Bean Validation
CDI
JCache
spring to mind :-)
On 18 Jul 2013, at 18:22, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi there,
>
>
> On Thu, Jul 18, 2013 at 4:53 PM, Antonio Goncalves <antonio.goncalves_at_gmail.com> wrote:
> I'm following Arjan ;o)
>
> http://antoniogoncalves.org/2013/07/18/java-ee-8-whislist/
>
> Really great list! I think we're largely on the exact same page ;)
>
> About the TCK, I know there are some strong arguments against making the TCK available and there may be certain implications with regards to certification, but just for me personally having access to a TCK would be incredibly useful. For the last year I've been doing a certain amount of research into the various JASPIC implementations. They were all certified, but I found a lot of things in them that did not seem be in line with what the spec demanded.
>
> Having access to the TCK would have helped immensely. With that I would be able to cross-reference it and check if the TCK is maybe incomplete at some point, or maybe contains a bug (it's software too after all), or is simply not testing something at all, or... that my interpretation of the spec is simply wrong.
>
> About the war is the new ear, next to having multiple wars there is one additional advantage of ears and that's that you can have a crude mechanism for layering. Meaning, code (not even necessarily EJB beans) in the EJB module can not directly access web artifacts. This allows some enforcement of business logic not being able to accidentally use a type from say PrimeFaces that lives as a jar in a web module. Whether this benefit is worth the price of the extra complexity is an open question. Hopefully the Java SE module system will be a better answer to this problem indeed. If EJB was indeed to be dissolved then the very term "EJB module" wouldn't even make much sense anymore.
>
> Kind regards,
> Arjan Tijms
>
>