Ready for InfoQ 3.0? Try the new design and let us know what you think!

Is Gartner's Report of Java EE's Demise Greatly Exaggerated?

| by Victor Grazi Follow 23 Followers on Dec 21, 2016. Estimated reading time: 10 minutes |

Gartner has produced an analyst report called “Market Guide for Application Platforms”, citing Java EE’s “revenue decline” in reporting “a clear shift” downward in the application platform market. The report was quickly picked up by chief Java EE competitor Pivotal on their website

According to Gartner:

Digital business initiatives require new features and capabilities in application platforms, and Java EE has failed to keep pace.

Application leaders responsible for modernizing application infrastructure should develop a strategy to deal with the obsolescence of Java EE.

By 2019, fewer than 35% of all new business applications will be deployed in Java EE application servers.

The report is attributed to Gartner distinguished analyst Ann Thomas, who has been in research and publishing since 1988, and Aashish Gupta, a researcher since the early days of his career in 2011.  The report precludes the common use case where technologies complement each other in the deployment. 

Unsurprisingly, the report has proved controversial in some quarters.  Reza Rahman, former Oracle Java EE evangelist and now leading the Java EE Guardians, told InfoQ:

It is understandable that this is non-technical staff, and does not seem to admit the reality that if anything there is a trend away from the traditional three-tier model, and frameworks and Java EE frequently sit side by side in the application stack.

Author, technologist and consultant Kito Mann amplified that:

Java EE is not monolithic; it is a collection of standards and you can pick and choose which pieces you want to use. Even Pivotal's Spring Boot is built on some core Java EE specs, like Servlet, JPA, and Bean Validation.

According to Rahman, the data driving Gartner’s report contradicts contemporary independent industry findings:

This is basically a "data driven" report with no clear indication of the quality, source or quantity of data. 

Fortunately, we do have public data to counter this where we know a bit more about the source, quality and quantity of the data. There are a number of surveys we have curated on the Java EE Guardians site:

There's also a much less prominent but more recent survey here:, citing sources but not quantity of data.

Independently, ZeroTurnaround, maker of the popular JRebel and XRebel software, conducted their own annual industry survey, which corroborates the Java EE Guardian conclusion.

Rahman summarizes the results in a chart that demonstrates the growth of Java EE by version.

Java Community Process member, author, and lifelong enterprise technologist Josh Juneau told InfoQ:

I've skimmed through the report, paying particular attention to those areas that are declaring "the obsolescence of Java EE". The report is clearly geared towards management and development teams that are newer to the market; those who are not familiar with Java EE or all of the many options available for building and deploying enterprise applications. The report paints the picture of Java EE being out of date, although I would argue that much of the community and enterprise customer base would say that this is not the case.

Although in the recent months/years there has been a clear shift in the development strategies that are being taken for building enterprise applications, there is still a place in the market for standard Java EE applications...and there will be for many years to come. That said, Java EE does remains relevant in the market by continuing to release new standards that are geared towards the latest development trends. There was uncertainty in the air (and there still is) around the next release of Java EE since Oracle was very quiet throughout most of calendar year 2016. However, Oracle along with the community are moving Java EE forward in 2017 and continuing to bring new standards to the platform. If one takes a look at the JSR mailing lists, they will see that activity is beginning to ramp up on those specifications that are scheduled for release in Java EE 8.

The microservice and cloud hype is not something that can be ignored. However, those are two areas that may not be pertinent to every enterprise customer; there are many that will never deploy their applications to a cloud environment, and simply require the need to retain full control over their enterprise. For those customers, the current Java EE application server methodology is a great fit.

It is also possible to develop service-based applications using an application server strategy. The "fat JAR" deployment of microservices is not going to work for everyone...nor does it make sense in many cases. This is something that needs to be considered prior to the development of any enterprise application....choosing the best tool and strategy for the task at hand. Enterprise customers should not be choosing microservices or gearing for cloud simply because it is a hot trend, but the report contradicts that argument.

Lastly, Java EE is not meant to be a ground breaking revolutionary platform that brings new techniques and strategy to the market. It is meant to be a consistent and standard environment that is solid, proven, and dependable. Java EE is based on proven standards, and microservices are not yet at a point where they can be standardized; the development methodology is still evolving.

But Juneau expressed one caveat:

I feel that when Java EE 8 is released, it will pave the way for a more standard approach to building microservices and cloud deployments. If the currently projected timeline for release of Java EE 9 remains on track, then I believe Java EE is on target for providing a sound and standard environment for deploying microservices and cloud based applications, as well as continuing to be a great platform for those applications that have been built on the solid Java EE stack over the years. That said, the community and JCP expert groups need to remain vigilant and keep on top of Java EE to ensure that it remains on target. Many in the community had known that reports such as these would be crafted to show that Java EE is in decline, given that Oracle hasn't remained on target with the initial release schedule. This report plays on keywords and new does not pertain to enterprise customers that require a solid and standard approach.

Technical author and JavaOne rockstar Ryan Cuprak told InfoQ:

This report is very confusing - I am not sure the authors fully understand the technologies they are comparing/analyzing.

What this report is trying to do is attack Oracle/IBM via Java EE. Notice, the article doesn't discuss cost savings, success, types of projects that are appropriate, concerns about vendor lock-in, etc. 

Java EE is relevant and will continue to evolve. Most Java developers use Java EE everyday even if they aren't aware of it. If you are implementing a micro-service using JAX-RS you are using a component from Java EE. You can't say the platform is dying when it is being used everywhere. Just because you didn't purchase WebLogic for a small departmental application doesn't mean you aren't benefiting from Java EE and using a piece of it.

Reza Rahman added:

Microservices and cloud are clearly on the Java EE horizon; that was the key focus of Oracle’s JavaOne keynote content vis-a-vis the promised accelerated schedule for Java EE 8 and Java EE 9.

Java EE vendors are also doing their part both in products like WildFly Swarm, Payara Micro, etc., as well as joint initiatives like MicroProfile.

As to platform comparisons, honestly it's not that credible to argue Java on the server side will not continue to dominate in the near future just as it has for many years now. If that's the case, really the only two viable choices so far are Java EE and Spring. I've already given you the many resources we have that show Java EE remains the most widely used API set in server-side Java.

The likes of Pivotal have argued otherwise for years now, but those basic facts have remained unchanged for all those years. It's unlikely that's going to change any time soon. As to revenue, the money Pivotal gets from Spring is a pittance compared to what Oracle alone makes from Java EE related offerings. That's not even counting IBM, Red Hat and the rest of the Java EE vendors. It's even more so when counting revenue from the various smaller vendors that build upon one or more Java EE APIs such as the JMS providers out there. 

We remain strong, vibrant and growing as a Java EE and open standards focused community. We have been for many years now which is why we could get the commitments that we have gotten out of Oracle.​

InfoQ also spoke to Alex Theedom, technical author, speaker, and lifelong technologist:

Java EE’s reputation for heavyweight bloat that is slow to add support for emerging application architectures is outdated by years. It was shown by Adam Bien back in 2009 that WAR deployments can easily be only a few kilobytes. Then in 2013 Arun Gupta showed how Java EE applications are clearly much lighter than Spring. Java EE developments are highly productive and lightweight, often requiring only one dependency; this is not something that can be easily said of other frameworks.

Microservices and the cloud are on everyone’s agenda and Oracle has clearly given their commitment. The next release of Enterprise Java, namely Java EE 8, JSR366, includes features that support cloud infrastructure and microservices. In addition to Oracle’s support, many vendors and community leaders are playing a pivotal role in the advancement of Java EE via initiatives such as the microprofile, a collaboration of vendors, community leaders and user groups that are successfully working to push Java EE in the microservices space.

