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.

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!

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!)

Eventual consistency and microservices

Since at least the early 1990's our industry and academia have dabbled with eventual consistency. I've written and spoken a bit about eventual consistency around transactions and replication as it applies to scaling systems and also SOA over the years. As Eric wrote many years ago, some of it even made its way into standards. Recently the industry has been looking at how eventual consistency may be required within microservices. For instance, what about Eclipse MicroProfile and transactions (yes, a favourite of mine)? It's possible some of this may make its way into Eclipse EE4J. And now Matt Klein from Lyft has written a nice piece about eventual consistency and networks, which is also worth a read.

Just remember: right tool for right job; just as ACID transactions aren't right for evry use case, strong consistency isn't right for every use case, and hence neither is eventual consistency right for every use case. Think, understand, consider and apply.

A Java EE Interlude

I want to take a quick break from the other series for a moment to do something I've been remiss about for a while: addressing a recent report by Gartner on the state of Java EE. Before doing so I decided the other day to read the article my friend and colleague John Clingan made a few weeks ago and I realised that John had done a great job already. In fact so good I couldn't see myself adding much to it, but I'll try below. Note, there are other responses to this report and I haven't had a chance to read them but they might be just as good.

To start with, it's worth noting that I've known Anne for a number of years and we've had one or two disagreements during that time but also some agreements. Her announcements about the death of SOA seven years or so ago falls somewhere in between, for example. It's also important to realise, if you don't already, that I do believe everything has a natural cycle ("the circle of life") and nothing lasts forever; whether it's dinosaurs giving way to mammals (with some help from a meteor and/or the Deccan Traps), or CORBA shifting aside for J2EE, evolution is a fact of life. Therefore, whilst I disagree with Anne about the short-to-medium term future of Java EE, longer term it will pass into history. However, before doing so it will evolve and continue to influence the next generation of technologies, just as the dinosaurs became the birds and aspects of CORBA evolved into J2EE. For more details on my thinking on this topic over the years I leave it as an exercise to the reader to check this blog or my JBoss blog.

John covers my next point very well but it's worth stressing: I've mentioned on many occasions that my background is heavily scientific and I continue to try to employ objective scientific method to everything I do. So when I see blanket statements like "fade in relevance" or "lighter-weight approaches", whether it's in a Gartner report, a paper I'm reviewing as a PC member, or even something one of my team is writing, I immediately push back if there's no supporting evidence. And I read this report several times searching for it but kept coming up empty handed. It was one subjective statement after another, with no real attempt to justify them. That's disappointing because with my scientific hat on I love to see facts backing up theories, especially if those theories contradict my own. That's how we learn.

One other thing I did get from the report, and I'm prepared to admit this may be my own subjective reading, was that it seemed like a vague attempt to look into the future for middleware frameworks and stacks without really understanding what has brought us to where we are today. I've written about this many times before but weak assertions by the report that "modern applications" are somehow so different from those we've developed for the last 50 years that existing approaches such as Java EE are not useful really doesn't make any sense if you bother to think about it objectively. Distributed applications, services and components need to communicate with each other, which means some form of messaging (hopefully reliable, scalable and something which performs); there's really no such thing as a stateless application, so you'll need to save data somewhere (again, reliable, scalable and performant); hey, maybe you also want some consistency between applications or copies of data, so transactions of one form or another might be of help. And the list goes on.

Of course application requirements change over time (e.g., I recall doing research back in the 1980's where scale was measured in the 10's of machines), but new applications and architectures don't suddenly spring into being and throw away all previous requirements; it's evolution too though. I've presented my thoughts on this over the past couple of years at various conferences. In some ways you can consider Java EE a convenient packaging mechanism for these core services, which are typically deployed in a co-located (single process) manner. Yet if you look beyond the Java EE "veneer" you can still see the influence of enterprise distributed systems that predate it and also the similarities with where some next generation efforts are heading.

I suppose another key point which John also made well was that the report fails miserably to differentiate between Java EE as a standard and the various implementations. I'm not going to cover the entire spectrum of problems I have with this particular failure, but of course lightweight is one of them. Well over 5 years ago I wrote about the things we'd done years previously to make AS7 run on a plug computer or Android phone and we've kept up that level of innovation up throughout the intervening time. There's nothing in the Java EE standard which says you have to build a bloated, heavyweight application server and we, as well as other implementations, have proven that time and time again. It's disappointing that none of this is reflected in the report. I suppose it's one of those terms the authors hope that if they say it enough, people will attribute their own subjective opinions and assumptions to it.

Another one of those throw-away statements the report is good at is that "[...] at this point, Java developers eschew Java EE". I admit not every Java developer wants to use Java EE; not every Java developer wanted to use J2EE either. But you know what? Many Java developers do like Java EE and do want to use it. You only have to go to conferences like JavaOne, Devoxx or other popular Java events to find them in abundance. Or come and talk to some of our customers or those of IBM, Payara, Tomitribe or other members of the MicroProfile effort.

I could go on and on with this but the entry has already grown larger than I expected. John did a great job with his response and you should go read that for an objective analysis. Probably the only positive thing I could attribute to the original Gartner report is that its very existence probably proves that time travel is possible! It's a theory which fits the facts: a report which criticises something based on data which is largely a decade old means it was probably written a decade ago.