<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Given that removing these APIs would cause TCK issues in these cases, I <br>
have been reticent to remove the APIs. At this point, I view this to be <br>
in a holding pattern until we have a very strong confidence that it <br>
won't break EE implementations.<br></blockquote><div><br></div><div>I have been exploring the effects of removing these APIs on JBoss Wildfly 20, the latest version to support Java EE 8.</div><div><br></div><div>The Wildfly implementations of EJBContext.getCallerIdentity and EJBContext.isCallerInRole(Identity) both throw unconditionally, respectively UnsupportedOperationException and IllegalStateException (?).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>The existing sample rightfully does not call any of the deprecated methods. The sample client runs just fine against the 21-internal Wildfly server.</div><div><br></div><div>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):</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Exception in thread "main" javax.ejb.EJBException: java.lang.UnsupportedOperationException: WFLYEJB0246: getCallerIdentity is deprecated <br>at org.jboss.as.ejb3@20.0.2.Final-SNAPSHOT//org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:266) </blockquote></div><div class="gmail_quote"><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>(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)</div><div><br></div><div>Thanks,</div><div>Eirik.</div></div></div>