The Java EE community and companies such as Payara, Tomitribe, IBM and Redhat are right behind Java EE devoting time, effort and resources to ensuring that it advances forward in the direction the community wants, and it is being advanced. How many other ecosystems get such support and dedication from those who use it every day?

To claim that Java EE is obsolete, irrelevant and not suitable for cloud-native applications demonstrate a lack of knowledge about what is really happening in the Java EE community, because from my perspective it is alive and well and thriving.

Werner Keil, JCP Executive Committee member points to a trove of important JSRs that are actively brewing, including CDI, JSON-P and JAX-RS, three JSRs used by microprofile. These are positioning Java EE 8 for Microservices and Cloud for release by late 2017 as intended. For HTTP 2 support in Servlet 4, JSON-B is nearing completion, and the new JSR 375, Java Security API, recently passed its renewal ballot and should be in a position to standardize security mechanisms for Java EE that are now only available in a proprietary manner.

Rahman also suggested that the report could have been sponsored, a claim denied by Pivotal when we spoke to them.

Seperately Ian Andrews, Vice President of Products at Pivotal, told InfoQ that

There's a lot of industry chatter about the decline of Java EE, as well as the declining use of legacy app servers. But, the real story is the rise of cloud native architecture. Gartner talks to global CEO's and CIO's every day, and they've astutely recognized this important shift towards cloud native, and advised their clients to pursue a modernization strategy for their existing application portfolio. Gartner's independent research on the rise of cloud native architecture echoes similar findings from other top tier research firms such as Forrester and Redmonk.

Over the past three years at Pivotal, we've witnessed a meteoric rise in the popularity of Spring Boot and Spring Cloud as the building blocks for cloud native applications. This is clearly evidenced by Spring Boot's 10.2 million monthly downloads in November 2016, a 425% increase year-over-year. We look forward to helping many more organizations use our Spring technology to adopt a cloud native architecture as they modernize their critical applications.

This post was updated 22nd December 2016 to include the statement from Ian Andrews.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

More Responses to this Nonsense by Reza Rahman

Amongst many others so far, the following are two more notable responses in the community to this highly dubious piece of work from Gartner. You owe it to yourself to read them - really.

This one is from inside the heart of the Red Hat camp. Aside from the rightfully humorous few-second video reference in the "executive summary" section, here is a key remark - "issue with the Gartner report is that it seems to completely ignore the advancements that Java EE vendors have made beyond the traditional Java EE APIs and runtimes, nor mention the MicroProfile efforts to develop microservices APIs for traditional Java EE developers".

This very well-received one from Pavel Pscheidl pulls even less punches. The title really says it all - "A quick reaction to hate on Java EE present in Gartner report".

Pavel will be doing a longer, more "analytical" (get it ;-)) follow-up piece as will I. I probably have the sad distinction of being one of the people that has dealt with Gartner's salespeople and "analysts" enough to shed light on why this work smells more than a little *ahem* ripe. I'll also say more about Pivotal's long and short term financial state that's a very leaky secret. Let's just say it's a bit of a far cry from the image of invincibility they try a bit too hard to project (that too of course is a very common sham in Silicon Valley exposed in very courageous recent works like Disrupted).

Re: More Responses to this Nonsense by John Clingan

Thanks to Reza, Pavel, Alex, Josh, and the rest of the Java EE community for offering counter-points to the report.

The report title could have been better. by Sai Matam

Java EE does not mean EJB. Yes, EJBs are on the decline. The report title could have been more specific and correct!

Java EE is an industrial grade tried and tested platform. Over the years it has absorbed many different technology trends and progressed over time. Java EE consists of many APIs and not just EJBs.

Java has continued to evolve, keeping pace with the new developments in technology. Microservices, which has been all the rage now-a-days, needs smaller and more modular jar/war files and Java 9 will make it happen.

Cloud is yet another trend - and Java is right there in the cloud. Java 8 has Streams and Lambdas which are immensely useful.

JavaScript, NodeJS, TypeScript & AngularJS are hot new things and show momentum in growth. We have to acknowledge that. But this does not mean that the NodeJS is the most favored platform!

Java is a mature technology with many critical deployments. At time, it feels like, Java is slow to catch-up. But Java has to evolve slowly with great responsibility.


Sai Matam


Re: The report title could have been better. by Victor Grazi

Sai is making a very important point. Java EE is indispensable in many if not most enterprises. Enterprises by default use app servers, JSPs, etc, even with single page and Spring MVC applications, and that is not going away soon. Just because one feature or another is no longer used, reports of our death are indeed greatly exaggerated

Re: More Responses to this Nonsense by Reza Rahman

For completeness and equal treatment, here is now the response from the Payara camp by Ondrej Mihalyi. A key phrase: "Gartner analysts irresponsibly provide obsolete information about the Java EE platform".

Java EE is used everywhere by Pavel Pscheidl

I'd say Spring is the most outdated technology out there, with great merketing. People definitely need different perspective on this than Pivotal's marketing can offer. Java EE is a symbol of collaboration towards common goal. In Java EE world, many extremely capable people bring technologies together. A noble goal I'd say.

Spring plays the role of angry kid, stealing everything they find useful, rebranding it like Horst Fuchs does in Teleshopping. They act more like a parasite that is stupid enough to try to kill it's host (not only by paying to Gartner). When Java EE dies, Spring dies. When it comes to revenues, the only one who is dying is Pivotal itself. From all the vendors mentioned in the report, they're the ones who do not generate a single penny of revenue.

"You have to understand, most of these people are not ready to be unplugged. And many of them are so hopelessly dependent on Spring that they would fight to protect it."

Don't get caught in Matrix. Give Java EE a try. You will see it's easy, simple and complete in features :) Enter a world of freedom, where you don't depend on one reseller of old Java EE.

Why is this controversial? by William Smith

This seems like such a statement of the bleeding obvious that I’m honestly surprised by the apparent upset Gartner’s report has caused. Java EE is a poor choice for a cloud-based deployment as it stands and really is legacy technology at this point. Oracle belatedly woke up to this and they have been scrambling to try and re-tool Java EE but that looks to be years away. In the mean time since Pivotol have been been able to work with companies like Ali Baba and Netlfix they’ve got a solid Microservice stack that you can build against today.

None of this means that Java EE as a whole is going away; bits of it are still useful. But the central idea of a centralized app server to act as a distributed transaction manager is increasingly irrelevant because it scales poorly beyond a certain point. It had a good run, and will continue to be used in many organizations, but it is clearly in decline at this point.

Re: More Responses to this Nonsense by Stuart Charlton

You know you've lost the battle when all you can do is FUD the clearly winning alternative in Spring and Pivotal by throwing shade on its financial viability.

First, let's be clear: Java folks need all the allies they can get against the real long term fight, which is the perceived obsolescence of Java. Node.js, Golang, etc. are all on enterprise radars. They don't have a major vendor presence yet is why they're lagging (Google IMO doesn't quite get how to be Sun circa 2001).

But, secondly: the Gartner report reflects a large slice of reality. Ignore it at your peril. I see it every day among VPs and CIOs in financial institutions and telecoms. Rebuilds of major apps from he mid-2000's are underway towards cloud native patterns, and Java EE isn't going to be the only (or even primary) choice.

The first stage is denial by Stuart Charlton

"The "fat JAR" deployment of microservices is not going to work for everyone...nor does it make sense in many cases."

