The Future of Java in the Enterprise - InfoQ’s Opinion

| Posted by Charles Humble Follow 977 Followers on Feb 20, 2017. Estimated reading time: 5 minutes |

As part of ongoing work to review InfoQ’s editorial focus for the next year, we’ve been looking at the Java landscape in some detail. We use the model from Geoffrey Moore’s classic Crossing the Chasm book, which is closely related to the technology adoption lifecycle in which five main segments are recognised: innovators, early adopters, early majority, late majority and laggards. Moore’s model introduced the idea of a large gap between the early adopters and the early majority, i.e. that early adopters are willing to take risks for the advantage of being first, whereas the early majority wait until they know that the technology actually offers improvements in productivity before they will take it on.

You can get a sense of our overall view on the independent trends in Java from the following adoption graph:

We continue to see Java SE as in good health, and it remains one of the most widely adopted languages for enterprise computing. Java 9 is expected to ship this summer, and includes both Jigsaw and the JShell REPL. Work on Java 10 is already underway. Given this, we believe that Java remains a great choice for building large-scale enterprise applications, particularly where they are expected to remain in production for some time.

In terms of alternative JVM languages we continue to see interest in both Scala and Clojure, but reader interest in Scala suggests the language may have reached an adoption peak; we can trace a small drop in Scala interest amongst readers around the time Java 8 shipped with support for lambda functions. Our instinct on this is that it hasn’t yet “crossed the chasm” in Moore’s parlance, and therefore still sits in the early adopter stage. We don’t currently believe it will reach majority status.

Clojure continues to do well, and its data-oriented design places it in a strong position as an alternative to Python in the Data Science world, but again it doesn’t feel like a language likely to see mass adoption.

Groovy remains very popular as a scripting-like alternative to Java, and JetBrains’ Kotlin seems to have found a firm niche for Android development, but neither language appears likely to challenge Java’s dominance at this point.

It should also be stated that whilst things looks positive for Java SE, the same cannot honestly be said for Java EE. We debated whether it belonged to the “laggard” category, but recent signs of life prompted us to hold it in late majority, and in addition the underlying technologies that make up Java EE are still relevant. Ben Evans, co-founder of jClarity and one of our InfoQ editors said

I'd argue that Java EE as a brand is fading, but the underlying core technologies that make it up are holding up better than the headline "Java EE" adoption suggests.

Another of our editors, CTO for Global Infrastructure Services at CSC Chris Swan said

