MicroProfile and Jakarta EE, Surviving Failure with High Availability (was Re: [microprofile-wg] Proposal: Host MicroProfile in Jakarta EE)
112 views
Skip to first unread message
David Blevins
Mar 24, 2025, 1:15:51 AMMar 24
to Microprofile WG discussions, microp...@googlegroups.com
We would vote to continue MicroProfile as a Working Group. We see Jakarta EE and MicroProfile as one ecosystem and advantages to us all in maintaining both. Both to increase our chances of success overall while diminishing our risks of repeat failure and 7-year setback experienced with Java EE.
We see the proposal similar to going from microservices back to a monolith, or a highly available system back to a single large server.
GROWING UP TIED TO A FAILED TECHNOLOGY
We all lived through the failure of Java EE. From the moment it started failing in 2014 to the first release of Jakarta EE with any new functionality (EE 9.1) it was roughly 7 years.
We publicly launched Tomitribe in 2014 and those were the first 7 years of existence. A company tied to Java EE, born at the worst point in Java EE history. We did not have an already successful business to lean on to coast through a rough patch. We had to grow or die in that environment. We were not the only ones. So like the generation that lived through the Great Depression, perhaps I am permanently changed. The difference between having gone through the pandemic and having grown up in the pandemic. Too disconnected from those who didn't grow up in that environment.
If anyone has the attention span, I have assembled some comprehensive thoughts below. I respect other's differing views on this topic and want you to know I have many of the same thoughts. My desire in writing this is to be understood more than change minds. Just like with the pandemic, everyone experienced it differently and that is ok and understood.
IMPACT OF JAVA EE DEATH
First point is what was the impact on our collective opportunity for Java EE in the industry due to our 7 year gap in delivering new functionality?
- Spring Boot became the de facto Java standard for new applications, accelerating developer adoption with zero friction and an opinionated, batteries-included model.
• Docker and Kubernetes redefined deployment models, but Java EE’s stagnation left it unable to evolve, while lighter stacks (Spring Boot, Node.js, Go) integrated seamlessly.
• JavaScript/TypeScript dominated the full stack, with Node.js rising on the backend and frameworks like React taking over front-end development, pulling entire teams into different ecosystems.
• Python and Go exploded in popularity, powering APIs, automation, cloud tooling, and serverless — areas where Java EE had no presence and minimal evolution.
• Serverless platforms (AWS Lambda, etc.) marginalized Java EE, as slow startup and heavy memory usage made traditional Java EE runtimes a poor fit compared to lightweight alternatives.
HOW DID IT HAPPEN?
- Participation steadily declined until collapse: Over time, fewer implementations were certified, vendors stopped proposing new features, and their role shifted to blocking changes rather than driving innovation. As contributors dropped away, the ecosystem was hollowed out until only Oracle and a few individuals remained. Vendors who find themselves the only contributor tend to stop their investment out of valid concerns of subsidizing their competitors. When Oracle also withdrew, Java EE reached complete failure.
- Cost of participation discouraged engagement: Access to key decision-making in private groups required significant financial commitments. Sensitivity over these costs discouraged existing vendors from continuing, and raised the barrier to entry for new implementations, accelerating the decline in participation.
- Brand damage: Since the early 2000s, frameworks like Spring aggressively positioned themselves against Java EE, painting it as large, bloated, legacy, slow to start, slow to evolve, and overly complex. The lasting reputational damage diminished adoption, and accelerated the shift away from the platform.
ONE ECOSYSTEM
How are Jakarta EE and MicroProfile united:
- Both under the governance of the Eclipse Foundation
- Nearly all vendors participate in both Jakarta EE and MicroProfile
- Nearly all Jakarta EE implementations also implement MicroProfile
- MicroProfile directly depends on Jakarta EE
So in practice there is no significant division in community or technically. The differences that remain are the working group and brand.
- Jakarta EE requires a $1M budget, costs $300k for the largest vendors to participate at the greatest level of influence, and the committees are closed to the public.
- MicroProfile requires a $50k budget, costs $25k for the largest vendors to participate at the greatest level of influence, and the committees are open to the public.
There are distinct advantages to each.
SURVIVING ANY FUTURE FAILURE
How can maintaining both better enable us to survive another 20 or 30 years without setbacks from a failure similar to Java EE?
- High availability: Damage to any one brand enables us to shift to the other. Decline in one does not guarantee decline in the other. Cost sensitivity can be mitigated. Governance issues can shift participation to one or the other for periods of time without losing people entirely.
- Governance A/B testing: We can try wildly different governance models and processes in one without risk of destroying our ecosystem as a whole. Reduces friction to trying out new processes and can help us continuously test heavy vs light processes, compare and abandon process that don't bring us the best results compared to their cost.
- Delivering to opposing market segments: Frequently trends emerge that directly oppose existing norms. With two brands we have increased agility to tackle both segments with the least confusion.
- Canary in the coal mine. Failure or stagnation in one can be an early indication of issues that may affect the other in a future date. An early warning enables more time for potential corrective measures before a total failure.
We had a monolith that failed catastrophically. We fixed that and not only got the first system, but a redundant system to mitigate that failure. This redundancy comes cheap, less than 5% the cost of our main system. Between both we're poised to weather almost any storm the industry can throw at us.
Our chances of total failure are greatly diminished unlikely to be a 7-year impact if they occur at all.
SHARED VISION REQUIRED
With my Industry Architect hat on, I think we've achieved something very critical. We're setup to win. This of course only works if:
- We see them as one system.
- We want both to win.
- We are in synch on strategy
I definitely see them as one, want both to win (who doesn't want more ways to win) and for us to be ok strategizing together. It is clear this is where we have the most challenges, however.
PERHAPS TOO ADVANCED
It is an advanced strategy with some overhead. Possibly beyond our skill and vision to actually pull off. While I would be willing to give it another 5 years of effort, it's clear others are not. This strategy requires a majority to pull off.
If others want to throw in the towel now, I don't fault you. I just think it's a shame. I like to play games till I beat them vs just skipping the hard parts. But I get it. We will vote -1 and will not interpret those who vote +1 as "not getting it", "bad" or "enemies." We're still all one team.
IF WE RE-MONOLITH, LET'S DO IT FULLY
If we do move MicroProfile into Jakarta EE, I would want it fully absorbed including a namespace change to jakarta. My interest in MicroProfile is not emotional but strategic as detailed above. If we're going back to the monolith, let's do it right and not make our lives harder.
--
David Blevins
http://x.com/dblevins
https://bsky.app/dblevins
http://www.tomitribe.com
We see the proposal similar to going from microservices back to a monolith, or a highly available system back to a single large server.
GROWING UP TIED TO A FAILED TECHNOLOGY
We all lived through the failure of Java EE. From the moment it started failing in 2014 to the first release of Jakarta EE with any new functionality (EE 9.1) it was roughly 7 years.
We publicly launched Tomitribe in 2014 and those were the first 7 years of existence. A company tied to Java EE, born at the worst point in Java EE history. We did not have an already successful business to lean on to coast through a rough patch. We had to grow or die in that environment. We were not the only ones. So like the generation that lived through the Great Depression, perhaps I am permanently changed. The difference between having gone through the pandemic and having grown up in the pandemic. Too disconnected from those who didn't grow up in that environment.
If anyone has the attention span, I have assembled some comprehensive thoughts below. I respect other's differing views on this topic and want you to know I have many of the same thoughts. My desire in writing this is to be understood more than change minds. Just like with the pandemic, everyone experienced it differently and that is ok and understood.
IMPACT OF JAVA EE DEATH
First point is what was the impact on our collective opportunity for Java EE in the industry due to our 7 year gap in delivering new functionality?
- Spring Boot became the de facto Java standard for new applications, accelerating developer adoption with zero friction and an opinionated, batteries-included model.
• Docker and Kubernetes redefined deployment models, but Java EE’s stagnation left it unable to evolve, while lighter stacks (Spring Boot, Node.js, Go) integrated seamlessly.
• JavaScript/TypeScript dominated the full stack, with Node.js rising on the backend and frameworks like React taking over front-end development, pulling entire teams into different ecosystems.
• Python and Go exploded in popularity, powering APIs, automation, cloud tooling, and serverless — areas where Java EE had no presence and minimal evolution.
• Serverless platforms (AWS Lambda, etc.) marginalized Java EE, as slow startup and heavy memory usage made traditional Java EE runtimes a poor fit compared to lightweight alternatives.
HOW DID IT HAPPEN?
- Participation steadily declined until collapse: Over time, fewer implementations were certified, vendors stopped proposing new features, and their role shifted to blocking changes rather than driving innovation. As contributors dropped away, the ecosystem was hollowed out until only Oracle and a few individuals remained. Vendors who find themselves the only contributor tend to stop their investment out of valid concerns of subsidizing their competitors. When Oracle also withdrew, Java EE reached complete failure.
- Cost of participation discouraged engagement: Access to key decision-making in private groups required significant financial commitments. Sensitivity over these costs discouraged existing vendors from continuing, and raised the barrier to entry for new implementations, accelerating the decline in participation.
- Brand damage: Since the early 2000s, frameworks like Spring aggressively positioned themselves against Java EE, painting it as large, bloated, legacy, slow to start, slow to evolve, and overly complex. The lasting reputational damage diminished adoption, and accelerated the shift away from the platform.
ONE ECOSYSTEM
How are Jakarta EE and MicroProfile united:
- Both under the governance of the Eclipse Foundation
- Nearly all vendors participate in both Jakarta EE and MicroProfile
- Nearly all Jakarta EE implementations also implement MicroProfile
- MicroProfile directly depends on Jakarta EE
So in practice there is no significant division in community or technically. The differences that remain are the working group and brand.
- Jakarta EE requires a $1M budget, costs $300k for the largest vendors to participate at the greatest level of influence, and the committees are closed to the public.
- MicroProfile requires a $50k budget, costs $25k for the largest vendors to participate at the greatest level of influence, and the committees are open to the public.
There are distinct advantages to each.
SURVIVING ANY FUTURE FAILURE
How can maintaining both better enable us to survive another 20 or 30 years without setbacks from a failure similar to Java EE?
- High availability: Damage to any one brand enables us to shift to the other. Decline in one does not guarantee decline in the other. Cost sensitivity can be mitigated. Governance issues can shift participation to one or the other for periods of time without losing people entirely.
- Governance A/B testing: We can try wildly different governance models and processes in one without risk of destroying our ecosystem as a whole. Reduces friction to trying out new processes and can help us continuously test heavy vs light processes, compare and abandon process that don't bring us the best results compared to their cost.
- Delivering to opposing market segments: Frequently trends emerge that directly oppose existing norms. With two brands we have increased agility to tackle both segments with the least confusion.
- Canary in the coal mine. Failure or stagnation in one can be an early indication of issues that may affect the other in a future date. An early warning enables more time for potential corrective measures before a total failure.
We had a monolith that failed catastrophically. We fixed that and not only got the first system, but a redundant system to mitigate that failure. This redundancy comes cheap, less than 5% the cost of our main system. Between both we're poised to weather almost any storm the industry can throw at us.
Our chances of total failure are greatly diminished unlikely to be a 7-year impact if they occur at all.
SHARED VISION REQUIRED
With my Industry Architect hat on, I think we've achieved something very critical. We're setup to win. This of course only works if:
- We see them as one system.
- We want both to win.
- We are in synch on strategy
I definitely see them as one, want both to win (who doesn't want more ways to win) and for us to be ok strategizing together. It is clear this is where we have the most challenges, however.
PERHAPS TOO ADVANCED
It is an advanced strategy with some overhead. Possibly beyond our skill and vision to actually pull off. While I would be willing to give it another 5 years of effort, it's clear others are not. This strategy requires a majority to pull off.
If others want to throw in the towel now, I don't fault you. I just think it's a shame. I like to play games till I beat them vs just skipping the hard parts. But I get it. We will vote -1 and will not interpret those who vote +1 as "not getting it", "bad" or "enemies." We're still all one team.
IF WE RE-MONOLITH, LET'S DO IT FULLY
If we do move MicroProfile into Jakarta EE, I would want it fully absorbed including a namespace change to jakarta. My interest in MicroProfile is not emotional but strategic as detailed above. If we're going back to the monolith, let's do it right and not make our lives harder.
--
David Blevins
http://x.com/dblevins
https://bsky.app/dblevins
http://www.tomitribe.com
Vincent Mayers
Mar 24, 2025, 7:09:31 AMMar 24
to microp...@googlegroups.com
That’s a great summary David. Thank you.
Cheers
Vincent
Vincent Mayers
Atlanta Java Users Group
--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/microprofile/13D8CD3B-9F54-4426-96A6-B4C6CCD735AE%40tomitribe.com.
Arjan Tijms
Mar 24, 2025, 10:36:34 AMMar 24
to microp...@googlegroups.com, Microprofile WG discussions
Hi,
First point is what was the impact on our collective opportunity for Java EE in the industry due to our 7 year gap in delivering new functionality?
While the gap was undoubtedly far too big, and I've too cited this exact gap as the main reason Spring took over to the degree it did, it was actually a little bit less big.
Java EE 8 was released in mid 2017 and Jakarta EE 10 was released mid 2022, so it's 5 years really.
See also
* https://blogs.oracle.com/javamagazine/post/java-for-the-enterprise-what-to-expect-in-jakarta-ee-10
Kind regards,
Arjan Tijms
PERHAPS TOO ADVANCED
It is an advanced strategy with some overhead. Possibly beyond our skill and vision to actually pull off. While I would be willing to give it another 5 years of effort, it's clear others are not. This strategy requires a majority to pull off.
If others want to throw in the towel now, I don't fault you. I just think it's a shame. I like to play games till I beat them vs just skipping the hard parts. But I get it. We will vote -1 and will not interpret those who vote +1 as "not getting it", "bad" or "enemies." We're still all one team.
IF WE RE-MONOLITH, LET'S DO IT FULLY
If we do move MicroProfile into Jakarta EE, I would want it fully absorbed including a namespace change to jakarta. My interest in MicroProfile is not emotional but strategic as detailed above. If we're going back to the monolith, let's do it right and not make our lives harder.
--
David Blevins
http://x.com/dblevins
https://bsky.app/dblevins
http://www.tomitribe.com
Arjan Tijms
Mar 24, 2025, 1:23:20 PMMar 24
to microp...@googlegroups.com, Microprofile WG discussions
Hi,
First point is what was the impact on our collective opportunity for Java EE in the industry due to our 7 year gap in delivering new functionality?
Arjan Tijms
Mar 24, 2025, 1:40:59 PMMar 24
to microp...@googlegroups.com, Microprofile WG discussions
Hi,
On Mon, 24 Mar 2025 at 06:15, David Blevins <dble...@tomitribe.com> wrote:
- Brand damage: Since the early 2000s, frameworks like Spring aggressively positioned themselves against Java EE, painting it as large, bloated, legacy, slow to start, slow to evolve, and overly complex. The lasting reputational damage diminished adoption, and accelerated the shift away from the platform.
[...]
- High availability: Damage to any one brand enables us to shift to the other. Decline in one does not guarantee decline in the other. Cost sensitivity can be mitigated. Governance issues can shift participation to one or the other for periods of time without losing people entirely.
I raised exactly this point in a recent EE Platform call, but I did come to another conclusion.
Frameworks like Spring have indeed been incredibly successful in painting EE as large, bloated, legacy and all those other things. Even when an EJB was easier to configure with an annotation and Spring still required XML, even when JBoss at the time managed to start in 3 seconds and a comparable Spring app needed 6 seconds, etc etc Rod and friends did not stop telling the world EJB required tons of XML, interfaces and code generators, and took a minute to start.
Given this history and strategy, would that other brand not suffer the exact same fate should it become sufficiently popular to register on the radar of frameworks like Spring?
The bottomline; instead of one strong framework, we market two weaker ones (and confusing users), and all that in the *hope* that our competition will leave one of them alone in their aggressive marketing and blackening of our name(s).
What's to say these competitors will not also blacken that other name? Then we have two damaged brands. Would we then introduce a third brand, and when that is damaged again, introduce a fourth brand? While understandable, I don't feel this strategy would work in the end.
Kind regards,
Arjan Tijms
Reza Rahman
Mar 24, 2025, 1:41:13 PMMar 24
to microp...@googlegroups.com
We've shared our perspective on these dynamics in the past so I am thinking it is worth summarizing it here briefly just once more.
To be honest, we have been keeping an eye on this for a while now and it is far from easy to figure out. What is certain is that Jakarta EE is very far from out of the woods just yet. What is equally clear is that MicroProfile as a brand really has not succeeded, most definitely not as a serious challenger to the Spring ecosystem. In fact, it barely has significant brand recognition even after so many years. By comparison, it seems Jakarta EE actually fares a bit better as a brand. Why these are the facts is very hard to discern. It may be that MicroProfile is essentially seen as an offshoot of Jakarta EE and there is no practical way of changing that. This is the case even with Quarkus customers we have been able to talk to so far. This is despite the fact the Quarkus customers have the most significant brand association with MicroProfile. It gets worse with customers of Liberty, WildFly, Payara, etc.
I fully understand this is probably hard to hear for some folks.
Nonetheless, in good faith I am sharing what we really see in the
wild and we have been trying hard to understand.
--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/microprofile/CAGZXXAJNSLeZvqAftn_WQQ255Nbn8%2BV3f99AaaUsuD6s3SeeHg%40mail.gmail.com.
David Blevins
Mar 24, 2025, 1:43:21 PMMar 24
to microp...@googlegroups.com, Microprofile WG discussions
On Mar 24, 2025, at 7:36 AM, Arjan Tijms <arjan...@omnifish.ee> wrote:Hi,First point is what was the impact on our collective opportunity for Java EE in the industry due to our 7 year gap in delivering new functionality?While the gap was undoubtedly far too big, and I've too cited this exact gap as the main reason Spring took over to the degree it did, it was actually a little bit less big.Java EE 8 was released in mid 2017 and Jakarta EE 10 was released mid 2022, so it's 5 years really.
By that measure, yes. By actual experience in the time between 2014 and 2017 it was in practice dead and we all experienced the extreme stress, duress and despair of that fact.
Those were really the worst years for me at least.
-David
PERHAPS TOO ADVANCED
It is an advanced strategy with some overhead. Possibly beyond our skill and vision to actually pull off. While I would be willing to give it another 5 years of effort, it's clear others are not. This strategy requires a majority to pull off.
If others want to throw in the towel now, I don't fault you. I just think it's a shame. I like to play games till I beat them vs just skipping the hard parts. But I get it. We will vote -1 and will not interpret those who vote +1 as "not getting it", "bad" or "enemies." We're still all one team.
IF WE RE-MONOLITH, LET'S DO IT FULLY
If we do move MicroProfile into Jakarta EE, I would want it fully absorbed including a namespace change to jakarta. My interest in MicroProfile is not emotional but strategic as detailed above. If we're going back to the monolith, let's do it right and not make our lives harder.
--
David Blevins
http://x.com/dblevins
https://bsky.app/dblevins
http://www.tomitribe.com
--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/microprofile/13D8CD3B-9F54-4426-96A6-B4C6CCD735AE%40tomitribe.com.
--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/microprofile/CAGZXXALxtb8LDFm_JDKmmJ-rusLgbf7MgLR1L1F6Bbujqk-o8Q%40mail.gmail.com.
Buhake Sindi
Mar 24, 2025, 6:57:54 PMMar 24
to microp...@googlegroups.com
From my experience, the reason why Spring framework has been able to strive are the key things:
- They were very quick to adopt cloud technologies and quick to adopt trends (e.g., in the AI space, they have their own implementations to various LLMs and MCP, outside of Langchain4J).
- They are quick to market their features to the world and are not afraid to adopt social media to showcase their products.. Heck, I know many of my peers who wish to attend Spring I/O conferences. This level of "aggressive" marketing is not what I've experienced yet for Jakarta EE/Microprofile. I've just go stuck to the platform after my frustration of using Spring over the years.
Case in point: I get asked if I've ever met Josh Long but few know who Adam Bien is.
So, if we need to make JakartaEE great again, we will have to start adopting various platforms and let people create content driven approach to using Jakarta EE (if you get my drift).
I'm just highlighting what I see here (from the African perspective).
Kind Regard,
Buhake Sindi
I'm just highlighting what I see here (from the African perspective).
Kind Regard,
Buhake Sindi
To view this discussion visit https://groups.google.com/d/msgid/microprofile/2d829c33-ca66-4160-97ac-5268eb204339%40gmail.com.
Reza Rahman
Mar 24, 2025, 7:12:17 PMMar 24
to microp...@googlegroups.com
Super valid. We need to figure this out, even if everything isn't a spec right away or at least not a spec included in the platform right away.
To view this discussion visit https://groups.google.com/d/msgid/microprofile/CABUp4f5-egi3ewE4RvSVJKe3hJrE1_UA%2B%2BhBgCMs9DQaOeP5wA%40mail.gmail.com.
John Clingan
Mar 24, 2025, 7:17:14 PMMar 24
to MicroProfile
Spring create/implement technologies, Jakarta and MicroProfile create specifications based on what is successful in the marketplace. Specifications require some degree of technology success, so Jakarta will always follow an implementation.
Arjan Tijms
Mar 25, 2025, 3:03:11 PMMar 25
to microp...@googlegroups.com
Hi,
On Mon, 24 Mar 2025 at 23:57, Buhake Sindi <buh...@gmail.com> wrote:
From my experience, the reason why Spring framework has been able to strive are the key things:
What I personally saw, was that a brilliant strategic move was to hide what is essentially a complete platform, inside a .war. That way engineers could update the platform just by deploying a new war to application servers like WebSphere or WebLogic. In those early years (around 2005/2006) engineers were often forbidden to even look at the application server, let alone update it.
Whether intended or not by the J2EE architects, the split of J2EE in an application server that was only supposed to be managed by ops, and a war that was to be created by devs, has to be its biggest blunder.
With Spring, dev could take back control, and sneak its own server / platform into the war, with ops being supposedly unaware of that. The 2GB websphere installations were essentially reduced to being http proxies and perhaps data source providers. Ops was happily "managing the EJBs" (which of course weren't there). As I wasn't in an ops role, and at the company I worked with I always delivered the J2EE server + app as a unit, I'm not sure what even the idea was about "ops managing the EJBs". Perhaps that always was just a pipedream invented in some ivory tower that never actually happened.
Kind regards,
Arjan Tijms
To view this discussion visit https://groups.google.com/d/msgid/microprofile/CABUp4f5-egi3ewE4RvSVJKe3hJrE1_UA%2B%2BhBgCMs9DQaOeP5wA%40mail.gmail.com.
Reza Rahman
Mar 25, 2025, 3:12:23 PMMar 25
to microp...@googlegroups.com
Yep, I also observed this and continue to observe this even today on Azure. So many times we go into an engagement for "J2EE" but it turns out to really be a Spring migration instead. It's almost become a signal when "J2EE" is still mentioned.
To view this discussion visit https://groups.google.com/d/msgid/microprofile/CAGZXXA%2BuTpwPn6BXnhQ5cJq-SZniJX6CqJPs41aKNWhsETDRzg%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages