Jakarta EE community voices: CDI is the future

Before CodeOne and EclipseCon this October, the Jakarta EE Steering Committee issued a call to action for the community to share their individual visions for the future of Jakarta EE. The community did not disappoint.

Over 70 responses were given to 4 questions by 27 Jakarta EE visionaries totaling over 6000 words of tersely written quotes. As representing this potent vision is more an act of decompression than distilling, we’ll extract their vision in a series of focused but hydrated articles we can all digest.

Hands down the loudest and most detailed answers revolved around pushing CDI to the far corners of Jakarta EE, platform- wide, as the single and only component model for all specifications. An overwhelming 19 of the 27 voices shared their vision for how CDI should rule the Jakarta EE world. Steve Millidge of Payara put it well, stating, “All the specifications need work to coalesce around CDI as the baseline bean model this will drive out complexity and duplication making the Jakarta EE platform light-weight and internally consistent.”

Specific areas of the platform that could change to adopt or leverage CDI included:

JMS allowing messages to be consumed by components other than EJB Message-Driven Beans. “The work to create a CDI based JMS listener started in JMS 2 but never finished”, notes Reza Rahman.
JAX-RS committers “want to get rid of the ancient JAX-RS DI mechanics and replace it with CDI” according to Markus Karg and echoed by Sebastian Dashner, Emily Jiang and several other project members. Santiago Pericas-Geertsen notes CDI beans can currently leverage JAX-RS, but “the combination of two injection frameworks creates some ugly edge cases that cannot be easily resolved” such as which should handle constructor injection.
“JCA is an incredibly powerful API for connecting to many different enterprise systems” states Steve Millidge, indicating realigning it on CDI can enable better connectivity to systems such as Apache Kafka or Cloud Messaging systems. Noted in other answers, though JCA was greatly improved in Java EE 7 it is tied to MDBs which have no clearly defined lifecycle and require EJB.
“EJB and CDI are redundant in many areas, it would be great to eventually build out the missing and necessary parts of the EJB spec into CDI, so that EJB could be phased out” answered Josh Juneau. An aggressive sentiment echoed by a number of community voices.

While the love for CDI is clear, Mark Struberg and spec lead Antoine Sabot-Durand caution that CDI should not become the next EJB and that CDI’s SPI should be used to make those integrations. Sabot-Durand adds his vision for CDI evolution involves flushing out that SPI and “could also focus on more asynchronous support and see how CDI events could be enhanced to be more powerful.”

Passion for pushing powerful asynchronous support into CDI was shared very notably by Clement Escoffierof Eclipse Vert.x, who stated despite being a “CDI newcomer or even a CDI noob” he believes CDI can embrace reactive and indicates his commitment to helping it get there. It will be a bit of work, but “without challenges, life would be boring”, said Escoffier.

Laird Nelson shared some radical ideas for CDI itself, indicating that CDI could be the definitive API for bootstrapping servers in a way that allows developers control of public static void main, including “standardized propagation of command line arguments into the CDI environment.” Similar command-line argument ideas have floated around the Eclipse MicroProfile Config project, which is a good something in this space is bound to take flight.

From application framework to server framework

One thing is clear. For all these specifications to align with CDI, implementers will be forced to recast their code into CDI extensions using the SPI. CDI will transition from the API used by developers to the API used to build servers, making it the SystemD and SysV of Jakarta EE, forcing it to solve similar issues such as extension start order.

Will we see CDI expand from DI framework to kernel? Very possibly.

If CDI becomes our future server-building framework, it will be because of the vision of all 27 community voices that pointed to CDI in 2018 and as the first act of the Jakarta EE community, declared it king.

eclipseorb_color