...whilst there are some useful and important specs that fly under the Java EE banner, the heart of EE, and what really drove Java app servers into the enterprise, was EJB. Spring stripped away the complexity of EJB, and over time 'EE' came to mean 'we run Spring on a grown up app server'. The traditional app server market (dominated by major vendors) is being displaced by newer PaaS offerings (because of course you don't need full fat EE to run your Spring app); and there are two forces pushing in the same direction - enterprises are sick of being held to ransom by major vendors, and PaaS offers more contemporary operational capabilities.

Indeed as InfoQ has previously reported even Gartner, who typically track trends further along the adoption curve then we do, has recently argued that “Java EE and other three-tier frameworks, such as ASP.NET" are fading in relevance:

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.

Fewer than 35% is, of course, still roughly a third, but generally we agree that while Java EE app servers will continue to be around, they will gradually be shifting towards running legacy-only workloads.

The good news for Java as a whole is that several competing frameworks offer a good range of options for building microservice architectures.  The obvious front runner is Pivotal which has a solid microservices stack. Spring Boot provides a fast and convenient way to build stand-alone Spring applications that embed Tomcat, Jetty or Undertow directly. Spring Cloud, supported by Pivotal's strong relationship with Netflix in the US and Alibaba in China amongst others, adds a number of battle-hardened cloud components to Spring Boot for service discovery, external config, circuit breakers and load balancers.  Commercial support is offered via Pivotal Cloud Foundry and other vendors including IBM with Bluemix and SAP with HANA.

There are also a number of strong alternatives for building microservices in Java. Three that are particularly worth paying attention to are Lightbend with Lagom, which builds on Play and Akka, Eclipse Vert.x and Ratpack. The actor model in particular, used by Akka, is something that we find compelling.

We should also note that Oracle has stated that they are looking to revamp Java EE for the cloud, with Java EE 8 expected late this year. Oracle states that Java EE 8 will have basic microservice and cloud capabilities, however the details are still sketchy. Java EE 9 is then expected in 2019, so it is possible that the landscape could look very different in a year or two.

The broader Java EE community has also begun working on the, which recently joined the Eclipse Foundation.

None of this should be taken to mean that we won’t continue to follow developments in Java EE with interest, or that it is likely to disappear altogether. We do however think that there are more robust options available for building modern systems.

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

Hype is great with this one by Pavel Pscheidl

Standalone applications can be also built on Java EE. In fact, there are more choices. Have a look:


The Gartner report is suspicious from my point of view and has nothing to do with reality. In history, Gartner already predicted the fall of Java EE and it's replacement by competition. The opposite is the truth - Java EE is stronger than ever and even Pivotal's revenues are not the best. More details:


Looking for microservices-patterns ? We have this for a long time. Just use Google instead of presumptions. Want service discovery ? There are more choices as well, for example SnoopEE (

In fact, there is everything needed already and much more. Have a look here:

There is nothing Spring can do that Java EE cannot do. With frameworks like Vert.x, you need to add a great amount of functionality, for example dependency injection - can be extracted from Java EE as well. In fact, all these services rely on Java EE. I do not see any advantage in using Spring. I am still looking for someone to name one single use case where Spring can do more. In fact, it's core is much older than Java EE. Compared to CDI, it is almost deprecated.

Please be aware that all the recent microservice hype is just a hype. From computer-science theoretical point of view, having a fatjar, which in the end means bundling application server into the jar itself), may be a stupid idea. Actually a very stupid one, in some cases. Actually, Adam Bien demonstrates that thin wars + Docker provide much better productivity and easiness of project creation:

Java EE - more than AppServers by Stephan Knitelius

Java EE has grown around the concept of application server, however the ecosystem has always been more than just the standard specification.

Vendors such as Payara, IBM, TomEE and RedHat have provided runable versions of their Java EE implementations for a couple of years by now, and are be no means inferior to Spring-Boot.

As Pavel pointed out MicroServices is the flavor of the month, a valid tool for a specific problem domain but not a one size fits all solution.

Its interesting that BlueMix is listed as a target platform for Spring-Boot applications, yet not mentioning that it is just as easy, if not easier, to deploy standard Java EE applications to easily configurable Liberty instance, without needing to be packaged into a fat-jar.

Kindly Strive for Better Editorial Balance. by Reza Rahman

I wholeheartedly agree with Pavel and I suspect so will anyone that has actually used Java EE in the past ten years or so. If this is the state of editorial balance at InfoQ, I very sincerely think there is much room for improvement.

Pavel has already done a nice job pointing out the standard anti-Java EE trope that's already been debunked many times over but this write-up is still sadly rife with. I think Sebastian Daschner also does a particularly nice job as of course does Adam Bien. Seriously debatable statements presented as being properly vetted in the write-up aside, it is plainly factually incorrect that there is any uncertainly as to the content for Java EE 8. Oracle has clearly stated the contents of Java EE 8 some time ago...

Aside from undue negativity on Java EE, the other very dubious element to this write-up is the enthusiastic, totally unreserved endorsement of microservices. The reality of microservices is far more complicated. It is no coincidence microservices is mentioned prominently in the far more down-to-earth discussion around Hype-Driven Development. Even people like Martin Fowler are soundly warning against the hype. Here is a relevant passage for convenience:

"Don't even consider microservices unless you have a system that's too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application".

It is no surprise then that when asked, a clear majority of developers are stating they don't want microservices specific features in Java EE quite yet. What that means is letting vendors innovate via MicroProfile and pretty feature complete products like WildFly Swarm is not merely alright, but actually the right thing to do. Things should be standardized when the microservices dust actually settles, not prematurely in response to hyper-competition and hype.

I understand that this is an opinion piece by people that are immersed daily in a deluge of hype and vendor messaging themselves. Nonetheless, I don't think technical publications like InfoQ will serve it's readers well by turning into highly partisan news outlets like Breitbart or a Fashion magazine like Elle. This write-up honestly smells of both. Please do better for all of our sake - Java EE or not...

Re: Kindly Strive for Better Editorial Balance. by Yannick Majoros

I have currently the pleasure of having to help pay the technical debt in a Spring application. While it's mostly easy to upgrade an old Java EE app, which mostly still works, upgrading a Spring application is another thing. Spring seems to have an history of half-baked ideas, later abandoned, just to try to mimic an app server in your classpath. Persistence support, for example, has gone from HibernateTemplate (so much simpler!), to using Hibernate sessions directly (later recommended by Spring docs), to then recommend using JPA directly. So long for the so-innovative framework. Tons of similar examples (interceptors anyone?). Specifications? No, let's have some weird half-documented semantics for injecting collections. If it doesn't work like you'd expect it too, well, it's not in violation of any spec, as there is none.

OTOH, I've been using JPA for 10+ years now in my Java EE apps. Didn't have to play around with "rest frameworks" or "AOP libraries", just used what the standard proposed. And guess what? I still have production apps that originated more than 10 years ago, upgraded step by step whenever needed, changing app server or some spec implementation when required. I wouldn't ever go back, and I only see the technology grow.

So, I just choose Java EE whenever I start or have to migrate an application. It just give me some trust, and guarantees on my investment.

JAVA EE is on the right track by sam sepassi

First of all it is worth to mention that the time has passed that most programmers consider the JAVA EE or the mighty J2EE as a web programming tool based on java.
Java EE is a pack of technologies and innovations offering various enterprise solutions and services. Bolding the concept “Enterprise”, JAVA EE has to offer STABLE solutions and technologies. Considering the article and referring back to the stability of enterprise level solutions, the “LATE MAJORITY” is the exact position that we would expect the JAVA EE to be!
JAVA EE consists of various technologies or to be specific specifications, which are literally the "INNOVATIONS". Whatever framework we consider, CLOUD or microservice, it normally uses combinations of these specifications which is eventually a subset of JAVA EE.

Re: Kindly Strive for Better Editorial Balance. by Reza Rahman

Incidentally, Oracle just announced this afternoon that Java EE 8 is now targeted for delivery July, 2017. This was hardly a surprise as we have seen activity spin up dramatically since December including a number of public review drafts. I hope this gives some food for thought as to why off-the-cuff remarks like "the details are still sketchy" are annoying to some of us that actually use Java EE, care about open standards, bother keeping track of these things and informing whomever we can.

You're Joking Right? by John Hogan

Dear Charles. I think that Geoffrey Moore would be quite tickled you read his book and cited his model. He might also be amazed that you can somehow now use his model and actually see through your Spring goggles to be picking out the laggards and leaders. All this in an industry you seem to have a clearly limited and biased view of is nothing short of remarkable. I believe the opinions expressed here (as though they were facts) are clearly biased and misleading. I also believe that this article does a disservice to both InfoQ and your readers. Developers beware and don't fall into this Spring coolaide bowl.

The reality is that JEE is an open, transparent and hugely successful platform developed through the Java Community Process (JCP). The JCP benefits from broad world wide participation by leading technology companies including Oracle, IBM, Red Hat, SAP, and a long list of other private and open source companies, and also a long list of thought leaders in the Java community. In sharp contrast to this, Spring has none of these things, and is basically closed and mostly controlled by a single company called Pivotal (who). And the fact of the matter is that Spring does nothing useful without relying heavily on JEE under the covers. Try building a Spring app without JEE Servlets, JPA, JTA, ... It is very strange to me how Spring zealots are continuously knocking JEE, whilst :) at the same time being so heavily dependent on JEE. I encourage you to crack open your Spring app like a piñata, and notice all the JEE jars fall out. Beware though that the JEE jars you might find inside a Spring war file do not represent anything like thoroughly tested and cohesive JEE platform that is certified and has undergone the rigorous certification effort required to pass the JCPs CTS as all JEE certified JEE servers have done. Rather, your Spring app may have a disparate and partial set JEE dependencies cobbled together with tons of other "stuff" from various open source projects all over the web. This type of app represents a true Frankenstack. Any company using this stuff should know that they're definitely flying by the seat of their pants. P.S. Isn't Groovy that language that Pivotal recently pulled the plug on and gave to Apache? Funny how Pivotal keeps popping up.

