When I first started writing this column more than a decade ago, my attention was focused on the teeming segment of enterprise Java technologies. Two areas in particular were hubs of competitive activity: J2EE servers and JMS providers. Different vendors’ products jockeyed for the market lead or to become the technological pacesetter. It was a great part of the market to cover, and the innovation it produced was fun to report on.

The market settled down due to two main factors: BEA’s WebLogic server was faster, better and more innovative than competitors. These advantages cemented BEA’s market lead, and the drama among commercial offerings steadily evaporated from competitors (Sun, Allaire/Macromedia, SilverStream, Novell, Pramati and others). In the free space, JBoss became the de facto implementation.

During this period, JMS vendors became largely irrelevant. The messaging bus was overtaken by ESBs, which sort of lost their way when Web services and (later) REST came to the fore. No longer were performance details that distinguished Fiorano from, say, BEA’s built-in messaging layer of much interest to anyone. Today, sites generally use the JMS implementation that comes with their Java server—and it takes care of most needs.

As the market resolution was working out, our then-Java columnist, Allen Holub, frequently pointed out that the resulting solutions were, with few exceptions, overkill. He claimed (and I believe rightly so) that the vast majority of sites using J2EE servers would be better served with an instance of Tomcat driving the app and plain old JDBC doing the bulk of back-end I/O.

For most of the intervening decade, the quest for a lighter way to do enterprise Java has been widely discussed, but without great enthusiasm. Some progress was made, though. The success of Rod Johnson’s Spring project was one step in this path. But because Spring is an omnibus solution that rides on the entire Java EE stack, it does not reduce the complexity so much as mask it. The Groovy-based Grails server does the same thing to Spring: It’s an even higher layer that comprises both Spring and Java EE.

With Java EE 6, we’ve seen more of a definite mainstream effort to reduce system complexity. Unfortunately, except for the open-source GlassFish project, there are no major Java EE 6 implementations. Even WebLogic, a server whose reputation was built on its early and eager adoption of new standards, still runs Java EE 5 only. IBM WebSphere—always a late adopter of standards—is also on EE 5. Only JBoss seems to have responded to GlassFish’s gauntlet. And by the time this column sees print, the Java EE 6 JBoss AS server should be out of beta.

The lack of enthusiasm for this new generation of servers is striking and indicative of a ground-shift in enterprise Java, first mentioned by Alex Handy: Java EE is no longer the future of enterprise Java.

The proliferation of Java Web frameworks suggest that developers are indeed identifying and building the functionality they want while letting the official version of Java do its own thing. This approach was no doubt given a shot in the arm by the success of Ruby on Rails, which demonstrated convincingly how simple it could be to assemble Web apps from components designed for integration (even if they are primarily not at enterprise scale).