Red Hat Middleware moving to IBM

It's been a while since I wrote anything on my blog. I'm not even sure if blogging is a thing anymore! Maybe I should be recording a short TikTok video or overlay some commentary on a cute kitten YouTube video. However, until I figure that out, I'll stick with text and blogging. Fortunately, I also have something important to write about, which hopefully makes the long gap between my previous entry and this one worth the wait: the Red Hat Middleware move to IBM.

If you're not already aware, then you can read about the general idea in this article. In summary, after having a successful enterprise Middleware strategy and portfolio for almost two decades, it has been decided that our future is best served by moving to IBM and merging with their Java middleware teams. On the one hand, you might think that this was inevitable given the IBM acquisition of Red Hat, but on the other you would be forgiven for asking, didn't IBM do this in the opposite direction in 2020? In this article, I want to try to address these thoughts as well as what I actually think about this and the future of my team. It's important that I point out at this stage that everything I'm writing here is my personal opinion and not any official statement on behalf of Red Hat.

On the subject of whether or not this merger is inevitable, I agree. I've been acquired a number of times during my career and the fact that Red Hat has managed to retain so much independence for so long is a surprise to me. I remember talking with a few other Red Hat friends and colleagues in 2019 after the acquisition was announced and we all agreed that IBM would fold Red Hat into itself within a couple of years. Five years later and we were wrong, though clearly we've seen some fluidity between what products are the responsibility of Red Hat versus IBM, e.g., PAM/DM and Storage. Therefore, I do think it was inevitable that, at some stage, someone at Red Hat or IBM would turn their attention towards the two middleware businesses.

This brings me to the next point: didn't IBM do this already? Kind of. In 2020 IBM decided to move some of their Java middleware expertise to Red Hat, such as AdoptOpenJDK, Kruize Autotune, Node.js and developer productivity, as well as making the business decision that the Red Hat Build of OpenJDK would be the preferred OpenJDK/Hotspot distribution for IBM customers. However, they retained a significant business with technologies like WebSphere, Liberty and J9. Along with these, IBM retained its own strategy for enterprise Java which was distinct from that which Red Hat had created.

Alright, let's get to the important questions: why now and what do I think about it?

On the first question, I think it's a combination of things. I can't talk about them all, but I can mention some of the more important things that drove the decision. There's the fact that Red Hat wants to focus more on hybrid cloud and open source AI, which has meant reduced investment in middleware, as someone reported in El Reg last year. I need to be clear here: focus is not a bad thing and the open source enterprise software landscape is just getting larger and larger; even a company with pockets as deep as IBM cannot be the master of everything.

It's also precisely because of this need to focus that merging the two Java middleware efforts makes sense: better together! As Red Hat works more and more in the AI space, the emphasis is around Python, which to enterprise Java developers is often difficult to grapple with when they have such large Java-based applications already deployed. IBM recognises the need to bridge AI and Java but cannot do this by relying solely on its own middleware offerings. When you look at what Red Hat Middleware has to offer, the answer is pretty obvious: combine and innovate together!

And I suppose that then leads us to the second question: what do I think about it? Recently I hosted my annual Engineering Kickoff meeting, where I gathered about 50 senior managers and individual contributors from my organisation in the same place. We also hosted an All Hands meeting which was attended remotely by about 550 people! Of course, that question came up, more or less. Therefore, I'll try to answer it in the way I did in those meetings.

For a start, I do believe that, on paper, combining the teams makes perfect sense. IBM is one of the key companies that originally helped to popularise Java. This is in no way meant to ignore the great work Sun Microsystems did in creating and pushing Java. Still, I think if it hadn't been for companies such as IBM, HP, Dec and yes, even Microsoft at the time, Java wouldn't be the dominant language for developers we see today. It may be hard for many to cast their minds back to the late 1990s and comparing it with today is hard, but back then, it was these companies dominating the enterprise market prior to the advent of the Web and even for the first few years after it came to life.

