Exclude SecurityManager API tests in EE 8 TCK

[mnriem]

As the SecurityManager API in Java SE has been deprecated and is slated for removal any TCK tests covering this area should be excluded from the TCK and a vendor should be allowed to drop the functionality in their implementations.

[mnriem]

Related to #406

[edbratt]

Is is nearly certain that EE 8 will never support JDK 17 or higher. Currently EE 8 ONLY supports Java SE 8. I can't see why this should be addressed.

[mnriem]

So for EE 8 a vendor cannot try to certify their implementation with say Java 20?

[edbratt]

No

[scottmarlow]

@mnriem I am trying to understand the background of why you created this issue (in terms of the exact need).

FYI, as part of the Jakarta EE 9.1 release, the Platform specification was updated to support Java SE 11+ (e.g. some technologies were removed and others made optional) but that doesn't address breaking changes like removing the Java Security Manager.

[mnriem]

@scottmarlow By excluding the tests that are related to the upcoming removal of the Java Security Manager it would allow customers to be able to adopt newer Java versions when running on Jakarta EE.

With the proposal of Oracle to speed up LTS releases this seems to be even more relevant.

My understanding is that TCK certification is mostly a self certifying story so excluding these tests should not incur a high overhead on the Eclipse Foundation but gives a vendor additional flexibility.

[mnriem]

Also note that vendors routinely would see customer running their Jakarta EE application servers on more recent versions of Java anyway.

[scottmarlow]

@scottmarlow By excluding the tests that are related to the upcoming removal of the Java Security Manager it would allow customers to be able to adopt newer Java versions when running on Jakarta EE.

Thanks for explaining your original intention of why you created this issue. As already mentioned before, further Jakarta EE changes are needed to align with some Java SE changes.

IMO, the best place to make the needed Jakarta EE changes is in a new Jakarta EE release that addresses the binary incompatible (breaking) Java SE changes.

With the proposal of Oracle to speed up LTS releases this seems to be even more relevant.

Understood.

My understanding is that TCK certification is mostly a self certifying story so excluding these tests should not incur a high overhead on the Eclipse Foundation but gives a vendor additional flexibility.

With regard to Jakarta EE 8, I think it would take more than just removing some TCK tests, the Jakarta EE SPEC APIs also need changes which is better directed towards a new Jakarta EE release. As you cannot update SPEC API classes in an already released EE version (doing so would break compatibility for EE 8 applications). The path forward should be updating to a new EE release that supports the newer SE version.

[scottmarlow]

Also note that vendors routinely would see customer running their Jakarta EE application servers on more recent versions of Java anyway.

Very true, WildFly has been doing that, along with other EE implementations.

[mnriem]

Historically passing the TCK allowed you to claim compatibility so excluding the tests from the TCK would be enough. That would mean that the SPEC APIs would not need to change in that particular case. I am advocating for the least disruptive changes and that would mean excluding any such TCK tests.

[scottmarlow]

Since we have already released EE 8 + EE 9, we cannot update the EE 8 or EE 9 TCK, because in my opinion, doing so would invalidate the EE 8/9 releases.

I suggest that this issue be closed since there is no action that we can possibly take for the reported issue, other than closing this issue (for the reason I just stated).