What are those cases? Seriously.

As both a developer who has been on production support for Weblogic, Websphere, and Tomcat apps, I have no idea why I would ever want to deploy to an app server again rather than embed it in my app as part of my build process.

It's dead simple, CI/CD built and tested from the ground up, no snowflake servers, deployed at scale, fast launch times, well-defined configuration through environment variables or Spring property files, etc.

If you're claiming that these ideas are not for everyone, I think you don't understand how fast the best teams are able to move - safely! - when iterating on their software.

Re: More Responses to this Nonsense by Reza Rahman

If you really think Pivotal's profitability is not an issue, I would suggest asking them to publish what their profits and losses in so many years has been. If Gartner wants to talk about the revenue stream from Java EE, I'd say the revenue stream from Spring is very fair game too.

As to the rest of the pro-Spring comments on this thread, I think the Java EE community and vendors have already addressed them in the article and linked resources (and of course for years elsewhere and I am sure many more times in the future given Pivotal's proclivity for negative marketing tactics against Java EE).

BTW, I trust Forrester and Redmonk just about as much as I trust Gartner. They all have the same dubious business model of taking money from vendors to make so called "independent" recommendations.

Re: More Responses to this Nonsense by Reza Rahman

No need to thank us, we are in this together for the long-term health of the Java ecosystem. I think most ordinary developers find the same old vendor proprietary divisive agendas from the same old players rather stale and tiresome. Unlike years past the grassroots community now has the capability of having their voice heard, just as they have done with Oracle. Please keep working to forward community driven open standards.

Re: More Responses to this Nonsense by Adib Saikali

My main issue with JEE is that once there is a standard spec all innovation stops while the standards process works it's way through the opaque JCP process where Oracle or some other entity can put a pause on progress. Lets look at some examples.

  • JPA 2.1 took about 2 years to finalize a minor release of the JPA spec. The spec from JPA 2.1 was released about 3.5 years ago in May 2013. A JEE developer is stuck using 2013. technology to compete with 2016 frameworks and advancements. So if I am using JPA today I would have to rely on lots of features from the JPA implementation such as Hibernate for example JSON support, Java 8 Date Time .... etc that my code would effectively not be portable between JPA implementations, therefore the whole idea of using JEE because its standard adds no value in fact it subtracts value

  • JMS 1.1 to 2.0 was an epic 11 year wait between spec updates. Again how is a JEE developer supposed to stay competitive and productive when key enterprise spec they use does not evolve quickly

  • Bean Validation spec took about 3.25 years to bake version 1.0 and then it took another 3.5 years to get Bean Validation 1.1 spec out. Again a JEE developer has to wait years between releases of the spec then a few more years before it gets officially GA in some major JEE server so sticking strictly to JEE API's and specs means being at a huge competitive disadvantage relative to those who don't use the official specs or rely on extensions of the official specs

  • Servlet 2.5 to 3.0 spec took 4.25 years to bake 3.0 to 3.1 spec to 3.5 years to bake. So as JEE developer sticking strictly to specs I can't do HTTP/2 today ... etc. Again as a JEE developer I am at competitive disadvantage to non JEE developer

JPA, Bean Validation, Servlets, JMS, are the more popular of the JEE API's and they all feature enhancements that if applied to the specifications would enhance developer productivity and a JEE developer waiting for these enhancements will have fallen further behind non JEE developers.

Still missing from JEE is any kind of standard JSON data binding specification, any kind of cloud support, any kind of real testing support ... etc. And by the time these all get these baked into JEE they will be obsolete because the world would have moved on.

At Java One 2013 I attended the JCP community meeting and asked about the pace of progress why there was no JSON data binding spec in JEE 7 the JCP executive committee panel's response was to argue that the JCP is not in the business of innovation but rather in standardization of things after the fact. To me this means that JEE is never going to help me solve the problems that I have today rather it will solve the problems I had 5 years ago. And after JEE standardize some spec I am expected to learn this new spec and throw away / rewrite perfectly working code to get the benefits of being standard JEE.

Using JEE because it's the standard solves no business problems, does not make developers more productive in fact it makes developers less productive. For JEE to be relevant in 2017 and beyond JEE needs a complete re-think and reboot both at a technical level and the standardization process level.

For new applications built today that want to be Cloud Native JEE has nothing to offer while Spring has a lot to offer in Spring Boot and Spring Cloud. JEE is legacy plain and simple and it would be huge mistake for a new application to be only built within what an application server offers there is simply too innovation happening outside of JEE to stick with JEE.

The fact there are conversations about MicroProfile and efforts to make JEE relevant does noting for anyone building an application today so why should they wait years until JEE standardizes things??? We get paid to solve today's problems not yesterday's

Re: Why is this controversial? by Guillaume Bilodeau


Leave the bubble by Nabil Belakbir

I am not pro Gartner and don't believe so much in there quadrant specially when talking about tech .

But let make it clear , Java is not Java EE .

And here we are talking about Java EE :

Here is some facts :
Application Server is now Anti-Pattern .
Digitalisation are becoming so distrupting and fast that we need reactive application , Microservice Architecture , Complex integration ...

Fact#1 : JCP process is bureaucratic .
Fact#2 : JCP community is closed (Bubble) and not open mined .

Evidence :
8 years
3 years
2 years
for minors changes in some specs

Java 8 was great , but let make it clear again it was 10 years behind what you can do in C#.

So Lambda and Stream is not a gift that Oracle Give to the community , it was there last chance to survive and don't break the wonderful Java .

Question :
Have you ever play with Websphere (liberty profile you will say !!!!)?
Have you ever play with Weblogic ?
Honestly , do you will invest 1$ in 2017 in buying this ?

It was an easy money in the past due to great sales guys and the No-Mature alternatives dilemma , but things are changing , and alternatives exist .

One more point (Kindly):
You are talking about Gartner is not neutral , Are you (JCP guys) neural ?

To conclude :
Java is a great language (Will be better if it not was in the hand of Oracle) and will survive a long time ... For the rest , prepare your grave.

Time is for Microservice , Polyglot programmer , Reactive application , Easy and cheap deployment .

Kindly Nabil
Java lover .

Re: More Responses to this Nonsense by Reza Rahman

Frankly I'd say you've been exclusively drinking the Pivotal anti-Java EE tropes for a bit too long, to your own detriment. That said, since you bothered to post on a holiday, I'll return the favor (BTW, some of this we'll summarize in an anti-FUD section of the Java EE Guardians site early next year).

