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.