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. At this point, I view this to be
> in a holding pattern until we have a very strong confidence that it
> won't break EE implementations.
>

I have been exploring the effects of removing these APIs on JBoss Wildfly
20, the latest version to support Java EE 8.

The Wildfly implementations of EJBContext.getCallerIdentity and
EJBContext.isCallerInRole(Identity) both throw unconditionally,
respectively UnsupportedOperationException and IllegalStateException (?).

My first attempt to start Wildfly 20 failed on Java 17, because of
encapsulation issues related to reflective access to proxies. That was
easily fixed by upgrading the 'jboss-ejb-client' dependency to a version
where this issue is fixed, and then building 20.0.2.Final-SNAPSHOT. After
this change, Wildfly started just fine with my 21-internal JDK where the
APIs have been removed.

I then went on to deploy and run the 'ejb-security-context-propagation'
sample project [1]. This sample uses EJBContext, so it allows testing of
the removed APIs.

The existing sample rightfully does not call any of the deprecated methods.
The sample client runs just fine against the 21-internal Wildfly server.

I then went on to add a call to 'EJBContext.getCallerIdentity()'. Since the
method throws unconditionally, the return type is never resolved, so we get
the expected UnsupportedOperationException (so, no ClassNotFoundException
or similar):

Exception in thread "main" javax.ejb.EJBException:
> java.lang.UnsupportedOperationException: WFLYEJB0246: getCallerIdentity is
> deprecated
> at org.jboss.as.ejb3 at 20.0.2.Final-SNAPSHOT
> //org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:266)


Based on this testing, it seems removing 'Identity' and related APIs will
have no observable effect on Wildfly at runtime. Building will still need
to happen using a JDK containing the APIs.

I wanted to explore this scenario also on Glassfish, but it seems the last
version of Glassfish supporting Java EE 8 cannot even start on Java 11
(which removed javax.annotation.PostConstruct) and I did not investigate
fixing that.

It seems to me that other Java EE 8 implementations could achieve similar
results by also throwing UnsupportedOperation in their
'EJBContext.getCallerIdentity()' implementation, either unconditionally, or
perhaps just when then detect that they are running on a JRE where the
Identity' class is removed.

To summarize, I'm hopeful that removing 'Identity' and friends have limited
effect on Java EE 8 implementations and apps and that workarounds exist for
problems which may occur. Apps using the deprecated APIs in EJBContext
would of course need to be updated, but that's a straightforward
replacement job.

(Based on my observations of GlassFish and Wildfly, it is not at all clear
to me that they have any plans of fixing their Java EE 8 implementations
to work on Java 11 or 17, regardless of the API removal discussed here)

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230419/3be77b83/attachment.htm>