Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

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

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

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