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.
- Top 5 Ways Process and Content Management Helps Insurers Increase Profitability
- Five Questions to Ask Before Choosing Responsive Web Design for Your Financial Services Firm
- IT and LOB Win When Your Business Adopts Flexible Social Cloud Collaboration Tools
- How to Stop Web Application Attacks
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.