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.

To Enterprise Java and Beyond! A personal perspective.

Ok so the title isn't quite what Buzz Lightyear said but cut me some slack, it's been a long day! Earlier I posted a blog about the results of the negotiations between Oracle and the Eclipse Foundation around IP transfer for Eclipse Jakarta EE and how they didn't go the way many of us had expected 18 months ago. The upshot of this is that the Java EE community is at a crossroads and I'm going to outline the options I see and give my own preference. Note, we are discussing these things within Red Hat now and have no firm conclusion so far, hence why this is on my personal blog. Therefore, don’t read this as a formal statement from Red Hat - it is not and these are just my own thoughts and opinions. If you know anything about Red Hat then you'll understand that even though I sit where I do in the organisation that doesn't mean I get a veto!

Before I jump in I want to make something clear from the outset. Anyone who knows me knows I've been involved with Java and Java EE (J2EE) from the beginning of their history. In my own small way I like to think I've helped shape them both, whether as a specification lead or a member of the JCP EC. I may not be a Java Champion but I'm a champion of Java - see what I did there ;) ? The reason I call this out is I'm pretty sure I understand the positive influence they've both had on the industry over the years, whether through explicit efforts like application servers and the raft of specifications needed to build them for a distributed environment, or implicit because many of those same specifications are embedded and often hidden in some of our most popular frameworks or stacks. I'm not writing this from the perspective of a vendor, or because I'm on some ego trip, or even anger at the way things turned out. A few of us have known that this day was coming and it's given me a chance to try to think about the future objectively.

One of the key things that Java EE has prided itself with over those years has been compatibility which has helped ensure application portability. With a few exceptions and application written against those standards ensured an application could be moved between different compliant vendor implementations. And something which is often overlooked is the backwards compatibly such that it was typically possible to easily migrate to the next revision of the specification and hence implementations. That compatibility helped a lot of developers build applications which have stood the test of time with little to no modifications. In short, they could develop their apps in the pretty safe knowledge that they'd keep working over the years until or unless there was a need to add new functionality or take into account some breaking change in the standards.

Alright so with all of that said, where do the most recent announcements take us? Well put simply, if the community want to modify a Jakarta EE specification that is under the javax namespace then:

• The namespace needs to change from javax to something else.
• The specification name needs to change, e.g., no more JMS (note, as my youngest son pointed out to me the other day JkMS may not be good as his generation assume JK is shorthand for joke!)
• The TCK needs to change.
• The RI needs to change. I know we don't have the concept of RIs in Jakarta but there are implementations in Glassfish which have need drive the specifications.

Now let's think of what that means for developers who use these specifications, either within Java EE implementations or elsewhere:

• Their application code needs to change.
• Their test suites need to change.
• Potentially any 3rd party code reliant on the specification needs to change.
• Potentially any code reliant on the original developer code needs to change.

If you’ve ever used one of the Java EE specifications or even other specifications from other standards bodies, then you’ll know that depending upon the original reason for wanting to modify the specification, all of the above changes and necessary coordination across developers and possibly different vendors might well be worthwhile. The modifications could be that killer feature needed to catapult dependant applications to the next level or close that crucial security flaw. Changing your applications to accommodate such modifications isn’t something you might want to do from the start, especially if they appear to be working fine anyway, but any concerns can often be quickly overridden through understanding the motivation.

Going back to those crossroads, one of the roads we could go down is what a few people are advocating: a Big Bang approach after Jakarta EE 8 is out to just get the whole issue around javax out of the way in one fell swoop. This would mean changing all of the specifications and take the hit with developers, communities and customers all in one go. I'm not convinced that's the right thing to do though I'm willing to listen to the community, but here's why I start from my position:

• It clearly breaks backwards compatibly and from the perspective of an end user that's not necessarily a good thing for all the reasons I mentioned before. Yes it "finally removes all Oracle control" as some have suggested, but I suspect most users of Java EE don't care about that, especially as they ignore it for other areas of our ecosystem like OpenJDK. So this could be an uphill struggle to convince people it's a good thing. Bad enough for one specification let alone all of them. In fact it could have the unintended affect of driving people away from Jakarta EE because if they have to change code anyway then why not look at all options, such as other frameworks, stacks or even languages.
• We need to stop thinking about developers of Application Servers or their components and think about our end users who are not necessarily as well versed in the politics we often take for granted. A "one time hit" for us could be death by a thousand cuts for our users, communities and customers.
• Going back to my original statement earlier about why a specification may have to change and why users may be ok with that, it all hinges on the definition of what constitutes a critical update to the specifications. Just changing the namespace doesn't count in my book (annoyance with Oracle isn't necessarily something people elsewhere care about, as I said earlier). I've heard that we should adopt Java 11 (like Java EE 8, Jakarta EE 8 only requires Java 8) and maybe suggest that we have to change the specifications somehow anyway as a result, so the namespace change is therefore forced on us and users. Well that doesn't work either because most vendors already support Java 11 without any changes to the specifications.
• OK what about JPMS I hear you say? That's a part of Java 11 so we could take to opportunity to embrace modules for the specifications and again address the whole namespace issue at the same time. Look, I'm not going to rehash the whole Jigsaw debate from the other year but I think the jury is still well and truly out at the moment as far as JPMS is concerned so suggesting that this will do anything but alienate a large swathe of users is strange at the very least. JPMS is not a good reason to break compatibility for end users of something so mature and so well adopters as Java EE.