Standards are robust by Rahman Usta

Java EE standards are robust and it evolves itself by directly community. Standards might come slow but becomes stronger after they are released. Java EE 8 and after Java EE 9 and also MicroProfile initiative will show how standards are robust.

What exactly is Java EE in the context of this article ? by Abhishek Gupta

There is a quote which says - 'Java EE as a brand is fading'. The very next line says that 'underlying core technologies that make it up are holding up better'. Readers should think about the following areas which have been left (maybe on purpose?)

1. what exactly is Java EE in the context of this article ?

(As per my definition, it's a set of specifications/standards worked on within the JCP and implemented by vendors)

2. where are these standards under the Java EE umbrella used ?

(few of the products/frameworks mentioned heavily leverage and integrate Java EE based components)

3. 'There are also a number of strong alternatives for building microservices in Java' - I am not sure what's the definition of 'strong' ? Adoption? Github stars? Duration of existence ? Committers ? what ?

I am not going to even dive into Java EE goodies, since

1. they are too many
2. the community out there will surely point them out one by one !

Disclosure: I am an Oracle employee but these are my personal views only and do not reflect the views of my employer


Not for the first time by William Smith

I am amazed by the reaction this is getting since it seems to me very measured, balanced and helpful opinion. Would love to see more of this on InfoQ. Well done Charles Humble and the InfoQ team.

I'm interested by this comment "The actor model in particular, used by Akka, is something that we find compelling." - can you expand a little bit on this. What do you like about the Actor model?

Also would you always advise starting with Microservices?

Re: Not for the first time by Charles Humble

Hi William,


I should preface my answer to say that whilst the post is a collective effort this is just response it just my own opinion.

I’ve always liked the actor model as an approach because I’ve found that they make multithreading problems so much easier to reason about. Many, many years ago I worked on a system for a retail bank that used IBM’s MQSeries and a product called Roma to build something analogous to an actor based system (in VB6, of all things!). What we found was that it was very easy for developers to understand and think in that particular way, and had some very nice scaling properties - for example you could monitor queue depth and then increase the number of running instances of an actor as appropriate. In the end you are pushing the multi-threading concern off the programmer - rather like Java did with memory management - and I like that as an approach. They are also good from a GC point of view since they will typically garbage collect their own heaps independently of other actors. As we note in the article Akka offers a lot of this for the JVM (Scala and Java) and is well worth a look

If you have a bit of time I suggest taking a look at Pony which is a moden-Actor based langauge which came out of Imperial in London - I found it very interesting and a bit easier to grep than Erlang (at least for my personal taste).

With regards to Microservices starting with a monolith remains good advice I think. When we talked to Adrian Cockcroft on our very first podcast he said broadly the same thing “People typically start with a monolith like Ruby on Rails or similar” and if you know your system is unlikely to hit scaling limits than a monolith is absolutely the way to go.

Also not all problems lend themselves to horizontal scaling. When I worked in fiancee, for instance, risk systems tended to be a bad fit for a distributed approach and I’ll guess that was the kind of thing Peter Lawrey was talking about here, so in those cases microservices are obviously not a good way to go.

So like everything in CS there is trade off; there are still plenty of unsolved or difficult problems when you start to distribute systems in this way - logging and tracing is one that comes up a lot, as is monitoring. But for many of the kinds of workloads that people are working with they do scale well this way, and Mciroservices is a path that has been well explored by a lot of companies at this point - Twitter, Netlfix, eBay, Google, Spotify to name but a few - and there are increasingly good solid frameworks that you can use to build on.

Charles Humble


Re: Not for the first time by William Smith

Hi Charles,
Thanks for your detailed reply, I really appreciate that. I'll take a look at Akka and Pony!

Re: Not for the first time by Pavel Pscheidl

Content of this message is de-facto the same as content of the report published by Gartner. But they removed the obvious lies and now they're trying sell the whole idea again.

If I take the only thing mentioned in this article, and that is Spring Boot, I can just only say "What the f*" ? Java EE has and greatly exceeds capabilities of Spring Boot. Java EE fatjars do not interfere with your application if you do not want to. Spring Boot is not capable to do that. Have a look at Payara or WildFly - you can do runtime redeployments - programatically. You can even do outside-of-jar redeployments - a very handy tool for Dockerization. I already provided link for that up above.

My problem with these articles is simple - it is written by people with strong opinion, but not so strong knowledge. At least the knowledge is not present in the article. Many Java EE capabilities are not mentioned. Instead, some Gartner report is cited and that's it. The value of Gartner report was also doubted many times. If nothing else, then please consider that Gartner failed to predict so many times (thus the disclaimer on their site) it hurts. If they really piss me off, I can do statistical analysis on their statements and trust me, that will hurt like nothing else.

That is why articles like this are not very well accepted. They are aimed at audience who select frameworks and libraries based on blogs and marketing. And we have to face consequences of this in real life.

Completely Ignoring WildFly Swarm and the Java EE Ecosystem by Reza Rahman

In the vein of outright choosing to ignore work that vendors do to innovate with Java EE, I think the most glaring omission is WildFly Swarm. Even a brief look at the home page should make it obvious what it is about:

"WildFly Swarm offers an innovative approach to packaging and running Java EE applications by packaging them with just enough of the server runtime to 'java -jar' your application".

Besides just fat jar packaging, Swarm offers an initializer, externalized configuration, discovery/registry (both built-in and external), client-side load-balancing, circuit breakers, clustering and so much more. It is nothing short of absolutely baffling why these features are only mentioned for Spring Boot and not WildFly Swarm and by extension the Java EE ecosystem at large.

It is as though the WildFly Swarm folks might as well not have put effort into innovating with Java EE as far as the likes of Gartner and InfoQ is concerned.

If anyone is still really honestly wondering why people might not think too highly of this write-up, I hope this illuminates...

obsolescence of Java EE? by Rudy De Busscher

The message that Java EE becomes obsolence is far from my experience. And last year, I coached several medium sized companies to convert from Spring Framework to Java EE.

And yes, probably their is the same amount of companies which makes the move to Spring and leave Java EE behind.

And regarding the possibilities of both frameworks, they are equally. There are not much things Spring Framework is capable of what Java EE can't do. And almost everything you can do with Java EE is also possible with Spring.

It is only a perception that one of the two is better and a response of someone who started with Java EE recently says it all

I never thought Java EE would be that easy

Even Oracle… by Oliver Gierke

I just came here to leave unbiased note that even Oracle is now running MOOCs on building microservices with Spring Boot:

Re: Even Oracle… by Ondrej Mihalyi

Thank you for sharing, Oliver. Though, from you, as a Pivotal employee, such info is never unbiased ;)
I think both SpringBoot, JavaEE-compatible runtimes and many other modern tools and frameworks are equally capable of building modern applications. As a member of Payara team, I'm obviously biased too, but I have to say that JavaEE makes it even very easy to modernize older applications, without rewriting them from scratch.
Springboot, especially when powered with Reactor engine, or other reactive frameworks like Akka or Vert.x are very useful for specific scenarios, but they also involve additional investment initially in terms of learning the tools and best practices. While JavaEE evolves too, it is much more stable and thus suitable for other scenarios.
It's only a pity that Oracle doesn't have a modern JavaEE solution - facing their own cumbersome WebLogic server, they decided to use a non-JavaEE framework to promote their cloud solutions, so that they don't promote their more direct competitors. It only shows their frustration with WebLogic, not that Spring Boot is the single best solution for the job.

