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.
Scott,
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)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