Whatever you might think about the pros and cons of things like messaging systems, databases, transactions, DCE, CORBA, J2EE and Web Services, IBM was a dominant force in them all at the time and into the early 2000s. It's had its ups and downs over the years and I'll leave it to more involved people to talk about them, but overall I'd say that IBM has a rich history in the Java and Middleware space. Furthermore, many of IBM's products today are built on Java, so they definitely understand its relevance.

Now I also like to think that Red Hat and all those companies it acquired over the years, such as JBoss, FuseSource, 3scale and FeedHenry, have a lot of history in many of these same areas. I'd also say that, without question, our open source influence has been at least equally prolific and influential. Prior to the IBM acquisition in 2019, we also had a growing business taking out IBM, so there's always been some good rivalry there.

Looking at things objectively and, as I said earlier, perhaps as a paper exercise, combining two related businesses and teams into one makes sense. I know many of these groups and individuals have worked together for years in upstream communities. On a personal note, I count a number of IBMers as friends I've known for decades. None of us are “evil” and everyone at Red Hat and IBM wants to do the best for our communities and partners.

However, many "on paper" exercises don't turn into good reality and in this case, there remain a number of potential stumbling blocks. Let's quickly address the overlaps because I don't really believe these are that significant in the grand scheme of things. Over the last 5 years, both IBM and Red Hat have collaborated more and more on sharing efforts on innovation and products. Several of the IBM products embed Red Hat Middleware products or components. IBM uses the Red Hat Build of OpenJDK, where J9 isn't an option. IBM uses a number of our Eclipse MicroProfile offerings on their own.

I'm not going to suggest that there aren't going to be discussions around future product strategy. There are obvious questions to be answered, such as where do EAP and Liberty come together, or what about OpenJDK/Hotspot and J9? What about AMQ and MQ Series or various Apache Kafka efforts? What about Visual Studio Code java and Eclipse Java? As mentioned in Matt’s announcement, Red Hat customers will continue to buy our existing products from Red Hat and partners, including getting new features, fixes, etc. Everything will remain open source, in the same communities and with the same passion the teams have brought over the years. The future planning around cloud-native Java, including Quarkus, will need to take all of this into account.

This leads us very neatly to where I do see problems and we all have to work seriously to alleviate them. What I'm about to outline may well be just perception on the part of 600+ people, but it will directly impact the success of any such endeavour.

Our two cultures are very different, even after 5 years of being part of IBM. As some of my extended team have pointed out, even the culture within my organisation is different from the wider Red Hat culture. That difference is seen by the associates in my organisation as a positive and important thing to preserve. I'm not just talking about the different ways in which Red Hat and IBM approach open source. Rightly or wrongly, there is a strong belief that IBM has a very top-down approach to strategy and business, whereas in Red Hat, it has largely been driven the other way. Some of this is definitely a result of Red Hat's roots and a community-first mentality. Still, our engineering and business leaders stay in place for a long time compared to their IBM counterparts and that helps to build strong trust relationships internally and externally. Amongst other things, this leads to a very autonomous approach in my organisation/business for driving strategy and delivery.

As I told my entire organisation, our culture doesn't come as a right because we are Red Hat: we all shape it, nurture it and allow it to evolve… or decay. Therefore, if our culture is important to us, it's something we can take with us and fight for wherever we end up. I've discussed this within Red Hat and IBM and they all agree that this move is not meant to change our culture and they recognise that it is an important part of how we function and deliver value to our customers. Therefore, changing it will be detrimental to our continued success. I have made the commitment to my entire team that our culture is something I want to protect, or I won't be involved.

This is one of my "red lines". These are commitments or promises that I've obtained from Red Hat or IBM, which I believe are necessary to maximise the chance of success for this move. There aren't many of them and in my view, they're all reasonable. However, I've been clear that these things are not negotiable, or we risk losing key associates, communities, customers, etc. If this move is truly going to bring the best result for everyone, then Red Hat and IBM need to deliver on these commitments and I’ll continue to help them do that. Failure to do so risks attrition of myself and many others.

