On 10/5/21 3:10 PM, Emily Jiang via jakarta.ee-spec
wrote:
Hi Scott,
Thanks for reaching out to me! My concern is that
we need to understand the SecurityManager tests. I
might be wrong but I assume these tests use
SecurityManager apis to test other functionalities.
If we delete them, would the functionalities live
without accompanied tests?
First, I apologize for raising this on this mailing
list, I corrected my address book entry for you (I
intended to just follow up with you privately to better
understand your point).
Some other tests combine testing of multiple Java SE
technologies within the same test source that also tests
multiple Jakarta EE technologies (typically targeting a
base Jakarta EE technology but also involving other
Jakarta EE technologies).
Would Java 17 make SecurityManger completely
obsolete?
No, Java SE 17 does not make the SecurityManager
obsolete, it only marks it as deprecated (for removal in
a future Java SE release).
I was thinking along the lines of the Java version when
this SecurityManager was finally removed. From what you
said, it seems that the tests are to test SecurityManager, I
think it is okay to have them removed. However, for the
removal process, it might also involve spec updates as well.
I think starting gathering how many tests and impacts of
removing SecurityManager is a great idea.
Or is it more that you just don't want to lose
any security related tests?
Scott
On 10/5/21 12:22 PM, Scott Marlow wrote:
Hi Emily,
I would like to better understand why you
said that we cannot remove Java Security
Manager tests from the TCK without adding
replacement tests?
I am thinking that if we remove Java Security
Manager TCK tests for Jakarta EE 10 and there
is a new way in later Java SE versions that
standardizes how equivalent security testing
could be done in a TCK, that someone could
contribute changes to then add new security
TCK tests but that is not likely to happen for
the EE 10 release.