As a start, we should
at least recognize this eventual deprecation and removal in the appropriate
specifications. Also, some type of messaging in the TCK runs would
probably be appropriate if running with JDK 17 -- just to explain why we're
running tests against a deprecated feature. I think this minimal
effort would be good for Jakarta EE 10. --------------------------------------------------- Kevin Sutter STSM, Jakarta EE and MicroProfile architect @ IBM e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter phone: tl-553-3620 (office), 507-253-3620 (office) LinkedIn: https://www.linkedin.com/in/kevinwsutter
Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)
Stark" <starksm64@xxxxxxxxx> To:
developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx> Date:
Re: [jakartaee-platform-dev] Reduce emphasis on security manager in EE
Just a clarification, the security manager
is being deprecated in 17 for removal in a later version. The current JEP
says it will start to be degraded in 18: https://openjdk.java.net/jeps/411
I think we are fine with making security tests optional, but then the issue
of reporting the status of optional tests in TCK runs comes up. We had
the discussion of making the status of optionality results manifest in
compatibility requests, but our position was that this should be handled
by the TCK reporting.
The Jakarta Platform has a very strong
emphasis on the security manager, especially when it comes to TCK testing.
A lot (or everything?) is tested with the security manager enabled, and
constituent specs and implementations have to comply with that.
As the security manager has been deprecated
for removal in JDK 17, I wonder if we should not start taking the first
steps in EE 10 to anticipate for this, even though EE 10 is not targeting
Perhaps we could start with making security
manager enabled TCK runs optional?