So far, I am pleased to say that both companies agree and are giving my team and me the support to bring our culture and processes with us. I know many of you reading this will already be asking yourselves, "For how long?" and you aren't alone, as it's something many in my team are also asking. I don't know the future, but I do know that if their response changes then they cross that red line. These things aren't just important for the initial transition, they are important for the duration. It's important to know that this isn't about me; it never was. I've had the privilege to work with a growing team of committed and passionate people who are responsible for the success of the business and it's them I'm doing this for now. They're my extended family!

Some may read these ‘red lines’ as threats. Nothing could be further from the truth. In the opinion of myself and others, these items are key elements needed to ensure our success regardless of the name on the letterhead. They can't be taken piecemeal. If there's no commitment then what's the point in all of this? I'm at a stage in my career where I want to invest my time and energy in things that I truly believe are worth it, or I may as well stop and take up lion taming!

As we move forward with the transition, I’m convinced that the IBM people we are working with are authentic and want to make this a success too. For example, I’m just back from a few days in Raleigh meeting with the Red Hat and IBM leadership teams and I thought that was a pretty positive experience. In general, Red Hat has been good at treating my team fairly over the years, which has been a part of our corporate success. If IBM can continue that tradition, then the transition could be as simple as moving from one good home to another. I know speaking with a number of IBMers, they also seem to feel treated well by IBM, so that’s a good start. While the positivity and goodwill continue, I’m more than happy to continue to lead the organisation and help define the future of enterprise Java well into the future.

Conversely, if the support we need for our culture, upstream first approach etc., falters, it will affect how the team works and how our communities and partners trust us. That would be a bad thing no matter which company we were working for if it happened and I think the results would be obvious. However, if I was really worried that might happen, then I could put a pin in it right now and stop. I’m not going to because this team and this business are worth the effort and so far, IBM and Red Hat agree.

 

Farewell Rob ...

This year has definitely been shitty for many people globally for a number of reasons. To add to that, I just heard that a long time friend of mine died the other day from pancreatic cancer. I could write about him but another friend of ours, Mike, already did and very eloquently. Therefore, I'll just link to his entry and send Rob's family my condolences. I'll also toast Rob tonight along with all the good memories we share!

Community driven innovation and freedom

Picture this ... a world where we have an industry with open source innovation at its heart. Communities come together to tackle problems. Majority decisions are made in the open through mutual respect and often lots of discussion. Differences of opinion are a reality inside these open source communities as outside.

In this world if you don't like the way a community is heading then you get involved and try to persuade them to change and understand your point. If there are many more people who believe the same then they get involved too and maybe that community changes direction. But in this reality you don't complain when a decision goes against you ... you respect the choices the community makes and you have the freedom to go and try to create your own community elsewhere if that's the best option.

You also don't complain about a community when you've had minimal or even zero involved. You don't complain about dominance of communities by vendors or individuals if you fail to get involved or fail to get a majority of like minded people active enough for them to gain voting rights.

Even without voting rights or until they are obtained, influence is something which is possible because everything is discussed in the open. In this ideal world you get involved and help. You spend the time to earn the same rights as others. You expend the time and energy and do the work that is required to gain those voting rights because they are a privilege and not an automatic right. However, if something is important to you then you spend that time to earn it.

Sometimes I think we live in this world but then I wake up!

Don't default fork MP into Jakarta EE

There should be no default rule for the relationship between Jakarta EE and MicroProfile because each MicroProfile specification is often driven by a mix of different developers, vendors and communities who may not want their efforts forked. To ignore them is tantamount to a hostile take-over. The Jakarta EE communities should work with them and try to persuade them to see their point of view. However, if the MP spec community cannot be persuaded then I caution continuing with a fork. Embed and try to work together because the MP spec should still be usable within Jakarta EE. And working with the original community is a far better path to future success than trying to split efforts - anyone remember Hudson these days?

