Understanding Jakarta EE: “JakartaEE should allow intermediate ‘bugfix releases'”
Confused about what’s going on with Jakarta EE? This interview series is meant to help you navigate through all the changes and understand where it’s headed, as well as how Jakarta EE plans to become the new home of cloud-native Java. Our 13th guest is Mark Struberg, MicroProfile spec author and software architect at Research Industrial Systems Engineering (RISE). Let’s dive deeper into the Jakarta EE universe!
Jakarta EE: The story so far
Transfering Java EE technologies from Oracle to the Eclipse Foundation is no easy job. The Jakarta EE brand is evolving rapidly but we need to stop for a minute and acknowledge all the changes and plans which will include the platform’s evolution into cloud, containers, microservices, serverless, and reactive technologies.
The vision for the technical future of Jakarta EE includes the following:
- Enhanced support for microservices architecture
- Move to Cloud Native Java, which includes better integrations with technologies like Docker and Kubernetes
- Increase the pace of innovation
- Build a vibrant developer community
- Provide production quality reference implementations
Update: The results of the Participant and Committer Member elections for representatives to the Jakarta EE Working Group Steering Committee, Specification Committee, and Marketing & Brand Committee have just been announced.
- Specification Committee – Participant: Alex Theedom (LJC)
- Specification Committee – Committer Member: Werner Keil
- Marketing & Brand Committee – Participant: Simon Maple (LJC)
- Marketing & Brand Committee – Committer Member: Ivar Grimstad
- Steering Committee – Participant: Martijn Verburg (LJC)
- Steering Committee – Committer Member: Ivar Grimstad
If you want to learn more about the Jakarta EE Working Group governance and processes, have a look at the Jakarta EE Working Group Charter page.
Now back to our series! Keeping track of what’s in and what’s out is still a work in progress, but here’s what we know for certain. While there may be some other proposals that are still pending, these are the projects that have been accepted. This list should help you keep track of Jakarta EE’s progress but we’ve only scratched the surface.
What are the current and future challenges of Jakarta EE? How is it forging a new path forwards for enterprise Java? Where is it headed? This interview series is meant to help you navigate through all the changes and understand where it’s headed, as well as how Jakarta EE plans to become the new home of cloud-native Java.
Jakarta EE series: Here are the interviews published so far
- David Heffelfinger: “I wouldn’t like to see Jakarta EE tied to any specific container orchestration tool”
- Markus Eisele: “I strongly believe there is a lot to do to make Jakarta EE ready for the future”
- Josh Juneau: “The platform needs to evolve more dynamically than it had done in the past”
- Werner Keil: “Jakarta EE should become more modular than it is right now”
- Ondrej Mihalyi: “MicroProfile is paving the way for better microservices support in the Jakarta EE ecosystem”
- Reza Rahman: “Modularity is key to faster release cycles”
- Dmitry Kornilov: “Jakarta EE APIs should be more cloud-friendly”
- Arjan Tijms: “Recognizing the importance of Kubernetes likely means a further reduction in the importance of running multiple applications on a single Jakarta EE server”
- Richard Monson-Haefel: “Jakarta EE 9 will begin the transition to a simpler, lighter, and more flexible platform”
- Otávio Gonçalves de Santana: “Jakarta EE tools should support Kubernetes”
- Guillermo González de Agüero: “MicroProfile saved Java EE & will have a key role in its cloud-native transformation”
- Michael Hofmann: “Combining Jakarta EE with MicroProfile could slow down the progress of MicroProfile”
Now it’s time to welcome our next guest, Mark Struberg, MicroProfile spec author and software architect at Research Industrial Systems Engineering (RISE). Let’s dive deeper into the Jakarta EE universe!
JAXenter: Would it be a good idea to merge Eclipse MicroProfile with Jakarta EE?
Mark Struberg: Oh, this is a complicated question. You have to differentiate between three aspects to answer this.
- The community aspect. Both projects actually have a huge overlap in people who are involved. So they are actually already merged.
- The Platform aspect. MicroProfile started as an ‘unofficial’ JavaEE profile with the goal to be even lighter as the official JavaEE WebProfile. Of course, MicroProfile is not yet an official JavaEE profile. But it probably could be officially ratified by Jakarta EE in the future!
- Specification work. While MicroProfile initially started with just JavaEE specifications (CDI + JAX-RS + JSON-P), we soon started to work on our own specifications. Mostly in areas which should have been part of JavaEE for a long time but didn’t make it due to the EE8 delay. Like microprofile-config, microprofile-health, microprofile-open-api, etc. In this area, there is a real difference between MP and Jakarta EE. MicroProfile sees itself as a place where we innovate. That means we actively push boundaries much more aggressively than Java EE ever did. That also means that we leave ourselves the option to break APIs in a non-backward compatible way. So far this was not needed, but theoretically, we could. And that’s good. Otherwise, we would block a lot of progress by having no possible way back.
Jakarta EE, on the other hand, is a standardization body. It takes existing ideas and tries to define a least common denominator which then gets specified as common standard.
How could those two aspects be combined? Probably MicroProfile will become an incubator project for Jakarta EE?
Right now, the MicroProfile community sets its own pace and keeps pushing boundaries. And this will stay that way at least until Jakarta EE picks up speed and ships Jakarta EE9. So you better ask me again in early 2019 ;)
If you want to use ‘cloud-native’ patterns today, then look at MicroProfile.
JAXenter: Jakarta EE’s path has already been chosen, and that’s cloud-native. How will this goal be achieved?
Mark Struberg: To be honest, I’m not a fan of all that ‘cloud-native’ and MicroServices buzz. For me, this term is a bit too much marketing focused. For 70% of business projects, it makes no sense but many companies will – for various reasons – keep their in-house hosted systems and multi-node clusters. We just needed to pick some big bullet points for Jakarta EE and show that we are up to date. Of course, I’m happy if it works for the marketing lads and if it helps to spread the word then I’m perfectly fine with it.
Yes, we need to support containers, service discovery, various design patterns like circuit breakers, etc. But all those parts are not only usable in cloud and MicroService environments. You really also need it whenever you have systems talking with each other. And yes, that includes having your old Java EE business monolith talking with SAP, a document archive server or any other remote system. Using a circuit breaker, bulkhead, etc for such communication is really a good idea. And if it’s just adding an annotation (like with e.g. microprofile-fault-tolerance) then even better! I expect that Jakarta EE9 will pick up work done in MicroProfile for those parts.
Please note that the next release of Jakarta EE will be Jakarta EE8 and not 9! Jakarta EE 8 will basically be the exact same content as JavaEE 8. But with a much more open license, open TCKs (finally!) and an open community. If you want to use ‘cloud-native’ patterns today, then look at MicroProfile.
JAXenter: How can Jakarta EE evolve to meet users’ cloud needs?
Mark Struberg: Wrong question. In my opinion, it should be about general ‘user needs’ and not about ‘cloud needs’! People just see all the shiny new toys and over that, they totally forget that there is no free lunch. *Every* design decision not just adds new features but always also has a downside!
With ‘cloud-native’ most users think of Netflix. But 98% of all applications are not ‘Netflix style’! Netflix has a really cool architecture and a huge throughput. But Java EE is mainly used to build business projects – which have totally different needs. Here, the main focus is not so much on pure throughput but on data integrity and ‘functional scaling’ aka maintainability. Data consistency really is king for most business projects!
Netflix, on the other hand, does not need transaction safety at all for most parts. If some movie doesn’t start streaming then you will simply press the play button again. Now think about a leasing company where a single row in a database might represent a leasing contract for a building worth 15 million EUR… Call me overcautious, but I personally feel much better using proper commit/rollback handling for that kind of apps.
The blunt truth is that it’s really hard to always get things like hand-coded compensation logic, etc right. So for most apps and teams, it’s much better to just have implicit transaction handling with an automated rollback in case some unexpected Exception pops up. And this is where Java Enterprise really shines. Now if we can combine those existing strengths with new patterns like bulkheads, circuit breakers, long-running actions, etc then this would be a really huge win and an excellent value for users. This is what Jakarta EE should focus on in my opinion.
JAXenter: Let’s focus on the Jakarta EE survey results. Over 60% of the respondents want better support for microservices. How would you implement that?
Mark Struberg: The MicroProfile project already contains most of the answers. At least from a technical point.
But let me be really clear: most times, the tools are not the problem we have! There are plenty of good tools out there in Java EE and other projects. Just look at Apache DeltaSpike and you will find many of them working even since JavaEE6.
The problem is that people need to develop a totally different mindset when moving to Microservices! And switching to SpringBoot will also not solve these problems. I already mentioned the missing transaction guarantees and failure handling as two core problems. But there are many more areas which work fundamentally different. I’ll give you an analogy: explaining to a rookie that he shall call `userTransaction.commit()` will not make his application magically consistent overnight. He really must first learn to understand and live the concepts behind it.
What Jakarta EE and MicroProfile should aim for is to make this learning process as fast as possible.
JAXenter: Speaking of the survey, the second most desired aspect is native integration with Kubernetes. Should this be a priority for the development of the project?
Too long [between releases] is deadly for adoption. But too fast is also not good – speed kills. Don’t nail me on numbers, but I think two to three years for major features would be great.
Mark Struberg: Kubernetes is really nice. But it’s also a very volatile place right now. I doubt that Kubernetes of today will be the same as in three years from now.
So, most of the time, I think the Jakarta EE specs don’t need to care about Kubernetes. Or about any other container for that matter. All this should be abstracted by the Java EE vendors. This is actually one of the huge benefits of Java EE ever since: it abstracts away the Java EE runtime from the application. Ideally running on Kubernetes only affects the former part and is fully transparent to the later.
To give you an example: If you use microprofile-config or the new JSR-382 ConfigJSR then you have two parts:
- the user facing API for resolving configuration for your application.
- the SPI for integrating and extending the configuration infrastructure.
If you run on Kubernetes, then all you need to do is to drop-in a jar with a ConfigSource into your application. Or probably the container even provides one out of the box. This ConfigSource will then integrate with kubeconfig. Your own Jakarta EE application doesn’t even know about it! It’s really fully transparent and abstracted away because it’s an operations/integrations concern.
To summarise it up: Jakarta EE should enable such abstractions and integration. But it should not force everyone to provide one out of the box. Because why should an IoT device need a kubeconfig integration for example?
JAXenter: Would you prefer faster releases (like Java’s new release cadence) or slower, yet bigger feature releases?
Mark Struberg: Something right in the middle. Too long is deadly for adoption. But too fast is also not good – speed kills. Don’t nail me on numbers, but I think two to three years for major features would be great.
I have an additional wish though: JakartaEE should allow intermediate ‘bugfix releases’. Releases which remain API compatible but add additional wording and TCK tests to improve portability and fix blockers.
JAXenter: How do you plan to participate in the development process of Jakarta EE? Any specs or TCKs you’re especially interested in?
Mark Struberg: Apart from being the specification lead for JSR-382 ConfigJSR (together with Emily Jiang from IBM), I’m also one of the core MicroProfile people plus also involved in half a dozen JakartaEE specifications like JSON-P, JSON-B, CDI, etc as active EE member. This is as much as I can spare beside my day job.
JAXenter: How do you think the community should adapt to the changes that have taken place recently?
Mark Struberg: My advice is the same since 20 years: don’t blindly follow every hype. Instead, think about how you can leverage the benefits for your environment and really try to understand the core ideas and design decisions of the new approach before you apply it. Because every design decision not only has positive sides but always come with a downside as well!
Our Jakarta EE interview series is published three times a week. Join us on a journey to the depths of Jakarta EE!