* Arjan Tijms has a really nice factual write-up on Java EE release cycles. The average Java EE release cycle is about 2.5 years (of course there are extreme examples like JMS, but that's the baseline cadence for most Java EE APIs). That's faster than any other open standard out there, especially compared with JSON, CSS, JavaScipt, HTML, HTTP or SQL. That said pretty much everyone in the JCP wants Java EE release cycles accelerated. That's why Oracle has promised to deliver Java EE 9 just one year after Java EE 8. That would be the fastest release turnaround Java SE or Java EE has ever had. It is totally unprecedented for an open standard.

* As you have suggested yourself, Java EE vendors do indeed actively innovate between Java EE releases. Examples of such innovation are almost countless such as Seam, Hibernate, Jersey, DeltaSpike, Arquillian, Forge, WildFly Swarm and so on. Utilizing such innovations as they occur by no means takes anything away from the value of open standards. Gavin King articulated this point many years ago now. Even if you do take advantage of vendor extensions, 70-80% of your code still remains vendor neutral. That's not what you get with a 100% vendor specific technology like Spring.

* The blighted picture you are trying to paint of Java EE is very incorrect. The reality is that both Java EE 6 and Java EE 7 have been feature complete for the vast majority of applications. The best way to see this is by reading the many Java EE adoption stories that Java EE Guardians regularly curate. Indeed, most things in the Java EE 8 and Java EE 9 scope can actually be met in Java EE 7 applications right now by adopting vendor-specific extensions. In the so called "cloud native" or microservices space all of the MicroProfile compatible products available in production right now offer the Java EE programming model in whatever form-factor anyone needs. I'd say WildFly Swarm basically offers exactly what Spring Boot offers, just with standards based APIs instead. The situation is the same in terms of cloud platforms. There is BlueMix, OpenShift, Oracle Cloud and many others that offer native support for Java EE as opposed to just the Spring Cloud in the Spring world.

Re: Leave the bubble by Reza Rahman

I'd say this is more of the same anti-Java EE trope that is deliberately perpetuated by the likes of Pivotal. I'd suggest the following food for thought:

* People like me have been contributing to the JCP as independents for years now. Nothing in life is perfect and neither is the JCP. Nonetheless, the JCP is the only place that I know of that requires absolute transparency and accountability. That means non-vendors like me have a strong voice in the JCP, as does anyone else. That's far superior to any open source project I have even seen where there are no guarantees of transparency and basically you are at the total mercy of whomever the project committer is. In case of Spring this is even worse as near 100% of all Spring committers are employees of a single company - Pivotal. Indeed in 2016 what we have shown is not even Oracle can control Java EE alone and it must answer to the community (yes, that's us).

* If you are so blindly enamored by fat-jars as to not see it's obvious down-sides , I suggested reading this excellent write-up by Sebastian. The short version? Ultra thin Java EE war files deployed to a server are a not faster and more agile than a bloated fat jar. That fact remains the same with or without CD/CD, Docker and the cloud. In fact, some of us have been using Java EE applications for a while using CD/CD, Docker and the cloud. I would say we are more productive than slow, bloated fat jars - WildFly Swarm or not.

* No one said you need to pay a cent for a server. There are plenty of FOSS ones like JBoss, WildFly, GlassFish, Payara and TomEE. The reason wise companies pay is because commercial support comes with a lot that Tomcat, Spring and Spring Boot just doesn't come with such as infrastructure integration, management, enterprise monitoring, debugging, diagnosis, 24/7 support and patches. That's the core reason the Java EE business model works and why Pivotal is so deeply a loss-making company with an uncertain future. They just don't get it. They also won't get it with Spring Boot because most of their users will simply use it on Amazon and never pay Pivotal a cent.

* I am not sure who precisely you think "JCP guys" are. Most of us are independent people that have day jobs with little or nothing to do with Java EE or Spring. The reason we do what we do is we refuse to be controlled by vendors like Pivotal and Gartner. In fact, we even distrust Oracle, IBM and Red Hat. Count your lucky stars that we exist. We are the closest thing to what this industry has to truly neutral people. Do yourself a favor and learn to appreciate what we contribute on your behalf on our own time...

Re: More Responses to this Nonsense by Adib Saikali

Quoting Arjan Tijms blog post you referenced I see that he writes "As can be seen the time between releases has been steadily increasing, but seemed to have been stabilized to approximately three and a half years." not the 2.5 years you are claiming in your response.

In the same article he writes

"As we can see here, excluding GlassFish and the tech preview of JEUS, it took 1 year and 6 months for the first production ready (according to the vendor!) Java EE 6 full profile server to appear on the market, while most other servers appeared after around two and half years."

So for JEE6 the trend was 2.5 years after the publication of the spec for a GA app server implement JEE 6 to appear so in total 3.5 + 2.5 years for GA implementation means a 6 year wait for GA between releases.

Arjan Tjim's blog post also includes a table showing JEE 7 Full Profile support for the major JEE app server vendors I am summarizing the data below and adding WebSphere 9.0 which is not in Tim's table.

  • Liberty released 25 Jun 2015 758 days since spec release (2 years, 1 month)

  • WebLogic 12.2.1 released 25 October 2015 880 days since spec release (2 years, 5 months)

  • JBoss EAP 7.0.0 released 10 May, 2016 1078 days since spec release (2 years, 11 months)

  • WebSphere 9 was released on Jun 24 2016 according to wikipedia with JEE 7 support 1125 days since spec release (3 years, 1 month)

    • Averaging out the major JEE7 GA dates we have an average 960 days between the release of the JEE7 spec and the appearance of supported GA versions for all major application servers that is 2.6 years average for a GA release. So the trend for JEE7 was 1 month worse than JEE6 so lets be generous can say that the average is same.

      So based on the data from Arjan Tijms blog you referenced the wait time between JEE versions and GA versions of app servers is about 6 years Arjan was trying to point out that individual specs might take less time to finalize but that does not make a difference for an enterprise developer who has to wait till their operations team buys and upgrade their current app server which typically takes at least takes 1 to 2+ years so a JEE developer is looking at a 6 to 8 year wait before they can use the latest feature of JEE.

      In your response wrote:

      As you have suggested yourself, Java EE vendors do indeed actively innovate between Java EE releases. Examples of such innovation are almost countless such as Seam, Hibernate, Jersey, DeltaSpike, Arquillian, Forge, WildFly Swarm and so on. Utilizing such innovations as they occur by no means takes anything away from the value of open standards. Gavin King articulated this point many years ago now. Even if you do take advantage of vendor extensions, 70-80% of your code still remains vendor neutral. That's not what you get with a 100% vendor specific technology like Spring.

      How is Spring ecosystem any different than any of the extensions built by the JEE vendors to innovate, Spring has always built on top of JEE standards and made the standards easier to develop with, easier to test with ... etc. And where there are no standards has provided solutions for example Spring Data, Spring Cloud, ... etc.

      There is a pretty good argument to be made that JEE has greatly benefited from a constant stream of innovations from the Spring ecosystem that has continued to increase the productivity of developers using slow moving JEE application servers.

      Reza why do you hate spring so much and not give it credit for being a great source of innovation for the JEE ecosystem?

Re: Leave the bubble by Adib Saikali

I am not sure who precisely you think "JCP guys" are. Most of us are independent people that have day jobs with little or nothing to do with Java EE or Spring. The reason we do what we do is we refuse to be controlled by vendors like Pivotal and Gartner. In fact, we even distrust Oracle, IBM and Red Hat. Count your lucky stars that we exist. We are the closest thing to what this industry has to truly neutral people. Do yourself a favor and learn to appreciate what we contribute on your behalf on our own time...

The JEE Guardians have no power to make Oracle do anything the only thing it can do is fork the JEE specs if that is legally possible. The existence of the JEE Guardians is a great example of how broken the JCP process is at innovation and moving JEE forward.

A JEE developer wanting to make any improvements to JEE needs to figure out who is leading a JSR when it is being formed, get invited to the Expert Group ... etc and contribute only when Oracle decides that the JSR should move forward and only in way that Oracle see's fit.

A Spring Developer can just go on and send a pull request for any feature they would like to add to any of the spring projects, or open a feature request or bug report.

If a Spring Developers wants to talk directly to the spring core committers that is super easy just head over to any of the public channels the developers hangout in or head over to and get their names and reach out to them on twitter or attend any of the many user group or conference talks they give to speak with them directly.

Roadmaps for spring projects are open just head to the bug tracker for each project and you will see what features are coming when.

Got a question on Spring head over to and you will get answered in a few minuets and a lot of the time the Spring core developers actually answer the questions.

