sebastiandaschner blog

Jakarta EE is currently being formed under the Eclipse Foundation. In order to align the future development, directions, and marketing to the industry, many claim that it’s crucial for the Jakarta EE community to share a common vision or mission statement that the technology will follow.

Last week, at the JCrete conference we held a valuable session on the current and future developments of Enterprise Java, especially Jakarta EE. The importance in sharing and advertising a common vision or mission statement was pointed out. Such a vision not only aligns future developments but also allows customers and users to identify the technology for the specific use cases.

Similar to my proposed technical design principles for future Jakarta EE specifications, I wanted to write down my points of view on Jakarta EE’s mission:

From my point of view, Jakarta EE should become the standard platform for modern enterprise Java software, defining standardized, interoperable specifications that focus on realizing business logic and that deliver value to the majority of enterprises.

Continuing The Journey

I specifically see the following aspects where Jakarta EE should continue where Java EE left off. In my eyes, Jakarta EE should:

Be built on specifications, that are enterprise-grade and effective to use. The well-known Java EE standards are widely-used throughout the industry and allow developers to “learn once, apply everywhere”.

Focus on application business logic, by allowing developers to implement effectively what delivers value to the business. The business logic is separated from the framework implementation. In other words, developers write only their business logic and only minimum technical plumbing, the application containers does the heavy lifting. Java EE is the only technology that allows to ship the deployment artifacts with only application bytecode what results in very effective development pipelines.

Support effective development, with convention-over-configuration approaches. It should be possible to realize the majority of enterprise use cases with minimal effort, while at the same time allowing to extend the standards if needed.

Define interoperable specifications, that require zero configuration when multiple standards are being used. Interoperability is ensured by umbrella specifications.

Offer stability. Java EE was always backwards compatible, which is a huge selling point for larger enterprises. Jakarta EE should continue to define standards that are backwards compatible in the features and APIs they offer. Developers generally don’t like surprises.

Provide vendor-agnostic solutions, by defining standards which are implemented by multiple vendors. Having many vendors not only fosters progress by competition but also improve the chances that the standards meet the demands of the industry.

Be compatible with 12-factor applications and cloud native technology, aka the way how we should build modern service-based applications. For me, these two “buzzwords” are more than just that; they define principles that enterprise projects vastly benefit from.

Addressing Past Restrictions

Besides continuing the road that Java EE went, Jakarta EE should also address past restrictions. In particular, Jakarta EE should aim to:

Keep a healthy, nimble progress. In order to stay relevant, a standard technology needs to advance. An Open Source foundation allows more collaboration and easier contribution for many enterprises and individuals, compared to a single entity controlling the processes. Jakarta EE should define nimble and effective processes that improve progress while staying true to the standard-driven nature of Java Enterprise. Inevitable delays should be caused by technical challenges, not by organizational ones.

Allow graceful deprecation, while keeping individual standards backwards compatible. Backwards compatibility is what made both Java and Java Enterprise that successful. Enterprises heavily rely on technology that doesn’t simply change with no apparent reason. However, in order to allow the platform to evolve without becoming too bloated, the platform should allow more flexible profiles, or compositions of standards. If possible, an enterprise can advance with an updated, minimized set of standards. If older functionality is still being used, the project can continue to use that particular standard. Yet, existing functionality within a single standards as well as interoperability of existing standards must continue to work in future versions.

Define more, suitable profiles. The Java EE’s full profile offers way more functionality than most projects need. On the one hand, it’s very productive for developers to rely on features always being available. For vendors, however, it’s an immense effort to support the set of all standards, including the ones from the past. Jakarta EE should define more profiles, with individual sets of standards that are suitable for different approaches. What’s crucial in my eyes, however, is the existence of an umbrella specification which ensures the interoperability of the standards, as soon as they are available at runtime. This would also allow developers to pick and choose their own set of features, while at the same time avoiding cumbersome configuration.

Enhance what’s missing in functionality. There are some feature gaps in Java EE 8, especially when considering 12-factor and cloud native requirements. MicroProfile, for example, addresses some of these gaps, such as resiliency, metrics, or health checking. Jakarta EE should incorporate similar standards, while considering proper integration into the set of existing standards. Java Enterprise should also advance from only addressing a typical transactional request model by supporting reactive approaches as well as supporting modern server-rendered frontends.

Conclusion

The future of Jakarta EE would benefit a lot from defining a shared vision in which direction the technology should advance. I believe that continuing what made Java EE an outstanding platform while addressing the shortcomings of the past promises a successful future of Enterprise Java.

What’s your take on that topic? Feedback is highly appreciated.

Further Readings