I cannot see any good reason (good for end users) that makes a wholesale change to the specification namespace worthy. Now that doesn't mean the community won't decide to go down that road, but if they do then they need to understand the potential potholes that are lying in wait. I've mentioned some of them and they could be so big as to derail the entire journey. Changing all of the specifications will require a lot of effort from vendors and communities to get behind the code changes, bug fixes etc. No one should be under any illusions that the developers and vendors who brought Java EE to where it is today are necessarily going to be able to commit as much to Jakarta EE in the future - the wider community is going to have to step up and fill in the gaps in effort and potentially monetary investment too. These specifications and implementations don't write themselves! One other thing to take into account: whilst the larger vendors can probably afford to make this kind of investment of time and people to change their implementations, it's entirely possible some smaller vendors won't have that luxury and that could reduce diversity.

That's one of the routes from this crossroads outlined. What about another? Well the clear alternative to the wholesale change option is to do it gradually as and when meaningful modifications to the specifications are needed. That then raises the obvious question about what is the future direction for Jakarta EE? Let’s try to answer that before we venture down this other road.

Those of you who have followed this adventure from the time we stood on stage at JavaOne 2017 will know that we said we wanted it to be the home of cloud native Java. That made perfect sense as we believed we could evolve the existing specifications seamlessly and eventually merge or otherwise collaborate with MicroProfile, which sprang up over a year prior to the JavaOne 2017 announcement. However, in this new world I'm no longer sure that makes sense and here's why:

• The use cases which drove the development of Java EE remain extremely relevant today as evidenced by size of the market. When you factor in those other frameworks and stacks which use components of Java EE (specifications and implementations), that size grows further. Those users typically want stability, compatibility and cautious evolution. But changes happen; Java EE today isn’t the same as J2EE in the beginning. That’s been fine over the last 15+ years as new specifications appeared in the javax namespace and modifications to existing specifications likewise. This is goodness. However, we have to recognise that Java EE hasn’t evolved rapidly over the years. The 18 month delay around Jakarta EE hasn’t exactly helped either. New specifications and updates to existing ones haven’t exactly been driving to a rapid release cadence release. Don't get me wrong though, that isn’t necessarily a bad thing: stability, maturity and reliability are good things after all and I believe many of today's long time users take that for granted and expect it.

• Slowly evolving the stable standards and implementations as and when, helps to give users the chance to evolve at their own pace too and often only when significant changes happen. In fact it’s not rocket science to see how the old javax namespace implementations could reside alongside their updated Jakarta namespace siblings at the same time if we went this route.

Stability is the operative word then and therefore, I think we should re-evaluate our direction for Jakarta EE in light of the namespace debacle which clearly has the potential to throw that out of the window. It’s no disservice to the community and implementers to suggest that focussing on stability and existing use cases should become the priority for Jakarta EE. They represent the backbone of our industry. If something significant comes up later that requires a change to a specification then we evolve only that specification, as I mentioned above.

What about new specifications though? Where do they get added? Well for now let’s assume that this route at the crossroads (this option) doesn’t preclude adding of new specifications to Jakarta EE, which would clearly have to be under a non-javax namespace, but we’ll put that topic on hold for a moment whilst we look at the final option at the crossroads where we find ourselves.

I think we can all recognise that there are new use cases for new deployment environments such as the cloud or IoT which have shown that Java EE isn’t necessarily the right answer. The community and vendors saw this when we all kicked off Eclipse MicroProfile and over the 3+ years since that effort started we’ve seen a lot of activity, many more implementations than Java EE Application Servers, and a number of rapid releases annually.

Whilst MicroProfile uses some Java EE specifications, it doesn’t need them all at the moment and might never. Some implementations can use Java EE Application Servers as a result of this. However, much of what has happened in MicroProfile has resulted in more non-Java EE specifications than Java EE and more implementations that don’t rely on Application Servers at all. It is a vibrant community evolving enterprise Java to be cloud-native faster than Java EE has so far been able to do. And it has a familiar feel to it as many of the same vendors and communities have become involved. Though if you look at the list of supporters and participants in the community you'll see many new names there, both big and small.

As I mentioned, MicroProfile relies on a few Java EE specifications at the moment, e.g., JAX-RS and CDI. If that community needed to evolve them then it would naturally need to either change the namespace as we’ve already covered, or perhaps replace them wholesale with entirely different approaches, though that has its own pros and cons. However, because MicroProfile doesn’t rely on many Java EE specifications, and when and where it does the use cases MicroProfile has will likely be satisfied with the stable javax versions anyway, it’s probable that the impact of any namespace changes is already much more focussed, meaning users are that much less likely to want to consider jumping ship.