The spring community is open and easily accessible as a user of spring it is easy to see where the projects are heading when new releases are coming making it super easy for any Spring Developer to plan their own projects based on the current and future state of Spring. This is something that can't be done with JEE.

Reza why do you hate Pivotal so much?

Re: More Responses to this Nonsense by Pavel Pscheidl

Your post is the perfect example of people doing uninformed decisions, spreading the lack of knowledge to others.

Java EE, for a quite long time, is an extensible platform by design. Everyone is free and welcomed to extend it. Java EE's goal is not to innovate rapidly at all cost, but provide a well working set of polished features by standardizing what is worthy.

Java EE's approach is much more mature. Before a new set of features that were voted by the community to be worthy of standardizing, additional features can be plugged in. This is mainly thanks to CDI portable extensions. Such extensions can be added in by simply putting the dependency JAR on the classpath. There is no configuration hell, those extensions are truly portable and act like small black boxes with additional functionality.

This way, independent projects can be plugged into existing Java EE, bringing bleeding-edge functionality without any rush to bake unproven technology into Java EE. I wonder if Pivotal wish they designed their Dependency Injection core better, because now it is obsolete, baked in deeply everywhere.

In fact, it's the Java EE that innovated in critical areas and moved on. Pivotal are not exactly kings of innovation. Spring, as a set of oldschool servlets is an archaic piece of technology. By using it, once forces himself/herself into downgrading the core functionality to a 10 year old configuration-heavy badly designed bullshit.

In Java EE, there are many extensions now. Yet the situation is not perfect. Crucial information is that, by far, those extensions provide everything that Spring provides, but often more polished and with advatantages of Java EE 7 core functionalities. For example, a set of extensions called the Apache Deltaspike project is the new Spring of Java EE world. They provide fucntionality of Spring Data, Configuration...look on your own ! Only it's more polished and works out of the box. Funny thing is, even Spring Data is now a Java EE extension. So if needed, it can be used in Java EE. However, it requires the Spring's core as a transitive dependency.

Extensions are the future. Java EE does one mistake - not promoting itself. Pivotal on their website provides Teleshopping-like descriptions with some examples. And it also serves as one intuitive place for developer to go for functionality. Java EE has to work on this.

Building your application on top of few proprietary servlets provided by Pivotal is, for a long time, the worst thing you can do. I believe there are two reasons Spring still uses this approach. First reason is simple - their core libraries are baked in so badly it makes their code legacy and rewriting it would be a huge problem. The fact they still do not support JSR-299 really shows Spring has technological problems. Second reason is, frankly, that Spring would be disposable at any time. It could be easily replaced by some other, better extension. Extending Java EE is easy. There are always extensions to solve things for you. With Spring, the situation is different. If it's not there, you have to do it on your own. And there is one hell of configuration and reading stacktraces waiting for you.

Want Spring Data ? Deltaspike. Configuration ? Deltaspike. Metrics ? Metrics-cdi ! MVC ? vRaptor !

Java EE has everything Spring has, but it's not the other way around. Configurable containers with container-managed transactions, thread pools, easy administration for the customer, metrics, load balancing, session failover, bulk deployments ... where can I get this with Spring ? And yes, if you want to use containers, Java EE has this too. It provides much more choices than just Spring Boot. Which ones ? Have a look here:

Let's improve ourselves by Fanime Fartoon

Come on guys, we're team Java, there's no need to keep saying which framework or Spec is better. We should all work together to improve the ecosystem. I mean there are good stuff on Spring and Java ee as well. Or else we'll both loose the war =/

Remember this comic

So let's work together ok?

Re: Leave the bubble by Ondrej Mihalyi

Reza why do you hate Pivotal so much?

You are right, why would anyone hate Pivotal ;-) I don't see any reason for that. They are just like any other company.

I would rather ask why do they and many others hate JavaEE and JCP? They consistently attack the unification effort of many companies and individuals just to support their own interests, even though they can live by it and just not care. JavaEE used to be the core of Spring, even when Spring developed many competing components. Many Spring apps are still running on Java EE servers in production, there is a reason to that.

I don't understand why would anyone ask whether Spring is better than Java EE. It just depends. Of course, in the cloud, the heavy application servers like WebLogic and WebSphere are not convenient. But that's true also about Spring v3 with all the XML configuration and bloated dependencies. I thought that many app servers are bloated, until I was working on a Spring based project which took more than 2 minutes to start on plain Jetty.

Spring has progressed since those days, as well as Java EE, which is nowadays not only about big servers with multiple deployed apps. Java EE implementations can be embedded, are lightweight enough to start a separate instance per the application.

Yes, it's true that not all of this is standardized in the JavaEE specs.
But if you want to compare Spring with JavaEE, you have to compare it with the opensource Java EE servers, runtimes, and the ecosystem, because nothing like JavaEE and the JCP exists in the Spring world. How many competing Spring implementations you can choose from? What would you do if Pivotal stop supporting the project as they did with the Grails framework? It's complete nonsense to compare plain opensource projects, mostly backed by a single company or a few individuals, with the enormous standardization effort within the JavaEE and the JCP.

Re: More Responses to this Nonsense by Reza Rahman