If no way to collaborate can be found, including simply embedding that spec into Jakarta EE, then I'd suggest that there is something fundamentally wrong with that specific MP community or those in Jakarta EE. I really can't see this ever happening though so it's not worth further consideration.

Then there's the notion of changing the namespace of a MP specification if it is "imported". Well I also don't think that should be a hard and fast rule either. It should be something that is worked out between the MP specification in question and the Jakarta EE community. It should also not be a reason to reject importing and collaborating with the MP community and defaulting to a hostile-like fork.

And that brings me to the final question: where does work on the MP specification continue, assuming it does need to continue? Well guess what? I think that's up to the MP spec community since they are the founders of their work and their future destiny. If they feel that innovation should shift entirely to Jakarta EE then go for it, with all of my support. But likewise, if they feel innovation should continue in MP and maybe they are a part of the corresponding Jakarta EE community they work to pull updates across when it makes sense. A great collaboration.

That time again ... September 11th

Yes, it comes around again. This year I decided to link something more for Ed. My thoughts are with his family as usual. And mine.

Community, Jakarta EE and MicroProfile

I've written a lot recently about the future of Eclipse MicroProfile and Jakarta EE recently. If you're reading this then hopefully you'll have seen those other entries (if not, scroll up?) I've taken a personal stance which may not be exactly the same as Red Hat's stance but as I've said already, this is a tricky series of connected decisions the entire community needs to make and there's no right or wrong answer. However, I wanted to write one more smaller article to just say thanks to the community for their very active involvement in the conversations. Whether through the email threads which have been kicked off, Twitter, face-to-face in various timely conference sessions, etc. it's warming to see the interest in the topic and the passion as well as commitment to the future of enterprise Java. I hope this doesn't wane as we move forward. As one of my predecessors used to say: Onward!

Transitioning Jakarta EE to the jakarta namespace

Note, this is just a copy-and-paste from the original email sent out by the spec committee. Placed here to try to maximise involvement.

[Contents of this email represent discussions of the Jakarta EE Specification Committee over the last several meetings.  The statements here have been reviewed by and represent the voice of the Jakarta EE Specification Committee]

As announced in the Update on Jakarta EE Rights to Java Trademarks[1] post on Friday, future modification of the javax namespace will not be allowed.  While this is not what was envisioned when Jakarta EE started, in many ways this in our best interest as the modification of javax would always have involved long-term legal and trademark restrictions.

To evolve Jakarta EE, we must transition to a new namespace. The primary decisions we need to make as a community and industry are how and when. Given all delays and desires on everyoneâs part to move forward as fast as possible, we would like to have this discussion openly as a community and conclude in one month. It is the hope that in one month a clear consensus emerges and can be presented to the Specification Committee for final approval.

In an effort to bootstrap the conversation, the Specification Committee has prepared two proposals for how we might move into the new namespace. These should be considered a starting point, more proposals are welcome. No final decisions have been made at this stage.

The guiding principle for Jakarta EE.next will be to maximize compatibility with Jakarta EE 8 for future versions without stifling innovation.

Other proposals should incorporate the following considerations and goals:

• The new namespace will be jakarta.*
• APIs moved to the jakarta namespace maintain class names and method signatures compatible with equivalent class names and method signatures in the javax.* namespace.
• Even a small maintenance change to an API would require a javax to jakarta change of that entire specification. Examples include:
• Adding a value to an enum
• Overriding/adding a method signature
• Adding default methods in interfaces
• Compensating for Java language changes
• Binary compatibility for existing applications in the javax namespace is an agreed goal by the majority of existing vendors in the Jakarta EE Working Group and would be a priority in their products. However, there is a strong desire not to deter new implementers of the jakarta namespace from entering the ecosystem by requiring they also implement an equivalent javax legacy API.
• There is no intention to change Jakarta EE 8 goals or timeline.
• Community discussion on how to transition to the jakarta namespace will conclude Sunday, June 9th, 2019.