Re: Even Oracle… by Reza Rahman

I am not sure this is terribly indicative of anything other than the fact that the cloud has made traditional rivalries less relevant. Microsoft runs Java on Azure these days and has their evangelists demo that capability. It doesn't mean they do not stand behind the their own technologies at the same time.

Re: Even Oracle… by Bruno Borges

Thanks Oliver for sharing this MOOC. It was in fact an idea we had to show that Oracle Cloud runs any technology, and we do plan to have other MOOCs for other frameworks as well in the future.

Interesting enough, we are going to promote running NoSQL databases on Oracle Cloud, but that won't mean we are giving up on Oracle Database or MySQL. It is just that Oracle Cloud does have an open infrastructure as a service that anyone can run anything on it, and some of our PaaS services are also open to anything.

Stay tuned for more MOOCs and openness on Oracle Cloud by following Or follow @oracledevs on Twitter.

Bruno Borges
Developer Engagement @ Oracle

Re: Hype is great with this one by Steve Hu

Hi Pavel,

You are comparing two obsolete platforms as Spring is no better than Java EE. They went to the wrong way to compete with Java EE by implementing all equivalent components and now it is bloated as hell. Take a look at the benchmarks between some lightweight microservice frameworks and spring-boot-tomcat and spring-boot-undertow. It's 20 to 50 times throughput gain.