* Frankly you are deliberately twisting facts and emphasizing the worst cases. Yes, the Java EE release schedule has slipped, especially for Java EE 7 (largely due to the corporate transition from Oracle to Sun) and Java EE 8 (due to Oracle's miscalculations that they have now been forced to correct). Even given that, the long term average is better than those two releases because Sun did a much better job at staying on schedule - particularly in the early days. Oracle has now promised to do the same or better.

* What Arjan shows is that implementations have their own cadence, which is about 2 years from Java EE release dates on average. What this means is that if you stick to a given application server implementation, the release cadence is still about 2-3 years. There are also great variances in speed for each implementation. One reason I tend to go with GlassFish/Payara and WildFly/JBoss is because their implementations are a lot faster.

* The big obvious difference between Java EE and Spring is that Spring is a proprietary technology with just one implementation, even if it does utilize Java EE heavily. I've already said what the many answers to the Spring Cloud in a Java EE ecosystem are. The situation is very similar with Spring Data, with DeltaSpike Data and Hibernate OGM being just a couple of answers amongst many others.

* Innovation in Java comes from many sources including Java EE, not just Spring. There are many cases where Spring either adopts innovations from Java EE or directly utilizes a Java EE API. That's what healthy ecosystems do.

* The only source of "hate" here that I see is people like you. About half of my projects are Spring based and I never have a problem outlining what Spring's strengths are and recommending it to the right client and project. I certainly never needlessly criticize Spring unless people like you make it necessary to defend Java EE. What I do have a problem with is people like you inside and outside Pivotal that spew negativity against what you have clearly decided is unwanted competition.

Re: Leave the bubble by Reza Rahman

Firstly, I think it is very important to disclose that you are in fact a Pivotal employee and your current title is "Advisory Platform Architect at Pivotal".

People should be aware that you are in fact paid to advocate whatever the Spring and Pivotal standpoint is.

* What the Java EE Guardians and pretty much the rest of the JCP has done is to force a change in decision making from the current Java EE steward Oracle. That is precisely how the JCP is supposed to work and why no one company can control the JCP. That kind of formal collaboration and governance mechanism simply does not exist in open source and certainly not for Spring. As to "forking" Java EE, that has never been anyone's intent and hopefully never will be. However, what efforts like MicroProfile tell Oracle is that a parallel formal open standard in enterprise Java is indeed possible if it ever stops listening again. I think it is pretty clear exactly how remarkable what we have accomplished together is. By comparison, Spring's governance model is very closed even by open source standards. The least Spring can do is have an external governance body with people that have competing implementations of Spring helping make decisions. Instead all decision making is basically done by Pivotal employees like you.

* Pretty much everything you said and more applies to Java EE and more. You can collaborate directly with spec leads/other EG members, contribute to implementations via open source, provide feedback, enter issues and ask questions in forums (StackOverFlow and elsewhere). As to GitHub in particular, many specifications have moved there already and that is where the rest of the projects are headed since is being shutdown in the next few months. As I've already mentioned, in addition what the JCP has is well defined governance rules requiring transparency and accountability. Those are the exact rules used to get Oracle to change it's actions on Java EE 8 and Java EE 9.

* Stop trying to silence criticism of your employer by using bully tactics and misrepresentation. I have no reason to "hate" Pivotal. What I hate is negative marketing tactics to try to undermine competition that Pivotal employees like you engage in. Whenever I see that, I call it out as do others because it is blatantly unethical.

Re: Let's improve ourselves by Reza Rahman

I agree with you wholeheartedly and have tried many times to get Pivotal to improve it's attitude to Java EE and open standards generally. Frankly, their attitude has remained just as toxic as always. They are bent on their proprietary views of the world. As we see here they don't hesitate to attack and try to undermine grassroots community efforts either when they believe they have something to gain or lose.

Re: Leave the bubble by Nabil Belakbir

You are right to point that there is some people from Pivotal that try to debate on this .

I think this is minimum of honestly required of this debat .

From my part i am not related to Pivotal and if you read my first comment i don't mention in any case Pivotal and BTW there is not only Pivotal in the space .

And you are absolutely right to say that there is some marketing agenda , witch normal and legitimate because it's all about business .

lightbend stack , node.js echosystem and others approach is also in the balance .

I want to make it clear that i am not defending Pivotal , because they have there agenda and money to this there self .

My point is the fact that Gartner analysis and many markets shift and signs (I see it my daily job CEO , CTO , VPs ....) are big alarms .

It's a survival time and you need to act with courage in these time .

What make a lot of harm to the JEE is that they are still close with some editors , that have bizzare agenda , and not honest sales practices .

You need to be clear on that and say it , if you do that community can of course follow you because Java is really great and what Sun built was an extraordinary gift to software lover .

Peace .

Re: Leave the bubble by Reza Rahman

Firstly I think the overly aggressive negative marketing tactics that Pivotal routinely engages in is very far from "normal business practices" and is in fact deeply unethical. Most responsible company policies explicitly disallow anything that looks like negative marketing against competitors. Pivotal's deliberately divisive anti-competitive tactics are harmful to the broader ecosystem and needs to be called out loud and clear.

If you have concerns other than what you have stated (and I have already responded to), I am happy to hear it. Please be specific so we can follow up on it either in the JCP or with individual vendors. Like I said, nothing in life is perfect but there are many of us trying to improve whatever we can in the JCP, Java and Java EE.

As to the supposed "shifts" you've mentioned a few times now, I suggest you read this recent very popular article on Hype-Driven Development. Part of courage is standing up to hype and call it out for what it is instead of prematurely endorsing it by standardizing it. A much more sound and principled approach is letting vendors innovate on products/initiatives like WildFly Swarm/MicroProfile, etc and standardize when the dust actually settles more definitively. In my view, I think that's about 1-2 years from now - which is just about the right time for Java EE 9. That's the point Josh judiciously but succinctly made in the original article and one that I plan to elaborate on in my own blog entries.

Re: More Responses to this Nonsense by Stuart Charlton

Re: hate. Let me see, you've half accused Gartner of being on the take, FUDed pivotal on multiple occasions on this thread, making stuff up about their financial viability, and your compatriot Pavel keeps saying Spring is based on outdated technology that is the worst possible choice someone can use - a laughably false claim.

You may defend Spring for its strengths and I thank you for that, but that has not been the focus of this thread. Heck I defend JEE for its strengths (JAX-RS) all the time too, though Spring REST is also great. .

Why wouldn't you expect some Pivotal folks who are in the field working with actual customers moving off JEE like Gartner says (is. A reflection of reality, not just Pivotal marketing, but actually what people are doing) to show up and question this line of debate?

You've also said this pivotal doesn't like competition and trashes JEE as a result. No, this is the face of actual competition - and with Pivotal making a compelling argument that is resonating. Pivotal isn't competing with JEE per se, it is competing with Oracle, IBM, and Red Hat: not exactly small startups. What do they have in common? The painfully slow evolving JEE!

The issue is actually about whether we NEED a standard anymore given the pace of change with cloud native apps and services. Things are moving far too fast for a JCP-like process.

You are right that Spring is propriatary technology, but it's open source proprietary technology, like Linux, or Node.js, or Python, or Golang; or Swift. Did Linux fail when it didn't follow the Open Group's UNIX standard?

JEE and the JCP did the industry a favor as a stabilizing force in the early 2000s, but that's because the features of an app server were relatively stable - they were defined in the 90s by the amalagamation of TP monitors and web servers. But standardization efforts don't make sense when you don't even know what you're standardizing. The notion of an app server as the unit of standardization has become fairly irrelevant, companies are now concerned more about the end to end platform and CI/CD ecosystem, not just a sliver ... so it's more about looking at RHOS+Jenkins+Wildfly+Fabric8 or Bluemix+Jazz+NodeJS+Watson or CF+Concourse+Spring Cloud+Geode . But these are moving targets that are much broader than the traditional JCP mandate.

The point is - I have no qualms with you as an independent JCP member trying to defend your creation that has been mismanaged by the dominant vendor, the Guardians attempt is similar to the WHATWG was trying to do with HTML, the issue I think you'll find is that the scope and business goal of a platform has broadened beyond the scope of what's inside the JVM. Gartner is trying to point that out.

By all means, debate the points with Gartner about what JEE can do, and make JEE better, but you are not helping your case by casting conspiracy theories into Gartner payola or Pivotal marketing prowess (which in reality is a fraction of the spend of the industry dinosaurs, so perhaps it's just a resonant message?), or anti-Spring commentary from JEE promoters.

Re: More Responses to this Nonsense by Reza Rahman

Firstly, it is important to disclose that you are in fact a Pivotal employee and your current title is "Platform Architecture at Pivotal".

People should be aware that you are paid to advocate your employer sanctioned views.

Whether you like it or not all of what I've noted is reality that isn't highlighted enough.

The types of terrible conflicts of interest that Gartner has was made illegal for financial analysts after the 2008 financial meltdown. The only reason Gartner can still do it is because the damage they can cause is far less than what financial analysts can do. The Gartner report reads like a blatantly unbalanced pitch for Pivotal and should be called out as suspect for that reason alone.

As to Pivotal's profitability, why do you tout a small number of key customers/point revenues but not overall profits/losses? With regards to Pivotal and it's employees' use of deliberate negative marketing tactics, I think that's already been vividly demonstrated here. At every opportunity you get, you try your best to try to undermine who you believe the competition is - even if it means attacking the community.

As to your statement on velocity of change, the reality is that our industry has always been fast moving and it has always been possible to achieve collaborative consensus, even in the very turbulent 90s. If anything, the industry has matured since then.

Re: More Responses to this Nonsense by Pavel Pscheidl

Things are not moving fast. The hype is moving fast. In fact and in reality, things move much slower than one would think. There are more and more small companies trying to enter the market. And when they fail, they actually create a hypothetical new market and make you believe you want their product.

Good ideas are widely used after longer time, definitely not in months. In the meantime, those ideas are polished and change their shape "quite a lot". And when they survive, they're standardized.

It still does not mean that you can't use bleeding-edge technology alongside the standards. My previous post clearly stated this. And this is how Java works. I also pointed out that Spring tries to extend Java EE, which is always welcome. But the way they do it today is stupid. Making Spring modules Java EE extensions would be the way to go, but there are already the same extensions on the market, only better. And it would make Spring more vulnerable.

Spring guys act very stupid. They have some product. People kind-of use it, but far less people want to pay for it. At least I haven't seen a tcServer in production, yet every bank has some full-blown application server. So in the meantime, they parasite on Java EE, constantly attacking it to promote themselves. But they would love to see Java EE dead just to take it's place on the market, making customers dependent on their technologies, which they don't have yet. It's one company constantly bashing one mature idea of many companies collaborating together towards common goal. One evil company who has to be out there to challenge this very idea. Yet it is doomed to fail. In fact, it already did. Is Spring growing ? Can you show the numbers ?

This is one of the reasons your comparison with UNIX-Linux is far from being precise. Mostly because by using Linux, you can always switch to another distribution. When Spring dies, you are in trouble. Or you have to fork it on your own - who would want to do this ?

Re: More Responses to this Nonsense by Reza Rahman

You brought up a great point I missed - thanks for that. In fact the reason *NIX portability exists is because of open standards like POSIX and now the Linux Standard Base (LSB). Most genuine open source folks try and advance open standards, they don't try to bash and undermine it, unlike Pivotal and it's employees.

Re: Leave the bubble by John Hogan

My guess is that Pivotal resorts to FUD to deflect attention away from the awful dependency nightmare that is the spring experience. Developers are supposed to enjoy this so they can innovate faster. Never mind that their using uncertified libraries (many of them javax), and they're still stuck back in Spring 3 land anyway.

Re: Leave the bubble by Reza Rahman

Indeed this is yet another real world problem with the fat jar approach that Pivotal actively denies while simultaneous bashing Java EE...

For years Pivotal and it's employees actively attacked anyone in the community that dared pointed out the configuration hell that Spring caused that Java EE did away with as of Java EE 5!

They've finally managed to fix that with Spring Boot only to make the dependency hell part they always had even worse. Now that part is so abstracted that you never know what Spring Boot is actually generating and what dependency conflicts it may cause if you don't get your Maven configuration exactly correct. It's virtually impossible to change or debug anything if what Spring Boot is auto-generating is not what you want or something isn't working correctly.

These problems are virtually non-existent in Java EE 7 projects with typically minimal Maven dependencies and very thin war deployments.

Re: Leave the bubble by John Hogan

No guarantees of API compatibility testing, nothing is standard. Truly a plug and pray framework. It seems like the Spring folks just grab every jar lib I every heard of and put a wrapper on it and hope everything works. What interoperability testing is happening ...? Who knows. Then they only talk about how lame the JEE community is for doing their due diligence, and going through the compatibility testing process. It takes a while for good reason, it's hard work. App servers that pass Java EE Compatibility Test Suite (CTS) get licensed and provide a meaningful assurance to their customers. Any company fool hardy enough to pay for Tomcat or any other app server support if their running Spring apps deserves what they get. IMO, they should not bother because they're flying by the seat of their pants anyway.

Java EE has been continuing to be one of the best player on the market by Rahman Usta

Thanks for everyone for criticizing Gartner's report. Java EE is an great "standards" ecosystem (it is an umbrella) for Enterprise field has been built by directly Java Community. It is not directly bound to a company. Enterprise needs are evolving and Java EE would bring new standards for new needs in Java EE 8 and Java EE 9.

Re: More Responses to this Nonsense by Reza Rahman

Here is Red Hat VP of Engineering and JBoss CTO Mark Little's very worthwhile reaction to this. Key sentences: "one subjective statement after another, with no real attempt to justify them", "the report fails miserably to differentiate between Java EE as a standard and the various implementations", "many Java developers do like Java EE and do want to use it", "a report which criticises something based on data which is largely a decade old means it was probably written a decade ago"...

Re: More Responses to this Nonsense by Pieter Humphrey

> Is Spring growing? Can you show the numbers?

Hi Pavel, sure thing! That's easy. Check any available index of public you can think of.

Disclaimer: I work for Pivotal but am a big fan of JPA, Servlets, JMX - sometimes even JMS and JAX-RS :)

Here are a few examples:

Then try comparing

or reading:

Between the above and this article it's pretty clear that the market doesn't care about a standards - based JCP process to get their technology. During a time of seachange, "standards body" led alternatives aren't available by definition - just "de facto" standards e.g. open source. Java EE and the linked app server / middleware portfolios from mega vendors are focused on vendor neutrality and portability in places that were right at the time, but that time has long since passed and people want portability and vendor neutrality in different places, ones that Java EE doesn't provide. Mostly, customers are scrambling to just keep pace and topics like portability and vendor neutrality are secondary or tertiary to even having an option at all ;) That's why do you think "opinionated" solutions are so trendy lately?

