As a long-term Java EE developer, consultant and lecturer, over the years I’ve seen Java EE evolving into a solid, carefully thought out, flexible platform, and one of the most lightweight enterprise frameworks. Therefore I was very surprised to read so many negative and incorrect claims about Java EE in the recent Gartner report “Market Guide for Application Platforms“, written by analysts Anne Thomas and Aashish Gupta. The report claims that Java EE is not lightweight, has become obsolete and hasn’t kept pace with modern architectural trends. These statements are made very confidently, yet are rather surprising, especially coming from such a well-known advisory company!
The Java EE platform has been very successful in providing a standardized and mature ecosystem to power various needs in the enterprise, as well as for smaller and more agile projects, ensuring long-term backward compatibility. Its productivity has increased a lot in the past years. It’s no longer a waste of resources to spawn a separate JVM process per each Java EE application. According to the analysis of Antonio Goncalves, a respected software architect, technical author and a member of various JSR expert groups, “most app servers boot in less that 3 seconds” and “most app servers use less than 150Mb of RAM“, while many use even less than 50MB.
In the light of these facts, the recent Gartner analysts irresponsibly provide obsolete information about the Java EE platform. They base most of their statements on very “traditional” and out-dated ways of building and running Java EE applications in a 3-tier architecture, using Oracle WebLogic and IBM WebSphere servers as a reference. There is clearly much more in Java EE than these two; IBM, for instance, offer a more forward looking platform in the highly modular WebSphere Liberty Profile server as an alternative to their flagship product. Other vendors and projects, like WildFly Swarm, sponsored by Red Hat, or our own Payara Micro, derived from GlassFish Server, prove that Gartner’s claim “Java EE is a framework for building three-tier client/server applications” no longer reflects the reality. These kinds of oversights degrade the credibility of Gartner’s report.
Gartner further complains about the pace of Java EE. They completely disregard the fact that vendors evolve their Java EE servers and runtimes continually with extensions and improvements, with many minor releases. It’s only natural that sometimes the standardization process slows down as there are so many shifts in current trends, and so many approaches that there is little to standardize.
To deal with current ever-changing trends, some of the biggest vendors including Red Hat, IBM and Payara, decided to take part in the MicroProfile initiative. MicroProfile is an effort to unify the innovations much faster than it’s currently being done within Java EE, and feed the standards body with practical proposals after the innovations mature. Java EE plays a huge role in the standardization of the approaches proven mature by MicroProfile and other frameworks like Dropwizard, Spring Cloud, and Play framework. While the fast-evolving frameworks suit smaller and dynamic projects with specific needs, common and standard-oriented platforms like Java EE provide solid support for long-term investments. The old African proverb applies here: “If you want to go fast, go alone. If you want to go far, go together.”
Another misleading part of Gartner’s market guide is the implicit claim that Java EE platform sales decline in favor of revenues from aPaaS services. First, Oracle’s and IBM’s decline in application servers sales revenues, when faced with opensource offerings, doesn’t imply that the overall usage of the Java EE platform declines too. In fact, companies often migrate to more flexible and cheaper open source Java EE solutions, which fit their needs better. This is a good thing for Java EE because it proves the promise of the standard specifications works in practice.
Second, many mentioned aPaas solutions offer services heavily based on Java EE technologies like Red Hat’s Openshift. Java EE domination continues to prevail, but it’s transforming from traditional on-premise servers to cloud-friendly runtimes and Java EE based aPaaS products. Almost all mentioned PaaS offerings are geared towards Java EE, or at least support it via Docker. The “lightweight WAR” approach of Java EE fits the Docker model better than any executable JAR approach, as demonstrated by Adam Bien. Bruno Souza and Elder Moraes also testify that “Combining Java EE and Docker is not only possible; it is a powerful way for teams to develop and deploy portable, scalable HA services“.
The question is why the market guide specifically targets the criticism at Java EE per se? It makes much more sense to discuss the place of Java and JVM frameworks in general in building cloud-native applications, competing with other technologies like Node.js or function PaaS platforms. The nature of the Gartner report, and the recent announcement of Google joining the Cloud Foundry Foundation, leave the door wide open for speculation.
Think twice before you follow recommendations of technologies that are more lightweight and convenient than Java EE, especially if they come from sources whose knowledge of the current status of Java EE is most likely incomplete. Remember that adopting an unreliable technology, or switching to a new technology with no clear advantage, are the most expensive and risky choices to make in the long run.
Instead, I would recommend taking the approach of evolutionary architecture described by Neal Ford, a software architect from ThoughtWorks, and focus your effort on building modular Java EE applications that can be adjusted to whatever needs you’ll be facing in the future. If Java EE is no longer suitable for some modules, consider using frameworks that are compatible with a subset of Java EE specifications to reuse your knowledge. Although, it’s likely that you’ll need to involve a completely different approach to power those edge cases.
Rather than listening to Gartner, ask architects or experts whom you trust for recommendations based on their experience – or, simply see for yourself and compare. If you explore beyond the “traditional” Java EE servers mentioned by Gartner, you will realize that Java EE is already suitable for designing cloud-native applications. The Java EE platform, with its full ecosystem, provides flexible ways to run applications and is easily extensible for any current trends, as well as any future trends to come.
{{cta(‘4c7626f5-1e53-418e-90c8-add6e4af19c9’)}}
4 minutes
Very good and important article!
Unfortunately, decision-makers don’t take the time and look at JavaEE in detail and what can be done with it. JavaEE is currently the most lightweight and fast Microservice-Platform on the market.
And if you don’t believe me, believe in Adam Bien, he shows in his videos and talks, what you can build with a minimum of code and infrastructure with JavaEE. It is amazing and I hope, that not so many developers and decision makers trust the myths, which were perhaps true 10 years ago.
Compare with WebSphere or WebLogic, WlidFly Swarm is light weight, but if you compare with some other framework without Java EE/servlet, it is heavy weight. Some servers can be started within 1 second and only use 4MB heap and dozens times faster then WlidFly Swarm. I am maintaining a microservices benchmark and you can see all frameworks based servlet container are at the bottom. The servlet API was designed in 90’s and it would be considered wrong designed in today’s standard with multi-core, async and native IO.
https://github.com/networknt/light-java-example/tree/master/performance
I agree, thanks for bringing this up. Java EE is not built with optimization in mind. I hope it will adopt a more reactive development model too as soon as it makes sense to standardize it. It looks promising with latest reactive additions in JAX-RS draft and the plan to specify non-blocking JDBC API (https://www.voxxed.com/blog/2016/09/non-blocking-database-access/)
It’s interesting that the best framework in your benchmark is Undertow (Light Java), and the one placed last is WildFly Swarm, which is based on Undertow itself, but provides Servlet API. It’s probably time to think about alternative standard API to servlets in Java EE, in the same way as JAX-RS provides an alternative to SOAP.
It’s only pity that Gartner prefer frameworks like Spring and Dropwizard to JavaEE, while your benchmark clearly shows that those are not more lighweight than some Java EE implementations, like Payara Micro and WF Swarm.
Incorrect, IBM Websphere Libery is light weight and tailored towards microprofile.
Fortunately they are right and I cannot say I am not happy about it. Vertx, Dropwizard, Spark, Ninja, Rapidoid to name a few are here to stay…j2ee is going to be legacy within a few years, time to move on…
Yes, for playground-projects, these frameworks you mentioned are indeed an alternative. But if you develop business applications which normally should have a lifetime greater one year, why not using a standard, which is definitely valid for the next 5-10 years? Why rely on some proprietary framework? What real benefit brings these frameworks in comparison to the standard?
And that’s the main point: So many people always say, JavaEE is bad, old fashioned or something like this, but no one can really say “why” or can name the benefits of the “cool new frameworks”, which cannot be done with JavaEE.
The real benefit of light weight framework is it has high throughput and lower latency with minimum memory foot print. We have tested light-java vs spring-boot with a real bank transaction and the provisioning cost of spring-boot is about 50 times more than light-java. For the same throughput and latency of one light-java server, you need at least 50 spring boot servers to mimic the same performance. And think about you have thousands services running…
Sure, alternative frameworks are always beneficial, because no size fits all. Java EE nor Spring Boot aim to be the most performant platform. There is just too much abstraction to support all usecases and help developers focus on the business logic. For some real-time scenarios (like high-frequency trading), not even JVM itself may be suitable, or it has to be heavily tweaked.
On the other hand, special low latency frameworks naturally provide non-standard API and approach, and you have to master them to be efficient in using those frameworks. That’s an additional cost for having highly optimized application. Often, that cost is much higher than the cost of more powerful infrastructure. Gartner should be mentioning this too, but they just decided not to.
Thanks for your comment. Gartner may be right, but their reasoning is extremely wrong. They don’t provide any valid argument, except very subjective view of JavaEE which ignores facts and changes in Java EE ecosystem in recent 5 years or so.
I personally like Vert.x and Play/Akka, other frameworks might be equally good. But I’d counter your statement with some questions:
“Exactly which one of those frameworks is here to stay? All of them? For how long?”
I wouldn’t like to bet on only one of those technologies, unless they implement some widely used API backed by specifications, or at least a common agreement.
people like the gartner crew are just hype merchants, and perhaps jee itself at time have been guilty of this. JEE when u abstract away the hype is just an implementation of some important design patterns and these r relavent and of course the implementation will evolve in whatever form. People are naturally lazy, the easier it is to write code then the more popular the framework ie Javascript
Not for nothing, but my recent experiences trying to move an enterprise with a few tomcat/payara/glassfish based applications to a more devops like approach I found the way Java EE applications are deployed incredibly awkward. It’s basically a big mess of overly large shell scripts (often taken into account platforms and JDK nobody uses), duplicated configuration files, application servers deployed in the same path together with the application, log files, work data etc..
This adds to the perceived heft and complexity of Java EE, and this is what I and a lot of people think of when hearing Java EE leading me to avoid projects involving it.
I agree with a lot of what you said Nils, thanks for sharing. Java EE has this legacy burden from the past and many people just remember their unpleasant experience and don’t want to look back again.
I also had similar experience in the past, almost entirely in a corporate space, with applications in production for more than 10 years. Back in the time when they were developed and the deployment configured, J2EE used to be really complicated, and even Spring in version 2 or 3 didn’t provide much easier way of doing things with its heavy XML configuration.
But in recent projects, using Java EE 6 and 7, my experience was much much better, and I actually started to like Java EE for its simplicity (might be surprising for you I know 🙂 ) It’s only a pity that, because Java EE still supports all old patterns, people still use them with the new Java EE versions and implementations, ignoring the new options provided.
Yes, I was quite taken aback with what is possible nowadays with Spring Boot compared to the sort of applications I have seen, especially when leaving out Maven in favour of Gradle.
I would say generally though that some frameworks make it easier to map dysfunctional organisational patterns to the way software is developed and my recent experience shows that it’s a long way to pay off that technical debt.
I read the article from Gartner. It is incredible that such respected organization publish this article without enough real facts to sustain their declarations.
Your mileage will very. Sometimes JEE will fit and some times spring boot is a better choice. I use both WebSphere, Payara and spring boot. Happy with the two latter. What I do like about spring boot is that it is actively addressing topics like service discoverbility, configuration servers, data streaming and works with a lot of Netflix oss eco system. I find that absent in jee discussions. And that’s more important than a 50 or 150 mb deploy size. I think Micro is more about business logic than physical size.
I think you should worry about what fulfills your need and not a 500MB deployment. It is a micro-services for you but there is more to it for those who are comfortable with JEE and continues to employ the platform.
In my view, most of you guys are just here to sell what makes you feel comfortable not what is good for everyone.
I don’t think we could exist and earn money if we were just selling what is good for us. Every project is different and we just try to provide the best tools for projects that would benefit from Java EE. However, we think that the Gartner’s report is biased and describes only disadvantages and outdated facts about Java EE, avoiding any mentions of the benefits it provides, and I added the missing information here.
Payara Server, as well as many other opensource or closed-source Java EE products strive to meet the demand of our community and customers. If it wasn’t like that, there wouldn’t be so many projects running opensource Java EE solutions in production for free. My point in the article is that Gartner doesn’t have the knowledge of the current state of the Java EE product and ecosystem and that there are many projects that seek stability in Java EE and use it in any form of deployment, be it on premise or in the cloud. In those cases, effectivity of modern solutions isn’t worth risking of loosing the stability and long-term support of Java EE.
Each solution, including Payara, provides their own improvements and features on top of the Java EE standard. Those are often the same kind of improvements provided by other solutions prefered by Gartner, they are just not so well known and common. That’s why we joined the MicroProfile project (microprofile.io) to work towards unifying common modern features of Java EE based solutions on top of Java EE to provide a consistent experience, without locking users to a specific product.
Thanks for your reply and I think I should have been more specific with my initial reply. I am a JEE developer myself and I still feel very comfortable working in that space. I also concur with your observation with regards to the Gartener knowledge on the current state of JEE. It all eventually boils down to this market that is being waged by the Springs community on JEE.
Hi Ikram,
Thank you for the explanation. I’m really glad that I only misunderstood you, but you have to admit your comment was very vague and misleading. I’m not going to comment on the reasons why reports like this target compromising Java EE as a technology and ecosystem, but I think that it’s a technology as good as others if not better and it makes sense to me to defend it against false claims. And I’m doing that with any other technology I understand and believe is good.
Hi Ikram,
I hope by now that you know that the silver bullet doesn’t exist. That there is no framework/language/whatever which works for everyone in any situation.
And your comment suggests that Java EE isn’t the right solution for you, and that is OK.
But as a consultant, I see many clients which make the switch to Java EE for various reasons and regret they didn’t have done it earlier.
A report which only mentions the disadvantages of a system as it was 10 years ago or so, is clearly biased in my opinion.
And yes, Java EE has also some drawbacks, even today, just as any other system.
Hello Rudy, on the contrary, I am an ardent follower and user of the JEE platform and it suffices for me in most situation. My initial reply is been taken out of context and it is actually targeted at all the hypes surrounding all this newly introduced ecosystems but non-the-less as you have rightly observed, there is no silver bullet to any one solution.
As developers we need to be open-mined and knowledgeable about the advantages and disadvantages of the technology we adopt. It is essential that we make accurate judgements based on facts, so that the solutions we deliver to our clients/business are the best they can be. This is not possible if the information available is false or inaccurate. If it is part of a negative marketing campaign because others want to distraught market perceptions.
We are professional developers who use technology to solve problems. We want a toolbox with a selection of tools that can be relayed upon to solve problems, not negative marketing and disinformation. This is why so many people have reacted against the Garner report. It pollutes that vital information space and distraught rational decision making. It’s unnecessary and unwanted. It’s dishonest and disrespectful.
My perception of Paraya and their people is that they contributes heavily to the Java community and even though you notice their presence you never feel as if they are there to sell, they are there to make a contribution and they consistently make it.
As mentioned by Rudy De Busscher, one size does not necessarily fit all. As such, there may be more than one tool to do the job. In some cases Java EE may be the right fit, and in others, frameworks such as Spring may be the correct choice. In the end, Java EE still remains highly relevant…not only in enterprise, but also for smaller scale solutions.
The Gartner report clearly targeted older versions of Java EE that are now simply outdated. If you look back at older versions of other frameworks, they, too, are outdated. Everything evolves over time. Who is to say that Java EE has reached end of life when it is still evolving and moving forward? In my opinion, any technology is still alive as long as it continues to evolve, making progressive improvements and staying relevant with newer technologies. Java EE is doing just that. A year ago when there was a Java EE hiatus, then the perception may have been a bit different. However, even at that time we had Java EE 7, which is highly relevant in today’s market.
In the end, even those who do not know Java EE or do not wish to learn Java EE should not be indicating that it is no longer relevant today. It continues to improve in many areas, and there are certainly many organizations that depend upon it.
As a Java EE Guardian, paying Payara customer, and JSR 370 Expert Group Member, be assured that I totally stand behind Java EE. On the other side, we must accept that Gartner has a different view than many of us have: They only count real-world revenue.
The problem with Java EE is, that it is free. Hence, no Dollars have to be spent. Payara is great, but it simply is a free lunch, so the more people change from WebSphere to Payara, the less Gartner thinks there is interest. Simple math.
On the other hand, Gartner is right with some points and we should stop sugarcoat the truth, but get back to work and change the reality:
* While it was announced to be made for cloud natives, the reality is that Java EE 7 and Java EE 8 are NOT made for the cloud. Those APIs still ARE targeting application servers (either on-premise or hosted).
* Dedicated cloud APIs are still missing (not even under construction). For example, an API for NoSQL DBs, an API for FaaS (function-as-a-service; like wrapping AWS Lambda), or API additions to access other “cloud technology” (just look at the services offered by cloud platforms).
* If we don’t like this truth, we have to change it: Start JSRs for these APIs, start a JSR for “Java EE Cloud Profile”, and convince Amazon, Google, Microsoft and the OpenStack community to fully implement it.
Until then, we should abstain from criticising Gartner. They just told the truth as of 2016, which is totally different from what we want the truth to be in 2018.
If we want to have Java EE 4 cloud, we have to first accept that neither Java EE Web Profile nor Micro Profile is currently covering cloud-native technology. Once we all accept this truth, we can start working on it.
As far as I can see it, the whole debate misses the actual issue. We talk about ease of development, memory footprint, suitability for micro-services and so on. It’s not about JEE as heavyweight vs. micro-services. JEE is actually the perfect platform to run micro-services. I run for instance a content management system in GF that uses a language detection EJB. That EJB is deployed on its own, any application that needs that functionality just uses it. I don’t need to bother about where it is deployed what it’s host or port is or anything like that. If I ran it as a separately deployed micro-service I had to manage hosts, ports, IP’s and so on and if I ran a number of services of that kind I’d soon run into issues how to manage all those things or I bundle the service with it’s users, but then it’s not a micro-service anymore.
JEE application servers take that burden off me. Another advantage is that I can choose whatever application server I want, my JEE application will run in all of them. But here comes the actual issue: all application servers are fundamentally different in how to use them and how they implement security. I run GF and I know how to deply an artefact and how to set up a certificate realm; if I wanted to switch to JBoss (which I tried once), I’ll have a hard time to figure out how it works, how to install my app and how to set up security. The hassle setting up an application server and to manage it is the reason why many people think it is heavyweight and clumsy and I was working for a number of companies that opted for something easier, like Spring Boot. JEE is not our issue, it’s the application servers. There should be a standard for security and at least some common ground for management.
I still stick to JEE and I’ll use Payara when I install my next server; it’s a great way to run software. I’ve a GF running for more than eight years now without any problems and yes, it’s connected directly to the Internet.
Found this article while looking for some WAS Liberty material…
Gartner report is absolute on Point.
There is indeed a decline in JEE sales, both Products and Human Resources.
Companies INDEED are looking for lighter weight alternatives with Docker/Kubernetes as target runtime environment in mind.
JEE INDEED do not support Docker based runtime deployment with dynamic hostnaming and cluster scalability.
The deployment model of JEE indeed not covering external resources zero-configuration approaches.
The JEE development cycle CAN NOT by any means achieve on-time delivery in modern Sprint, Pipeline environment.
At the end of day… JEE developer can’t even do any type of refactoring… bumping up its dependencies… because he goes in to endless regression cycle…
Enough is enough guys.
I absolutely agree with that the Gartner’s article raised some good points, especially about the trend of going away from licensed software towards commercial cloud services. But I don’t agree that Gartner correctly interprets those facts.
Java EE sales are declining because IBM and Oracle app server revenues are declining and not because Java EE is becoming less relevant. At the same time Gartner talks positively about Spring, Dropwizard and other free frameworks that have no revenue at all so license revenues clearly don’t matter anymore. The industry has changed and Java EE is keeping the pace with it. Most Java EE vendors evolved their revenue model and get money from support or from cloud services rather than from licenses. But Gartner doesn’t take these revenues into account.
At the same time, most Java EE servers have evolved and provide alternative lightweight runtimes to fit Docker/Kubernetes deployment. A new set of lightweight APIs called MicroProfile has emerged on the Java EE foundation and some of it may eventually become part of Java EE itself.
An example of a lightweight Java EE runtime is Payara Micro, which starts in seconds, can build an uber JAR, supports elastic clustering using Hazelcast and supports Java EE and MicroProfile APIs. There’s even a kubernetes plugin to cluster instances in Kubernetes automatically with no configuration at all. You can see an example project for yourself: https://github.com/MeroRai/WorkDistributor
Other Java EE runtimes like OpenLiberty or WildFly Swarm offer similar functionality and both have a great community where you can raise questions and get answers. I know a lot of people behind those projects and can connect you with them.
I recommend to ignore what others say and explore for yourself or ask people that know more than Gartner 😉
Please no polemic und untrue sentences. JavaEE6 and 7 were a already perfect fit with docker and microservice architecture. And the old J”2″EE heavyweight argument does not count for years anymore… every JavaEE Server has a footprint von 60m of RAM… so where is it heavyweight?
Please present facts to your points, otherwise it is only worthless.