It is envisioned binary compatibility can be achieved and offered by implementations via tooling that performs bytecode modification at either build-time, deploy-time or runtime. While there are open questions and considerations in this area, the primary goal of the discussion that must conclude is how do we move forward with future modifications to the APIs themselves.

Proposal 1: Big-bang Jakarta EE 9, Jakarta EE 10 New Features

The heart of this proposal is to do a one-time move of API source from the javax namespace to the jakarta namespace with the primary goal of not prolonging industry cost and pain associated with the transition.

Were we to take this path, a compelling approach would be to do the namespace rename and immediately release this as Jakarta EE 9. Additional modifications would be put into a Jakarta EE 10 which can be developed in parallel, without further delays.

• Some or all Jakarta EE APIs under javax would move immediately into jakarta as-is.
• Any packages not moved from javax to jakarta could be included in Jakarta EE, but would be forever frozen and never move to the jakarta namespace.
• Jakarta EE 9 would be refocused as quick, stepping-stone release, identical to Jakarta EE 8 with the exception of the javax to jakarta namespace change and immediately released.
• Jakarta EE 10 would become the new release name for what we imagined as Jakarta EE.next with only minor impact on timeline.
• Work on Jakarta EE 10 could start immediately after rename is completed in the GitHub source and need not wait for the Jakarta EE 9 release to actually ship.

Pros:

• One-time coordination and cost to the industry, including; conversion tools, users, enterprises, cloud vendors, IDE creators, platform vendors, trainers and book authors.
• Easily understood rule: everything Jakarta EE 8 and before is javax, Jakarta EE 9 and after is jakarta
• Consistent with the javax to jakarta Maven groupId change.
• Highest degree of flexibility and freedom of action, post-change.
• Industry would have the opportunity to begin digesting the namespace change far in advance of any major new APIs or feature changes.

Cons:

• Largest upfront cost for everyone.
• Specifications that may never be updated would still likely be moved.
• Decision to not move a specification is permanent and therefore requires high confidence.

Decisions:

• Which specifications, if any, would we opt not to move?
• Would we take the opportunity to prune specifications from Jakarta EE 9?
• Do we change the language level in Jakarta EE 9 to Java SE 11 or delay that to Jakarta EE 10?

Proposal 2: Incremental Change in Jakarta EE 9 and beyond

Evolve API source from javax to the jakarta namespace over time on an as-needed basis.  The most active specifications would immediately move in Jakarta EE 9.  Every Jakarta EE release, starting with version 10 and beyond may involve some javax to jakarta namespace transition.

• The most active APIs would immediately move from javax to jakarta
• APIs not changed or determined by the community to be unlikely to change would stay in javax
• Jakarta EE 9 would be a mix of javax and jakarta packaged APIs
• If a change was needed to a javax API post Jakarta EE 9 for any reason, that API would transition from javax to jakarta.
• Jakarta EE 10 would be a mix of javax and jakarta packaged APIs, but a different mix than Jakarta EE 9.
• At some point down the road, Jakarta EE xx, it may be decided that the migration from javax to jakarta is âdoneâ and the final APIs are moved.

Pros:

• Cheaper up front cost and reduced immediate noise.
• No need to move specifications unless there is an immediately visible benefit.
• Potential for less impact from API change overall.

Cons:

• Prolonged coordination, cost and complexity to industry affecting conversion tools, users, enterprises, cloud vendors, IDE creators, platform vendors, trainers and book authors.
• Use of restricted javax namespace prolonged.
• Frustration of âalways changingâ packages may deter application developers and become a permanent perception of the brand.
• Difficulty in remembering/knowing which Jakarta EE release an API was moved. âIs Connector javax or jakarta in Jakarta EE 11?â
• Difficulty in keeping the industry in sync.
• New implementations may find themselves having to deal with the javax to jakarta transition, unable to avoid legacy costs and therefore decide not to enter the space.
• Transitive dependencies to other specifications may make incremental change difficult or impossible.
• Restrictions on what Java SE implementation can be used for certification