Counting maven downloads is fraught with issues, but since it's the only metric Sonatype makes available, we are forced to deal with it, sadly. Gradle numbers don't get included, private repos get missed, CI builds artificially inflate the number, etc etc but it's the trend that matters. Spring Boot experienced a 425% increase in maven downloads from Nov 2015 to 2016, topping out at 10.2 Million a month.

I'd be curious to see what metrics Java EE has to offer to counter the decline, I'm like Mark Little in that I like data. The mega vendors behind it have been using revenue from products layered atop app servers to obscure the fact that people starting moving away from using full-blown Java EE app servers for app dev back in 2004. This report clearly states that they can no longer do so. Cloud (SaaS) has eroded those business as well.

to quote Cameron's signature signoff:


Re: Leave the bubble by Pieter Humphrey

Hi John, ICYMI:

Spring ecosystem and 3rd party dependencies testing list

Spring Framework compatiblity with Java 6,7,8

To avoid any misunderstandings: Spring 4.x has been shipping full support for JPA 2.1 and other EE 7 level specs since 2013, side by side with our JPA 2.0 / EE 6 support.

Re: More Responses to this Nonsense by Reza Rahman

To state what's probably already obvious, the original article includes a very sufficient number of independent data sources that demonstrate Java EE and it's APIs remain the dominate technology in server-side Java by a healthy margin (and yes, that includes the ZT survey Pivotal is quoting). If we don't want to accept those focused survey results as reality, it is always possible to play various games of pulling up selective data with manipulated keywords to try to advance a product propaganda.

Just to prove a point, here is a Google Trends graph comparing the terms "Spring Framework" and "Java EE". The reason using "Spring" as a keyword doesn't work is because that also refers to a season in case we are forgetting. Adding "Java" helps but is still highly imprecise. It is also the case that Java EE is hardly represented by just a keyword like "java ee" but also "Java Enterprise Edition", "JEE", "J2EE", etc not to mention all of it's constituent APIs...

Re: More Responses to this Nonsense by Pieter Humphrey

where are these "very sufficient independent data sources" you mention? I can't find a single one. The Guardians survey clearly has a built in audience bias by definition and cannot be considered independent data. The vaadin survey collects data from a whopping 250 developers. The only points of direct comparison in the Zeroturnaround survey, which IIRC had a statistically significant sample size, shows spring is the #1 and #2 web framework. Did I miss something?

In this ZT survey below, the only point of direct comparison indicated that of ~1800 responses, 36% are migrating from Java EE to Spring, compared 14% in the other direction.
ZT survey data:

