Java EE hasn’t been receiving the same amount of attention its open-source brethren have over the past year. While the JCP and the OpenJDK focused heavily on nailing down the plans for Java SE 7 and 8, as well as plans for the OpenJDK itself, Java EE 6 has quietly been moving toward implementation within IBM and Oracle.

And while Java EE 6 brought initial modularity changes along with the addition of REST support, Java EE 7, which began life as JCP standards proposals in April, looks to repair many of the historic problems with the platform.

Rich Sharples, director of product management at Red Hat, said that the Java EE 7 proposals created by his company are initial ideas for the future of the platform. The work ahead will first involve forming expert committees around these new ideas, then formulating and formalizing specifications for the future of Java.

Sharples said the vision for Java EE 7 includes four main goals: ease of deployment, support for HTML5, support for the cloud, and the deprecation of unused portions of the framework. The first and last of these goals were also pursued, to a small degree, with Java EE 6. In EE 7, he, they should receive a lot more attention.

“Because of Java EE’s focus on compatibility, there is a feeling it’s grown rather large,” said Sharples. “We’ve added a lot to the Java EE platform. With Java EE 6, a number of APIs were announced to be pruned or deprecated, and they will be pruned in Java EE 7.”

Among all of those proposed areas of improvement is one major proposal that caught the eye of John Rymer, a Forrester vice president and primary analyst. That improvement is a standardized cache API for Java EE.

“They’re proposing to standardize the elastic caching APIs,” he said. “Oracle has Coherence, which has a lot of usage, and it has an API. This is an important capability for scaling Web applications, not only in Java, but in .NET as well. There’s no standard API.

“This will be an interesting test to see how the new regime under Oracle works; they’ve got the leading product. I think it’s going to be an interesting test to see how the JCP handles it.”

Regardless of how that API turns out, Rymer said that Java EE is already heavily under siege from another Java framework: Spring.

“Our survey data says that Java EE and Spring, which is really the major alternative, are at parity,” he said. “The same number of developers said they were using Spring as said they were using Java EE. From our point of view, that means Spring wins because Java EE has a lot of big vendor support behind it, and Spring is all grassroots. It has achieved a strong position in the market, and that says a lot because there’s not a lot of promotional dollars behind Spring.

“Also, [in jobs listings], the growth rate in postings mentioning Spring is much higher than the growth rate mentioning Java EE.”

In the end, though, it doesn’t really matter what happens in Java EE 7 and Spring as long as the complexity remains, said Rymer. “We’ve just been hearing from clients that the complexity of Java is driving them away from Java,” he said.

“The most obvious place to go is .NET, but some are looking because they don’t want to go to .NET; they’re going to things like Ruby, like platform-as-a-service. There are no real great answers yet, but there’s a lot of pressure to find things that are better, that are easier to configure, that are more configuration-automatable through policy statements. It’s a real problem, and they’re saying in Java EE 7 they’re going to go after this, but we’ll see.

“If the problem is really in the implementation of the specification, then Oracle, Red Hat and IBM are going to have to make major revisions to their products to fix these problems.”