Addressing security concerns and evolving beyond Spring with Java EE 8

By November 5, 2014 September 5th, 2017 News

By Jason Tee
TheServerSide.com

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 EE 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.

Read the full article

News

Author News

More posts by News

Leave a Reply

X