Since the point we announced Jakarta EE and began working on it we've been asking the question about whether and how MicroProfile might merge into Jakarta EE, perhaps providing the innovation branch of it. But if the community wants to evolve Jakarta EE to cloud-native, I believe it makes more sense given the recent announcements to jump straight there and anoint MicroProfile as the place where that work continues to happen, pulling over specifications from Jakarta EE only where needed, modifying them only when there's a good reason. We don’t want to split the community and cause yet more confusion or delays and whilst some may want to continue driving Jakarta EE forward to conflict with MicroProfile, that risks fracturing the efforts and not capitalising on the momentum happening there now. Therefore, if new specifications were to be considered to be added to Jakarta EE around cloud-native, my preference would be for them to be moved to MicroProfile instead. And of course that doesn't mean they can't be taken back in to Jakarta EE if and when new releases are deemed necessary.

OK so you've gotten here and you'd probably like a summary of the options as I see them so here goes:

1. The Big Bang approach and change all of the javax namespace at Jakarta EE 9 to something else. Not my personal preference as it risks alienating a lot of end users, driving them elsewhere and possibly reducing implementation diversity.
2. Focus on stability and compatibility for Jakarta EE and evolve specifications and namespace only as and when new and significant modifications to them are needed, such as new features, bug fixes etc. New specifications can be added here too but clearly not under the javax namespace. I'm more keen on this option but the communities need to agree on the use cases as there's a possible conflict with MicroProfile.
3. Agree that MicroProfile is the place to evolve Jakarta EE specifications if they need to become more cloud-native. MicroProfile will likely look forward though and add more and more new specifications and only pull across specifications from Jakarta EE when really needed, as has been the model to date. My preference, in case it wasn't obvious.

Now maybe there are other options, such as significant reasons for why Jakarta EE should evolve in directions not covered by MicroProfile. And of course option 2 and 3 aren't necessarily mutually exclusive if we can find other meaningful use cases for evolving Jakarta EE in option 2. It’s also possible some people won’t agree with my assessments. For me those are all good and acceptable outcomes from reading this article. I’m a scientist and if new information comes to light which impacts a theory I’ve created then I’ll re-evaluate. But what I caution everyone against is making rash decisions in the heat of the moment, especially if they are fuelled with the “let’s stick it to Oracle and get this done!” That attitude won’t lead to the right outcome and we could then spend many years regretting it.

The next step should be discussing this in the communities and not just the Jakarta EE community. The MicroProfile community is just as tied into the future of Jakarta EE. How we move forward with both is important to both. Let’s do this together and make the right consensus driven decision. This is a tricky time and we shouldn't rush to a decision on partial facts or worse still, anger and frustration.

Why Quarkus?

One size rarely fits all. I've written about this a number of times, for instance on the topic of extended transactions. In the world of building architecture that rule applies too or we'd all be living in caves! The Red Hat/JBoss middleware developer strategy for many years has recognised this fact and we support the frameworks and associated stacks for a wide variety of developers to use when building the next generation of microservice-based applications. Because polyglot is the normal situation today it does not just focus on Java, hence why Node.js is in there. Furthermore, not all new applications will be build from scratch; there has to be a way for existing applications to evolve and similarly for existing developers to evolve their skills rather than having to start from scratch.

As anyone who has been in this industry long enough knows, existing investments remain with us for years (decades in many cases). We can’t just throw them out the window when something new comes along. Neither can we throw the people out the window! Therefore, appealing to so-called brownfield developers is critical because it allows them to leverage their existing skills and key knowledge which likely has built up over many years. Brownfield can include:

• building new services and applications which require/leverage/integrate with existing systems but where the new components are developed in some new framework or approach;
• evolving existing systems, components and services built with mature (I hate "legacy") frameworks and stacks towards newer styles. One example of this would be the evolution of CORBA to J2EE.

So whilst it might look like adding Quarkus to the mix confuses things, it really doesn’t, or at least it shouldn’t and here’s why: there’s a spectrum of developers and applications and our approach attempts to cover the important areas of that spectrum. Specifically there's no one tool or framework right for the entire application or developer and you’ll need some or all of Quarkus (remember, it combines [will combine] serverless with Camel-K/Fuse, our core services on Kubernetes, such as [xPaaS] SSO, transactions, messaging, and uses Eclipse Vert.x for reactive and Eclipse MicroProfile/SmallRye), with EAP/WildFly if you need Java EE/Jakarta EE. And crucially, wherever your app is developed or deployed, they will be able to communicate and interact seamlessly as if developed with the same technology stack.

We’ll be talking more about how this all comes together in the coming weeks and months but another important point to remember is that we’re driving this upstream first, as we always do within JBoss/Red Hat. In fact Ken Finnigan's recent blog about the future of Thorntail is one of those important next steps. So if you want to get involved and help influence the technical direction please do! There are multiple entry points, i.e., you don’t need to start with Quarkus if you are more interested in Keycloak, or WildFly or Narayana (yeah!)