Also, I added "Java Enterprise Edition", "J2EE" and "Spring Boot" to *your* google trends query, and it doesn't support your claim in the slightest.

Like Java EE is the new J2EE, Spring Boot is a modernization of Spring Framework and is a more relevant search term in the 5 year time window you've chosen for your trends query. (I left out JEE as a google search for it shows that it's overloaded, similar to Spring being a season)

Re: More Responses to this Nonsense by Reza Rahman

I have to wonder now - have you even bothered to look at what's linked before continuing your flame war?

There is no such "Java EE Guardian adoption survey" linked anywhere. What we have done is curate all such relevant data that we can find. We haven't properly curated the latest ZT and Vaadin data yet, but we will as community volunteer time allows.

If we must continue bickering, here are the specific key independent surveys referred to:

The wide ranging DZone survey with 1200+ responses showed more adoption for Java EE than Spring by a good margin for all roughly corresponding versions including Java EE 7 and Spring 4. The same survey showed independently high adoption for JSF and JPA compared to their respective alternative technologies. These survey results were highlighted in a JavaOne keynote with DZone's full permission.

Similarly, the most recent main ZeroTurnaround productivity survey with about 2000+ responses showed a majority of 58% developers using at least one version of Java EE. That's very similar to what the other surveys show for overall Java EE adoption so there is definitely consistency. This is the general conclusion that the report draws we saw that both Spring and Java EE are pretty popular choices, and the general consensus is that both are quite excellent. The more focused Spring vs. Java EE survey showed that generally more developers use Java EE than Spring (~1700 vs ~1400 respondents). The highest adoption rate for any Spring version was 47% while the highest adoption rate for any Java EE version was 60%.

As to your attempts to over-emphasize the 36% that say they favor Spring over Java EE vs. the 14% that say they value Java EE over Spring: the real story is that the majority (50%) are not interested in holy wars and value both technologies equally. Also, let me remind of the fact that a full 14% of developers of a given technology say they want to migrate to it doesn't exactly support the "Java EE is dying" propaganda now, does it?

The Vaadin community survey is smaller no
doubt, but it basically bears out the general patterns of the larger DZone and ZT surveys - 41% say they use Java EE while 32% said they use Spring.

If I were you, I'd tone down the Spring Boot chest thumping a bit. There's no doubt Spring Boot is getting fairly impressive adoption, but it's nothing close to what you guys at Pivotal claim in the real world outside of marketing rhetoric. For one, the reality is that enterprises just don't move that fast. To get a more realistic view of things check out job data on a site like

* WebSphere: 1257
* WebLogic: 907
* JBoss: 936
* Tomcat: 1374
* Spring Boot: 339

The reality is that when it comes to the enterprise, "ye old" Java EE and application servers (and we'll even leave Tomcat out of this despite the fact
that it is basically an implementation of a core Java EE specification) have far more traction than anyone realizes and that's reflected in the revenues of companies like IBM, Red Hat and Oracle. Spring Boot certainly has not exceeded the adoption rates of even older versions of the Spring Framework, let alone Java EE. The reason it has a good showing is that it is a relatively new technology so people are doing more searches on it. In fact, if you add up the search results for "J2EE" and "Java EE" the line will probably still mostly intersect the one for
Spring Boot. I hope that's slightly humbling food for thought.

Whether you guys like it or not, you'll need to co-exist for a long time with Java EE if not live under it's shadows. That should have been your lesson in trying to unsuccessfully undermine a highly commercially successful open standard for the better part of 14 years with your negative marketing. That's even more true now with well organized grassroots communities standing behind Java EE.

Re: Leave the bubble by Pavel Pscheidl

I recommend studying the basics about compilers and languages.

Btw. Who says AS is an antipattern? How is it a fact ? Because you say so ?

Re: Leave the bubble by John Hogan

Hello Pieter. That's a very impressively long list of jars. It reminds me of tbe inside of the war file for any Spring app I ever saw. Didn't see a word on testing though. Where is the testing part?

Glad you guys got to JPA 2.1 in Spring 4, but feel really bad for everyone stuck in the Spring 3 maze. Talk about vendor lockin...

Re: More Responses to this Nonsense by Pavel Pscheidl

Easy with that statistics talk, since you should learn it first. First statistically significant sample size depends on MANY variables, including population size ! Also, on what confidence level are you operating ? How does the exact hypothesis sounds ?

And most importantly, is the picked sample good enough ? Is it random ? By looking at the surveys, it's by far not enough to prove what you're trying to prove.

Re: More Responses to this Nonsense by Pavel Pscheidl

I agree with Reza. We've come through many years of troubles with people form Spring, our little angry brother. Lies, provocative blogposts, false advertising. We always have and we always will stand against your weird behavior.

You will have to live in our shadow for a long time. Java EE has better and much stronger community, better APIs, better design. More choices, more functionality. And we're TRULY OPEN.

For the years to come, you can try any evil marketing technique you want. You can write blogs, you can pay others to do viral marketing for you. Those who do not remember their past are condemned to repeat their mistakes. Time has proven Java EE wise. Your strategy just does not work.

Re: More Responses to this Nonsense by Reza Rahman


I must say thanks for your genuinely passionate defense of Java EE in this thread and elsewhere. I do hope others in the community take notice and try to understand why some of us believe in Java EE as much as we do.

I also think your final follow-up blog entry to Gartner's highly inflammatory, very poorly done, irresponsible and downright suspicious report is worth highlighting here and elsewhere. I do hope they are listening as well.

I will try and follow your example and get my perspective out there as soon as time allows from the day job...


JEE to Spring to Docker to Serverless by karthik karuppannan

I see the future as more of serverless and dockerized images (with lightweight containers like Jetty/Tomcat). JavaEE folks will continue to fight the losing battle... yes, the current JEE app servers are far,far better and light-weighted than the previous bloatwares. But that's almost irrelevant. The tech is moving towards containerless world and JEE folks claiming about lightweight containers does not matter. With cloud and microservices, developers have the upper hand than the infrastructure/sysadmin folks. That means developers don't want to be tied to certain JEE spec because of the JEE server.. Developers will always go for Tomcat/Jetty and cherry pick the JEE specs they like. and if developers choose it, devops folks will just support it. Spring makes things a lot better for developers (springboot, embedded server, native cloud features).. I'm a huge fan of Spring, but with Serverless/FAAS computing, even Spring is not my first preference now. In near future, most of the apps by default will be serverless and the rest will be based on frameworks like spring, django, RoR, etc... that's based on my dev work at ground zero :)

The truth about Gartner researchers by Ondrej Mihalyi

It was clear from the oriiginal report and even more confirmed by the evasive answers in this InfoQ interview that Gartner's consultants are no researchers but rather experts like any other, driven more by their own knowledge and feelings than by serious research and desire to provide objective information about what's best.

But, with recent statement by Ann Thomas, there is now a proof that there are a lot of emotions driving their Gartner's reports:

The most obvious claim of the 2016 Gartner's report about application platforms, Java EE being obsolete, is clearly based on nothing more than an old experience 13 years ago and a lot of personal preference towards other platforms. A true researcher cares more about objectiveness, present knowledge rather than past, and numbers, than about empty claims that may become false under the pressure of time.

Gartner should disclose their sources for their claims, not just comparing revenues iin chosen Java EE servers. They forgot to analyze how many of the deployed PaaS applications are still based on Java EE, shifting revenues from traditional servers to the cloud platforms. And there's a lot more to analyze and provide numbers for.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

47 Discuss