Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Fair rules for"optional"TCKcompliancetests

Guess Ed can probably help more with insight into how realistic that is Building the TCK without Glassfish in Jakarta EE 9 instead of 10 and what resources Oracle has, not to Mention the tragic loss of Bill Shannon who was one of the most profound experts in many of these aspects…?


It should be a lot easier to build the TCK with say Payara due to their close relation, but do you see a realistic opportunity the TCK should be buildable without Glassfish based on Wildfly or TomEE within the Jakarta EE 9 timeframe?


If it wasn’t for some JCP restrictions we could have made the JSR 385 TCK as flexible as to say implementation A just supports Length, while B can only support Mass or Temperature.

We made a compromise there with SI Base Quantities and "All Quantities" but the TCK could have been created with a "Mix & Match" profile allowing to pick just a number of types.


I know CDI and probably Bean Validation should have TCKs that are equally flexible because we borrowed from them in 385, but hard to say, if the entire platform TCK was able to gain a similar flexibility or independence from Glassfish in this release?




From: Scott Stark
Sent: Monday, July 6, 2020 17:50
To: jakartaee-platform developer discussions
Subject: Re: [jakartaee-platform-dev] Fair rules for"optional"TCKcompliancetests


The fundamental problem is that too many assumptions around the existence of "de facto RI" as you stated, exist. As I said, Jakarta EE8 was not a real test of the Jakarta process. Jakarta EE 9 is, and there are clearly issues relating to infrastructure costs as well as the removal of reference implementations. Jakarta EE 9 is a big incompatible release that offers users minimal value. The point was to move the platform to stage 1 of EE10. We need to remove the implicit assumptions and behaviors inherited from the JCP process and get to a sustainable ecosystem.


On Mon, Jul 6, 2020 at 10:40 AM Werner Keil <werner.keil@xxxxxxx> wrote:

Not sure, if they can simply be dropped from Jakarta EE 9 in the middle of the road?

E.g. Jakarta EE 8 had among others 2.7.4. RMI-IIOP (Proposed Optional)

Which became 2.7.4. RMI-IIOP (Removed) guess the lack of support was what turned "Optional" into "Removed" but without a "Proposed something" in Jakarta EE 9 how could we just delete things without prior notice?


Maybe since EE 9 will break all sorts of compatibility anyway without using some Transformer Magic or similar, it is even acceptable in this particular case, but further down the road it would a fatal signal to the community regarding reliability and stability and that’s a major reason to use Jakarta EE instead of some random framework or a solution that’s tied to a vendor’s mercy and may change quite often.


Ford was betting big on Pivotal in 2016, and last year this cost them almost more than rival Tesla or the COVID19 crisis:

Dell wants to sell VMWare for similar reasons, and nobody knows, what cuts may result if some "locust" investor gobbles it up and decides to eliminate parts of Spring they feel are not cost-effective any more?


So this time with Jakarta EE 9 "Big Bang" transition maybe something can be dropped a little sooner than expected, but in future versions I would be more careful to avoid doing that without enough notice.




From: Scott Stark
Sent: Monday, July 6, 2020 17:12
To: jakartaee-platform developer discussions
Subject: Re: [jakartaee-platform-dev] Fair rules for"optional" TCKcompliancetests


Exactly. Hence, unless some sponsor is explicitly stepping up to bring the EE9 specs, their TCKs and an implementation across the finish line, those specs need to be dropped from the EE9 platform.


On Mon, Jul 6, 2020 at 8:28 AM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:

My summary reading of the EFSP  wrt optional is;


  • Jakarta EE Platform specification is a specification under the EFSP and therefore specification rules apply.
  • A specification can have optional parts which must be mutually compatible I.e. you can implement all optional parts
  • All optional parts must be covered by the TCK
  • A specific compatible implementation doesn’t have to implement optional parts.
  • A specification version must identify at least one compatible implementation that does implement all optional parts at release review.


Therefore by definition if the platform specification has optional parts that nobody wants to create a compatible implementation for then that specification version can not be released.


So as in my previous email the solution in the Jakarta EE 10 timeframe is to aggressively remove all optional parts of the platform that nobody is prepared to implement.






jakartaee-platform-dev mailing list
To unsubscribe from this list, visit


Back to the top