Deprecate Application Client Container (ACC)

[m-reza-rahman]

The ACC was never really that popular and it's primary target use cases - remote EJB and Applets - are long out of favor. It should be deprecated to keep the platform lightweight, agile, and forward looking.

There are already many better alternatives for many years now. Just some of them:

• Not using Java SE clients in the first place and use JavaScript clients instead.
• Using REST, WebSocket, etc instead.
• Using vendor specific remote JNDI client libraries.

[hs536]

Several superior alternatives to appclient exist, but migrating to them requires a significant application rewrite. Many of our customers (Fujitsu's) rely on appclient as their EJB client; deprecating it would therefore impose considerable migration risks and costs on them.

[hantsy]

If we deprecate the Application Client, will we discard the JNDI lookup in all Jakarta EE specs?

In my memory, in client codes, we can look up a remote component by JDNI in the initial context. If we finally remove application clients, I am unsure if JDNI is still useful on the server side. CDI injection by type or name is a better choice for developers.

We should clean up the JNDI use cases to use CDI qualifiers and names as first-class citizens.

• DataSourceDefinition
• Jakarta Persistence persitence.xml DataSource element.
• JMSDestinationDefitition/JMSConnectionFactory
• Concurrency ManagedExecutorservice, ManagedScheduledExecutorService, ManagedThreadFactory, etc.
• Use @Inject to replace @Resource everywhere, completely remove @Resource usage in the EE12.

[m-reza-rahman]

If we deprecate the Application Client, will we discard the JNDI lookup in all Jakarta EE specs?

ACC has nothing to do with the use of JNDI on the server-side. It is purely a client-side construct.

[m-reza-rahman]

Several superior alternatives to appclient exist, but migrating to them requires a significant application rewrite.

None of this is unlike other deprecation decisions we have already made in the platform such as SOAP or CORBA. Indeed both are still more popular than the ACC. Just because something is deprecated or even removed does not mean a given vendor cannot still continue to support it, pretty much indefinitely. Indeed I imagine this is what some older runtimes would do. It simply means vendors can make the choice to discontinue it if they so wish.

[hs536]

None of this is unlike other deprecation decisions we have already made in the platform such as SOAP or CORBA.

If I'm not mistaken, SOAP remains in the spec as Jakarta Enterprise Web Services, and CORBA also remains as "Optional" spec. Was this a proposal to make appclient "Optional" within the spec, rather than "Deprecated"?

[m-reza-rahman]

Either way is fine. Functionally, there is little difference. SOAP is slated to be removed in EE 11: https://jakarta.ee/specifications/platform/11/jakarta-platform-spec-11.0-m4#changes-in-jakarta-ee-11. Even back in the Java EE days, we tried to keep the platform fresh and relevant by deprecating old, outdated stuff like Entity Beans and JAX-RPC. It's a good bet there are applications that still use all these things and certainly vendors that still support them.