Re: Hype is great with this one by Reza Rahman

Spring Boot is essentially a runtime framework over the Spring Framework. The overlap it has with Java EE is a mere reflection of the fact that Spring and Java EE have had more similarities than differences for a very long time. Boot would never have gotten any adoption at all if it did not functionally provide what the Spring Framework already provides. Indeed they cite their extensive (bloated?) feature set as an advantage over say DropWizard.

There. I did my good deed of the day. I defended Spring.

Re: Hype is great with this one by Steve Hu

A lot people will say Spring-Boot is not Java EE but they are wrong in most of the cases as Spring-Boot is based on servlet which is part of Java EE and was designed about 20 years ago. There is another way (reactive) to use Spring-Boot but not popular. In my opinion, Servlet API is the biggest roadblock for throughput, latency and developer productivity. Anybody who have ever written request/response wrappers in servlet filters would agree with me. They cannot change Servlet API due to backward compatibility promise.

Re: Hype is great with this one by Reza Rahman

If you want to make an actual constructive difference I suggest discussing your concerns with the Servlet expert group alias which is currently actively working on Servlet 4.

While Java EE does provide extensive backwards compatibility guarantees, it has pruned APIs in the past and added replacements. I think the backwards compatibility point you are trying to make is more applicable for Java the language, not higher level APIs that are far easier to change carefully over time.

