Kevin Sutter wrote on 1/29/20 12:17 PM:
Can I play
devil's
advocate? In the past, Java EE and Jakarta EE would specify a
*minimum*
level of Java SE that it was requiring. Java EE 8 and Jakarta
EE
8 specified Java SE 8 as the minimum. But, several application
servers
also support newer versions of Java SE -- 9, 10, 11, etc. These
application
servers didn't necessarily come out and state that they were
Java EE 8
or Jakarta EE 8 compatible with Java 11 (for example). But, the
application
server documents support for Java 11. I'm not aware that
anybody
called "foul" on that and I am by no means advocating for it.
The rule was that you had to be compatible in every
configuration that you documented as being supported. It didn't
matter whether you said it was Java EE compatible in that
configuration or not, it just had to be.
So, if you buy
into that argument, then why wouldn't the reverse also be okay?
Somebody
declares they are compliant with Jakarta EE 9 using the required
Java SE
11. But, the application server also supports Java SE 8. As
long as they don't advertise they are compliant using Java SE 8,
then there
should be no "foul". End users may end up using Jakarta
EE 9 with Java SE 8, but without a formal compliance statement.
If
an application server wants to be put on the Compliance page
with Java
SE 8 as the runtime and advertise their compliance with Java SE
8, then
the formal certification would be required.
The same rule is still part of of TCK compatibility rules, so it
still applies. So yes, if they support Java SE 8, they have to be
Jakarta EE 9 compatible on Java SE 8.
The difference between the JCP approach and the Eclipse approach is
that the JCP approach was enforced by lawyers and the Eclipse
approach is enforced by the community through transparency. Without
the published TCK results on Java SE 8, how would the community
check that they really were compatible on Java SE 8? Surely the
community isn't expected to run the TCK themselves just to prove
that the vendor is compatible.
|
