> > 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/