Decisions:

• Do we start small or start large?
• Which APIs would immediately need to be changed?

Out of Scope

The following are very important community discussions, but do not require a decision in the time-frame allotted:

• Roadmap or release date for any Jakarta EE.next that would contain new features
• List of specifications that may be deprecated, pruned or removed from Jakarta EE.next, if any
• Specification text around backwards compatibility requirements, if any
• What profiles should be defined

However, depending on the path chosen, some of these topics may require immediate resolution before the chosen path can be executed.

[1] https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/

Evolving Jakarta EE

In the second of my additional blogs triggered by the recent javax announcement, let's look at another of the options I mentioned for moving forward. If we decide not to pursue the option to freeze Jakarta EE for stability and focus our combined innovative efforts on MicroProfile, but instead agree to innovate within Jakarta EE then what do we need to do to succeed with the alternative, i.e., what do we need to do to make Jakarta EE successful? Well let's first start with the understanding that to go down route we must therefore believe Jakarta EE is the best place to innovate for cloud-native enterprise Java and no place else. Splitting efforts doesn't help at this stage in the history of the ecosystem: we need the community to coalesce and collaborate on this.

With that in mind we, and by that I mean existing vendors, the communities of users and contributors, partners, etc., have to get far more involved in Jakarta EE than many have with Java EE to date and particularly of late. We need evangelists, we need developers, we need testers, we need writers, we need so much more to fill in the gaps left by previous individuals or vendors who cannot be expected to put in as much time and effort as they have in the past. And critically we need this to happen in order to convince the industry that there's a groundswell of support and investment behind Jakarta EE which makes them stand up and take notice.

The Eclipse Foundation needs investment too and it can't all be on the original main vendors to provide. Because Jakarta EE is now at the Eclipse Foundation this makes that kind of participation possible because there are no barriers to active involvement as perhaps there were when Java EE was in the JCP. Those old reasons (dominated by a single vendor, trademark concerns, not all things open source) go away. That's good because there's a lot going on within Jakarta EE and some of the specifications definitely should be evolved whereas others should probably be deprecated. Furthermore, new specifications need defining, implementing, testing (for compliance with a TCK) and including within subsequent releases. That's effort which has to be shared and this time the community must get involved. If the future of Jakarta EE relies solely on the same vendors and individuals as Java EE then we have failed in one of the most basic of reasons for moving to the Eclipse Foundation.

There's another reason we would need to come together behind Jakarta EE innovation and that's related to the shadow the recent javax announcement has likely cast over things. No matter how positively we want to spin things there will no doubt be some tarnishing of the image which could turn people away or even convince them to leave. If we (the community) can do all of this together then any possible tarnishing of the Jakarta EE brand could well be polished away and perhaps Jakarta EE can have a bright future.

Why MicroProfile after javax?

It wasn't my intention to write more on this topic as I want the discussions to be had in the community forums. However, since writing my first article I've seen some confusion on the Twitter-verse and perhaps some FUD so I figured I'd write a couple more articles here, of which this is the first. Hopefully they help fuel the debate.

Hopefully you've read at least my JBoss blog about the javax namespace problems and my personal blog outlining my preference for how we move forward from this point. Since posting them both I've read a number of people ask “Why MicroProfile?” Or “Why can’t we just innovate in Jakarta EE?” I want to try to answer those questions but recall this is still my personal opinion not that of my employer.

I think what some people are missing is that I'm not arguing against innovating with Jakarta EE components. I'm discussing where to do that innovation and why. And this isn't an easy choice for our community to make. No matter what we do there are risks and I want to make sure everyone understands that there are no right or wrong answers here. As long as we make an informed decision as a community I'm sure we can move forward constructively. I'm sure some people won't agree with the decision(s) but as long as we have a good debate I hope everyone will get behind the new direction and put their feelings aside.

