Channels ▼

Web Development

Java EE 7: And Then What?

With little fanfare, Oracle released Java EE 7 last week. This is the most recent release of the enterprise bundle of services you might recall as J2EE. It has come a long way from its early days as an oversized, tangled hairball. Today, it is a slimmed-down, redesigned, responsive, and more usable product than it's ever been. The question, though, is whether anyone cares.

More Insights

White Papers

More >>


More >>


More >>

You might recall that enterprise-scale, server-side Java was a technology designed in anticipation of need, rather than in response to it. It was a committee's solution for the expected demand for executing business logic on a server that was both serving Web pages and pushing completed transactions to a relational database. The design was a considerably over-architected solution that bundled every kind of possibly needed service — down to e-mail — in one massive package. At the center was the container, a sort of execution playground in which enterprise Java beans (EJBs) — components unrelated to their namesake Java beans — would execute business logic. In addition to being difficult critters to program, the beans were designed more for remote invocation than direct calls. Both aspects led to considerable dissatisfaction with server-side Java, although there was an emerging agreement that the technology did scale well enough to handle huge workloads.

On the strength of scalability and acceptable performance, Java became the default enterprise server — a less-expensive alternative to mainframes and superior to the still-evolving .NET ecosystem. But it was tied to the proposition that its programming was complex, difficult to get right, and generally unpleasant. This situation invited alternatives. I recall many conversations during that time wondering why a given site could not simply use a lightweight server such as Tomcat and use JDBC for persistence on the back end? For many sites, that would have been good enough and quite a bit easier to program. A mid-range alternative appeared in the Spring framework, which has slowly become the de facto way to write server apps in Java — particularly for projects below enterprise scale.

In perhaps one of the finest examples of open-source alternatives influencing a (then) closed-source predecessor, Spring's approach, which consisted of plain Java objects wired together by dependency injection, became a model for simplifying EJBs. The imprint of these ideas was first evident in EJB 3.0, released in 2006.

The Hollywood ending at this point would be that Spring then went on to triumphantly take over the entire Java enterprise space. But, in fact, it didn't. It simply coexisted, in part because Sun, then Oracle, began revving the technology regularly. In 2009, a lighter version of the container was released and more-nimble EJBs — EJB 3.1 Lite — debuted. That same year, Spring Source, the company behind Spring, was acquired by VMware — an unlikely owner. Spring Source has been an odd fit with VMware, which has never articulated its rationale for the purchase or how it aligns with the company's overarching goals. It was no surprise to see Spring spun off earlier this year with several other developer properties and database products into Pivotal. It would be fair to say that VMware did not put a lot of muscle behind Spring's development during the past four years. This gave the entrenched Java EE players — Oracle, IBM, and Red Hat — the time to continue tending to the product and refining it. Java EE 7 is the latest effort. It is, for most intents, an incremental upgrade. Perhaps the most notable change is a whole new API for the Java Message Service (JMS), which sorely needed a less-complicated programming model. It seemed clear at the announcement that the important release will be Java EE 8, which will provide new APIs to support cloud infrastructure and further tidy up the existing APIs and services.

If Java EE continues to add new features and simplify existing ones, it will surely remain comfortably ensconced in its present sites. And it could well shed the image of excessive heaviness. It's still hard to tell, but the vectors are pointing in the right direction.

— Andrew Binstock
Editor in Chief
Twitter: platypusguy

Related Reading

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.



Very good article and comments to really start evaluating what JEE is good for and not; not just blindly use any module, component it has to offer. As a JEE developer, insight outside of JEE is much appreciated. Thank you.


I still use a lot of interfaces in my code. I do that for different reasons:
Some Java tecchnologies require it (dynamic proxies, RMI, etc...)
It is a good way to insure that an APi does not involve direct access to data members.


I watched some of this happening from the sidelines. I left IBM at the end of 1993. At IBM I was a 'technical planner' in the CICS development team. There were two factions at the time, one that thought all resource management should be implicit (I was in this faction) and another, influenced heavily by X/Open, that wanted explicit APIs for all resources. Unfortunately, the latter faction represented IBM in the development of J2EE, now JEE, and so explicit APIs were provided for each resource. When J2EE came out I listed all the resources that should have been implicit and started ticking them off as they were added (or should that be removed?). For instance, container managed transactions, container managed persistence, message beans (which half manage the message queue). Then along came Spring which not only thought all resources should be implicit, but gave two mechanisms (dependency injection and inversion of control) for making that happen. Originally it was all wired up using XML but then annotations were added. Finally, you could make all my resources implicit. Now with JEE 7 you can more or less do that in a transactional server that is almost as good as CICS was in 1993 when I left.


+100 "... lot of Java Pros that just cannot build something without a boat load of interfaces."

Not only Java developers suffer from this decease:-)

It's pretty common for brainless pattern-followers, and those who like to impress others by number of layers and complexity, rather than by elegance.
Not sure they heard what Occam's razor is...

But has the issue something to do with Java?
Try .NET MVC4 with 20+ frameworks to compare...


Couldn't agree more about the complexity of J2EE. However, over complicating something simple is not new to Java. What baffles me is that a lot of incredibly good thinking went into creating Java. It is extremely flexible and able to accommodate almost any task but lost in all that flexibility is a really simple way to do the 80%. Over the years it's improved by leaps and bounds but there's still an awful lot of Java Pros that just cannot build something without a boat load of interfaces. As a contractor I work on projects all the time that have countless interfaces which end up having a single implementation. I know it's a pattern and developers like to plan for what ifs but it just seems like needless complexity until you need it. Perhaps following that pattern was wise when Java tooling sucked but the modern Eclipse IDE makes it a non-event to refactor a code base by pulling the public methods out of a class, creating an interface refactoring the code base to use it. So why does this pattern persist when it's really not necessary 80% of the time?
There's also folks who continue to write setter/getter methods when Spring and even Java EE can inject private fields. I know there's perhaps the use case for testing frameworks but why not use Spring there and eliminate a lot of boilerplate code? Granted, the IDE will write them for you but if you have a large service with a lot of IOC injection, that's still at least a screen-full of boilerplate to avoid when investigating functional methods.

Dr. Dobb's TV