The reason the Java ecosystem largely adopts Servlet is certainly not because there aren't alternatives. It's just that developers haven't seen the need to adopt them. For example, Netty has been around for ages. DropWizard uses Grizzly instead of Servlet. As you pointed out, Spring Boot can actually easily replace it's network protocol and resource management layer as can more Java EE centric micro frameworks like WildFly Swarm.

If there is a better way, both the Java open source ecosystem and standards process is sure to adapt to it. That's why Java is still as strong as it is even after all these years. Java is old, but it is also constantly being rejuvenated through careful evolution.

Kindly Strive for Better Editorial Balance. by Charlie Wilson


I can't understand your objection to this post since the Java EE Guardians pressure group that you run have been saying a lot of the same things.

"Despite all this there is growing evidence that Oracle is conspicuously neglecting Java EE, weakening a very broad ecosystem that depends on strong Java EE development. Unless things change soon Java EE 8 won’t be delivered in anywhere near the time when it was initially promised if it is delivered at all.
It is very difficult to determine why this neglect from Oracle is occurring or how long it will last. Oracle has not shared it’s motivations even with it’s closest commercial partners let alone the community. A very troubling possibility is that it is being done because Oracle is backing away from an open standards based collaborative development approach and is instead pursuing a highly proprietary, unilateral path."

It's taken 4 years for Java EE to get to a point when it might ship, and its hugely disappointing in scope. So we're really waiting until Java EE 9, expected at the end of 2018, to get an update. And then we have to wait for the app servers to support it. So 2020 or so to get a moderate level of cloud support into the spec.

Given the sea change that is occurring in how applications are built it hardly seems unreasonable for a site like InfoQ to suggest its readers might want to look for alternatives.

Would you seriously recommend a client try and build a system for large scale cloud deployment using Java EE today?

Re: Hype is great with this one by Steve Hu

Don't get me wrong. I love Java and has been using it since day one. In my opinion, there is no way to change servlet API without big impact on downstream specifications. What I really want to see is to discard servlet filter and redefine request and response chain more efficiently in order to address all cross-cutting concerns. i.e. rate limiting, cors, metrics, security, auditing, sanitization, body parsing, validation etc.

Re: Hype is great with this one by Reza Rahman

Changing the API for filters doesn't really sound like such an insurmountable problem if your concern is as dire as you claim. There are plenty of deeply knowledgeable folks in the Servlet expert group including from Netty, Tomcat, Jetty, Grizzly and Undertow. I suggest starting a real discussion there with detailed justification.

Despite popular mythology, the reality is that only a very small number of Java EE APIs have any direct dependencies on Servlet. Indeed if memory serves only the JSF TCK needs the Servlet specification. That's why it is rather easy for so many of the higher level frameworks to swap out Servlet such as even JAX-RS/Jersey (Jersey uses Grizzly directly instead). It's also exactly why almost every Java EE API including EJB, JPA and CDI have long been available as standalone, embeddable APIs.

Re: Hype is great with this one by Steve Hu

These issues were raised years ago and they cannot be resolved in the current framework. I've switched to undertow http core server and never look back again. Java EE is declining and it will be gone when everyone moves to cloud.

Re: Hype is great with this one by Reza Rahman

Can you kindly point me to where they have been raised? A detailed writeup would that can be properly evaluated would certainly be a lot more convincing that simply bombastic opinions. If these are legitimate issues worth addressing, don't you think the Undertow folks would bring this up in the Servlet expert group since Red Hat is one of the strongest supporters of Java EE? Or is it that these purported issues are not as dire as you claim?

From my standpoint, I have seen the Java EE community grow continuously from the point in time in Java EE when Rod Johnson stated his "Java EE is irrelevant" meme years ago. The last survey from RebelLabs shows 15% of developers state that they are in fact moving to Java EE from other competing technologies and a majority 60% - stating that they use Java EE. I doubt these are facts Rod imaged in the Java EE 5 era years ago. For so many of us, people like you that continue to make these assertions that are not really based on any real reasoning have a "cry wolf" quality. If the past is any indication, it is more likely you'll continue to be proven wrong years from now.

