BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Java EE is one of the best known and widely used platforms for developing and running enterprise applications—and it has been for a long time. A big advantage of such a lengthy pedigree is that it instills trust. But Java EE also faces the ongoing challenge of being forced to evolve or become obsolete. In a world where legacy is a point of pain rather than one of pride, how will Java EE fare in the future?
Yesterday's solution can be today's problem
While the flashy new languages and sleek development environments get attention for how well they meet the needs of businesses today, Java is often seen as being stuck in the past. Sometimes, that perception is based on a literal reality. Just because there's a Java 8 version available doesn't mean it's being adopted at a significant level. Brian Maccaba, JVM security expert and CEO of Waratek, recently revealed that outdated is the in thing. “Most of the clients we talk to say they are running every version of Java under the sun—except the current one.”
It takes a long time to update and run migration programs to get older applications switched to the latest Java edition. Brian noted that the average enterprise faces a host of compatibility problems and complexities due to developers leaving the organization, lack of documentation, and so on. “If you have compatibility problems, if it's not going to be trivial to upgrade your applications, then there are going to be long periods of time when you are going to have exposure to these older versions and their inherent security problems.”
According to Maccaba, 5% or less of enterprise customers are running Java 8. About 20% of applications are deployed on Java 7, and a whopping 75% are still deployed on version 5 or 6. That's a lot of legacy to maintain, and it opens the enterprise to a variety of security issues such as SQL injection attacks.
The proliferation of code sources simply adds to the security holes and migration issues. “With the Apache Struts Framework, the use of third party libraries is a very big problem. Typically in an enterprise application, only 20% consists of internally developed code. The rest is coming from external sources like vendors and the open source community.” Enterprises are left with few options for protection as they wait for a patch to be created by a third party.
Modern Java EE gives Spring a run for its money
Even as legacy Java tends to place a significant drain on the system, the more recent versions are surging forward to prove that Java is still very relevant in today's enterprise landscape. Ironically, borrowing heavily from the concepts of other frameworks may be what helps Java EE maintain its place as a leader in enterprise development. According to Nicholas S. Williams, author of Professional Java for Web Applications , the EE of today is a strong competitor for Spring.
“You cannot refute the argument that the enterprise edition has grown and improved significantly over the years, and adopted many of the approaches, patterns, and tools that you normally find in the Spring framework. It's certainly possible that users could find that attractive and want to take the full Java EE approach.” Staying with a single platform and framework is always tempting for enterprises, which savor standardization almost as much as they crave customization.
However Nicholas was not convinced that EE can claim primacy based on stature alone. In fact, being a lightweight is a competitive advantage in the framework world for some very practical reasons. “If you look at the selection of modern application servers that implement the full complement of EE features and then look at the Spring framework to compare footprint, memory usage, and other aspects, using the full Java EE stack is still not all that attractive. I think that an application created through the Spring framework is smaller, runs faster, and is easier to develop.”
Of course, Spring doesn't make EE completely redundant, either. Williams noted, “They're not done with EE, their still improving it. The addition of WebSockets in version 7 was huge. You'll notice that Spring Framework 4 didn't offer a replacement for EE WS, it just offered a complement that makes them a little bit easier to use and makes it easier to integrate existing spring beans with WebSocket listeners. It's hard to say for sure if either of them will ever win. Whichever way it goes, it's far from over.”
That seems to be the case each time Java is declared in danger of becoming irrelevant or obsolete. It's deeply entrenched in the enterprise, and it's not just dead weight. Java EE is still alive and kicking—and it won't go down without a fight.
Which would you use for new software projects, Java EE or Spring? Let us know.