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" TCK compliance tests (was: Inconsistency on the term "pruned")

I was thinking of jakarta.* based specs that have been removed, but even for javax.* from Jakara EE 8, if you are not making a statement of compatibility, simply that you have an implementation of that legacy api, certification of a Jakarta EE 9 full platform with that extra inclusion would not be indicating that it ran against the Jakarta EE 8 J2EE management TCK. 

When I made such a statement previously on some thread, Lance Anderson from Oracle agreed with the view that it had nothing to do with the current platform.

On Thu, Jul 2, 2020 at 10:10 AM Kevin Sutter <sutter@xxxxxxxxxx> wrote:
Even if it doesn't make sense, I think those are the rules...  At least for these initial removed features.  For example, let's pretend the Open Liberty wanted to continue to support J2EE Management after it was removed from Jakarta EE 9.  J2EE Management was originally part of Java EE and under the javax namespace.  Thus, falling under the old rules put in place by the JCP.  If an app server ships the J2EE Management API, then a corresponding implementation which passes the TCK is required.

That's the way that I have always understood the rules concerning Java EE.  Now, if someone can cite an alternate understanding, then I'm happy to be corrected.  Or, maybe something changed since we shipped J2EE Management with Jakarta EE 8?  I didn't think so since it still uses the javax namespace.  Maybe someone from Oracle needs to clarify the requirements?

(BTW, this is another advantage of moving to the jakarta namespace.  We can define our own rules going forward for removed features post Jakarta EE 9.)

Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    

Back to the top