As to using Java EE on the cloud, folks like myself have been doing that for close to 5-7 years now - check out just some of these real world Java EE adoption stories. You can even see cool demos from Adam Bien first hand as to exactly how Java EE runs elegantly on the cloud. Those demos are far more powerful than any bombastic opinion coming out of any irrational naysayer...

Re: Hype is great with this one by Steve Hu

I don't want to argue about this but just to point it out that undertow core http can handle 2 million http request on my laptop for "Hello World!" and sprint boot + undertow servlet can only handle 100K with 2 times more memory used.

Re: Hype is great with this one by Reza Rahman

I looked at your benchmark the first time. The issue is that it is far too simplistic to have much meaning in the real world. The reason you are getting those results is the code you have basically does nothing but immediately return a string for a GET request. In that scenario, a bare metal NIO server will definitely perform better than a multi-threaded HTTP/Servlet container.

For a more realistic benchmark, take a look at this one from Niko Kobler. What it shows is that the results are far more mixed for the loads that most applications would realistically need to handle. And that's saying nothing about the fact that the NIO programming model is far more complex for most enterprise developers and likely can't be widely adopted for that very reason.

Re: Kindly Strive for Better Editorial Balance. by Reza Rahman

I think it should be pretty obvious that the Java EE Guardian position is vastly different from what is being said in this article (at best the article is a needlessly exaggerated over-reaction that should have been a bit better vetted by folks that understand the overall situation). If it is not, I'll indeed take the time to explain.

Firstly, what Oracle has done is clearly awful. However, they have clearly made amends in terms of the accelerated schedule for Java EE 8 and Java EE 9. The pace at which they are delivering things right now matches nothing we saw in the past including the Sun era.

Secondly, the reality is that Java EE 7 was a very solid release and the Java EE ecosystem/vendors have not sit still. As you'll see in the adoption stories links I just posted in my previous response, people are succeeding with Java EE 7 - including on the cloud, with Docker and using microservices. The reality is that most of what is in scope for Java EE 8 and Java EE 9 is already available as non-standard extensions to Java EE applications. This even includes network level enhancements like HTTP/2. This is thanks to Java EE vendor work including initiatives like MicroProfile and WildFly Swarm. That all being said, we still do need Java EE to move forward so we don't have to rely on vendor-specific features for too long. That's what the Guardians are at the core about. We wish to see open standards continue to remain strong for Java.

So to answer your question if you value your independence from vendors, the insulation from hype/Snake Oil that open standards provide, grassroots community/vendor collaboration, simplicity and productivity, Java EE does in fact continue to make very strong sense. That certainly includes applications on the cloud (we have already been doing that for years with Java EE) and utilizing microservices (in the frankly niche case where that applies for most blue collar enterprises that will never need Internet scale applications).

Red Hat Just Voted... by James Watters

"Red Hat will soon offer a supported, embedded Apache Tomcat runtime library to all JBoss Web Server and OpenShift customers. Any application that embeds Apache Tomcat, such as those developed with Spring Boot, benefit from a supported embedded Apache Tomcat runtime."

Re: Hype is great with this one by Pavel Pscheidl

Hello Steve,
my experience with Spring is exactly the same as yours.

However, your GitHub repository says nothing. You want to redesign Servlet spec to what ? Servlets and filter chains are such basic mechanisms I sincerely doubt there is something better right now.

Re: Hype is great with this one by Pavel Pscheidl

I ran your example and the solution marked as "Spring Boot Undertow" was running at exactly he same speed as "Wildfly Swarm". By the way, WildFly has Undertow inside too.

Only the Spring Boot solution took 3x-5x more memory under maximum load. (ab -n 10000000 -c 10000). The more concurrency, the more memory load difference.

Re: Not for the first time by Ondrej Mihalyi

I also mostly liked the article, as long as it was balanced and helpful. The actor model is very compelling, especially when high throughput is a huge advantage, and that's where frameworks like Akka, Vert.x, Lagom, and languages like Erlang really shine. Unfortunately, the concept is still unfamiliar to the majority of developers, and I'm not sure it will ever be recognized by the mainstream because of the complexity brought by its asynchronous nature.

