Status: JDK-8191136 Remove deprecated java.security.{Certificate, Identity, IdentityScope, Signer} APIs

[Eirik Bjørsnøs]

>
> Given that removing these APIs would cause TCK issues in these cases, I
> have been reticent to remove the APIs.
>

To assess TCK impact, I downloaded jakarta-jakartaeetck-8.0.2.zip [1] and
did a grep for getCallerIdentity:

% grep -R getCallerIdentity .
> ./src/com/sun/ts/tests/signaturetest/signature-repository/javax.ejb.sig_3.2_se8:meth
> public abstract java.security.Identity getCallerIdentity()


So it seems no TCK tests actually call the deprecated method, but there is
a set of API signature tests which seems to expect the EJBContext methods
to be present:

>From javax.ejb.sig_3.2_se8:

CLSS public abstract interface javax.ejb.EJBContext
> meth public abstract boolean getRollbackOnly()
> meth public abstract boolean isCallerInRole(java.lang.String)
> meth public abstract boolean isCallerInRole(java.security.Identity)
> meth public abstract java.lang.Object lookup(java.lang.String)
> meth public abstract java.security.Identity getCallerIdentity()
> ...


I have not been able to determine whether these signature tests will accept
the EJBContext signatures as present even when the JRE removes the class.
However, I'm hopeful that is the case, since it does seem that
./lib/sigtest.jar has a BinaryClassDescrLoader class which parses class
files directly, without any reflection.

Based on these observations, it seems running the TCK on a JRE without
java.security.Identity should either be a non-issue, or it should require
relatively small efforts to allow the TCK to run on such JREs.

Thanks,
Eirik.

[1] https://download.eclipse.org/jakartaee/platform/8/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230421/d4d07aa6/attachment.htm>