OK so back to the original questions about why I'm suggesting we focus our innovation efforts around MicroProfile. Well think of it this way: if there was no MicroProfile and we wanted to evolve Jakarta EE today then where would we look for influence and inspiration? If “The Cloud” isn’t in your top 2 then you should probably go sit this one out. Now that leaves us with the obvious question of where do we do this work? My preference, as I've already mentioned, is MicroProfile and make Jakarta EE the stable solution for existing Java EE end users. I'm not saying this because Red Hat has a MicroProfile product, which we clearly do, but we also have an industry leading Java EE product, just in case anyone missed that! This is about developers and end users. And what they want today. In big shops and small. For their new applications. Cloud is their biggest concern and how to develop for it.

Naturally we could evolve Jakarta EE towards cloud-native. That was the original remit for Jakarta EE after all. But I believe the namespace issue changes things because prior to this we were probably going to be able to get away without having to touch much of Jakarta EE, or perhaps not for some time anyway. In the meantime we'd be able to focus on those aspects of it which are needed in that particular problem space, bringing in new things which aren't there too (e.g., Istio integration). But clearly that isn't going to be possible now and we're going to have to invest some time and effort in all of the specifications.

Now you can argue how much effort that will be but even if the code changes can be masked to end users, they still need to be made within the TCKs, docs etc. And of course there is the knock-on effect on training courses for Java EE 8, books etc. It will all take some time. It will likely divert the attention of many people who could well be used to help innovate. And in that time what else happens in other areas of our industry which we may miss? Is the rest of the world going to stand still? We risk stagnation and developers migrating elsewhere, which is precisely why Red Hat, IBM, TomiTribe, Payara and others created MicroProfile in the first place over three years ago. Let’s face it, Java EE innovation stagnated for quite a while. MicroProfile represents the most intense effort of innovation any of us have seen based on a select number of aspects of Java EE for many years. As a Java EE community we should all be proud of that and not see it as a threat!

A threat, I hear you ask? Yes, apparently some people are now suggesting MicroProfile is a threat to the future of Jakarta EE, despite the fact the latter exists today due to a number of factors and MicroProfile is up there near the top! I'm not going to even stoop so low as to respond except to remind everyone that very few companies have as much invested in Java EE than Red Hat so anything I discuss here is not done without careful consideration. If that doesn't help then nothing willl.

Anyway, back to the question at hand. The logical alternative to starting to evolve Jakarra EE towards cloud native is to jump to the end game, or somewhere on that road. And I believe that MicroProfile does precisely that for enterprise Java. Recent surveys from the Eclipse Foundation and others back up this assertion. The MicroProfile community has done a great job so far and should be congratulated.

If you've looked at MicroProfile recently then you'll know it uses a few Java EE specifications, such as CDI and JAX-RS. It doesn't seem to need more than those just yet. However, if more Jakarta EE pieces need to be evolved then pull them in. Push them back to Jakarta EE if needed but don’t make that a requirement. Use the momentum that we've all built up around MicroProfile to keep driving forward. Maybe some Jakarta EE specifications need replacing completely for the cloud, e.g., transactions or messaging. Reactive is not something which can be easily applied to all of the current Jakarta EE specifications so why not just start with a much more focussed (limited specifications) approach, as MicroProfile is doing? Can you imagine the can of worms we might open if we wanted to make Spec A reactive only to find that impacts B, C and D, with other cascading impacts from them?

So if the community still believes that pieces of Java EE have a role to play in cloud-native microservices, I suggest MicroProfile is already a far better starting point than where Jakarta EE is today. Now as I stated in an earlier blog post you might not agree with me and that's fine. Perhaps the reader believes there’s something else other than cloud-native microservices that people want to innovate around using Jakarta EE? Great, let's hear it and open a discussion. How many people are willing to contribute their time and maybe even money to it? If Jakarta EE is to not only survive this javax namespace issue but thrive then it needs people to stand up and be counted against GitHub commits.