On the other hand, Spring MVC and Java EE offer a simple thread model by default, easily understood by many. But both optionally offer asynchronous API for experienced users, without forcing to use it when you decide to avoid the complexity. I still don't know why the article only mentions SpringBoot, while a majority of Spring-based projects still use plain Spring MVC. But to say publicly that Java EE was even considered a laggard is, on one hand, honest, but on the other completely inappropriate and unresponsible by the InfoQ editors. Neither Spring nor Java EE deserves this. These platforms simply target a different majority than SpringBoot and other popular frameworks. It's obvious that the authors belong to the other majority, but it would be fair to give credit to the stability that Java EE provides, while still keeping pace with proven innovations. Its aim is primarily standardization and not leading the innovations. And the standardized API is very often much clearer and easy to use than its predecessors. I believe that reactive programming will be improved in Java EE soon, and maybe even some support of actor model will be eventually standardized, but not before it becomes adopted by the early majority. Until then, is a perfect place to standardize innovations, which will likely be adopted.

Re: Standards are robust by John Hogan

Agreed, JEE standards are very robust and a JEE server represents an extremely well tested, certified and licensed platform. This guarantees all JEE APIs are fully implemented and interoperable. To accomplish this, a JEE server must pass the JCP's Certification Test Suite (CTS). Everything is open and transparent. Spring does not do anything like this. There's none of these guarantees with Spring, and there's nothing standard about Spring.

Re: Kindly Strive for Better Editorial Balance. by John Hogan

I absolutely would recommend Java EE in the cloud to anyone because a JEE server guarantees a specific level of functionality that customers and companies can rely on for mission critical applications. With JEE, you know you can rely on standards that are open and transparent and that were developed through the Java Community Process (JCP). All licensed JEE servers have passed the JCPs Certification Test Suite (CTS) guaranteeing JEE specs are fully implemented ... The JCP is an incredibly successful and transparent standards body that has stewarded the development and evolution of Java and Java EE since 1998. The JCP has and does benefit from the participation and contributions of thousands of companies and individuals from all over the world. And as you know, the list includes a very long list of some of the largest technology companies in world and thought leaders in the Java community.

Spring is from a privately held company name Pivotal. With Spring there is nothing like the level of openness, transparency and standards compliance that Java EE provides. Not surprising, Spring typically gloms on to JEE and claims compliance. Springs doesn't undergo any kind certification that I'm aware of There's no CTS testing or certification. IMO, Spring customers are buying into a cobbled together and totally non-standard framework that will lock them into Spring forwever.

Re: Kindly Strive for Better Editorial Balance. by John Hogan

This is an excellent summary of the joy and ease of use that is the JEE development experience and also a small glimpse of the misery and pain of using totally non-standard and half baked Spring.

Java EE is a specification, you know that right? by Geoffrey Hayward

The author’s objective is to persuade the reader that Java EE is old hat. There is nothing novel about this view. It seems to be an unfortunate trendy theme. The recent, widely criticised, Gartner report has not helped this.

To the lay reader the ‘chasm concept’ may have an appealing allure, however I question whether it is a legitimate instrument to support the author’s opinion. Java EE is not designed to be cutting-edge. A highly skilled community of experts transform solid proven innovations into standards. Then the standards are skilfully curated into a Java EE specification. Early adopters of Java EE are the people and organisations who implement the specification.

Objectively, this article does not have scope to impact on any reader’s thinking. Yes, it is a plus one for the people against, but the author does not offer anything new. “InfoQ editors said” is hearsay. As for reader interest, InfoQ should think in a wider context and ask: does a specification need a constant stream of online buzz? And are Java EE developers just heading to when they need help?

Re: Hype is great with this one by Werner Keil

More importantly Spring-Boot is pretty much a "distribution" of other projects and technologies. DropWizard which the article failed to mention or several technologies by Netflix like Hystrix or Archaius. Or Apache projects. Pivotal has a long history of providing commercial support and some extensions to either Java EE or other Java based technologies. Mostly Apache, but that becomes more diversified with big players like Google, Amazon or Netflix.

Netflix while not a traditional IT vendor (but nor was Amazon starting to sell books or videos online, too;-) has become one of the biggest innovators in this space. And a vast majority of its Cloud technologies have one thing in common. They are written mostly in Java.

Re: Hype is great with this one by Pieter Humphrey

but we can build reactive support directly into the framework as a servlet alternative - in fact Spring Framework 5.0 will work with Apache Tomcat, Reactor Netty, Jetty, Undertow and possibly other non-blocking runtimes, using a familiar Spring MVC - like programming model.

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

41 Discuss