|Re: [jakartaee-platform-dev] [jakarta.ee-spec] What are our options for Jakarta EE 10 going to ballot without GlassFish passing the Concurrency 3.0 TCK?|
This makes sense to me as we are all effectively working towards getting our implementations compatible.
Currently we have had a de-facto RI since the beginning with GlassFish. Whereby GlassFish is required to pass all the TCKs in order to release a platform specification. This leads GlassFish to be always on the critical path for a platform release.
Having the totality of the TCK testing covered by a range of compatible implementations will also remove the requirement to have a single Compatible Implementation project team on the critical path for the platform release.
Right, they would have to ask their favorite project when they will be fully certified. Effectively there would need to be a ratification type of CCR that did not convey full compliance, but that is what reflects the reality of doing away with a single reference implementation in favor of multiple compatible implementation. The downside being what you have referred to.
Back to the top