On the Death of Java EE, aka, J2EE

I’ve spoken with several people about the recent prediction, from Burton’s Richard Monson-Haefel, that “JEE will be the CORBA of the 21st Century” in five years, meaning, it will be an annoying, obsolete platform. The original report is only available to Burton clients, so I have haven’t taken a gander at it myself. But, there’s also an MP3/podcast episode from Richard on the topic.

Still, and Always, Work to Do

I’m probably more in agreement with Monson-Haefel than the vendors who “struck back” in the reply article and other folks who reacted strongly to Monson-Haefel. Long time Coté readers and listeners know that I’ve spent plenty of time complaining about Java, Java developers, and especially J[2]EE.

I am after all, a Java developer of about 10 years: while I still like Java and JEE, I have several chips on my shoulder. Substantial changes towards simplification and inclusion of other languages and approaches to web applications still need to be rolled into JEE.

JAMP

Here’s what I’ve said to the folks who’ve talked with me:

Sure, if Java EE were frozen as it is now and never changed, it’d become obsolete once simpler and lighter-weight platforms, like Rails, were fully injected with the enterprisey serum. However, if Java EE continues it’s goal of simplifying and adds in support for more languages than just Java — such as JavaScript, PHP, Ruby, Python, and/or Perl — it can keep it’s position as platform for developing enterprise applications and services.

When I boil it down, Java EE programers want two things: transactions and scalability. Every single alternative is eventually judged by those two criteria. Once an alternative has the same mind-share for doing transactions well and scaling, Java EE will be truly threatened.

While maintaining Java EE’s strengths in those two areas, Java EE also needs to become a more inclusive platform, pulling in as many non-Java languages and technologies as possible. Java EE has lost a lot of ground on the platform front to Linux in the form of the LAMP stack. The LAMP genie is out of the bottle, but it highlights strategic thinking for Java EE in the future: it needs to become not just a container, but the entire platform for applications.

Abstracting away the OS was the early dream, but the missing feature to all of that was limiting the platform to Java only. The dynamic language JSRs are key to realizing this broader platform play. As such, the next bet for Java EE’s long-term survival is for the Java EE community to make running dynamic languages and frameworks like PHP, Rails, JavaScript, and python work as well, and even better, in Java EE as they do in Linux.

Java EE will steeply decline if the Java EE community keeps Java EE as a mono-language environment, where only Java is spoken. I don’t yet see WS-* driven SOA as any sort of panacea of the Next Great Framework, but we’re now starting see a solid WS-* backlash that could lead to the ideal SOA we’ve been mashing out over the past few years.

Key to riding out those waves, for Java EE, is being as open a platform as possible. Otherwise, the combination of Linux and the dynamic language du jour (PHP, JavaScript, Ruby, Python, Perl, or whatever comes next) will have a good chance of wining the day as the enterprise application platform of choice.

As Dick Wall would remind us, Groovy is looking pretty good nowadays as well.

Further Chewing

All that said, you might look at the result of those suggestions as something that wouldn’t be the next evolutionary stages in JEE’s life, but something else entirely. Fair enough, I wouldn’t argue against that understanding of such an arc. But it wouldn’t be my way of looking at it.

There’s a long, low-level discussion we could get into at this point about several “what is JEE?” questions and lines of thought, like:

• The ball and chain (or “excuse”) of backwards compatibility
• Tools making things “simpler” (not my cup of tea)
• What parts of JEE people actually use? (now we’re talkin’!)
• How do implementations of JEE effect complexity
• JEE’s many Red Headed Step Children

But, we’ll skip that for another time if you, dear readers, are interested. I’m sure other people will take up many of those topics as well.

Avoiding the Wile E. Coyote Anti-Pattern

There’s enough maneuvering room for JEE to apply the breaks and avoid spilling over the CORBA cliff. We advise Sun along these lines almost every chance we get: essentially it boils down to (a.) recognizing what users/developers want, and, (b.) giving it to them as fast as possible.

That’s key advice we give to everyone in this day and age. Sure, we might get The BigCo excuse, or “The Committee Excuse” in the case of JSRs, from everyone, including Sun. I roll my eyes every time I hear it — often, only in my head to be polite. But, I’ve liked what we’ve been seeing coming from Sun and, more importantly, the Java/JEE community recently. My belief that they can “turn it around” is still in wait-and-see mode, but I’m far from writing them off yet.

That is, my warm-and-fuzzies are still OK in the Java/JEE world.

BIG Disclaimer: Sun a client. In fact, they referred me to Rich Seeley for the followup article.

Technorati Tags: burton, dynamiclanguages, j2ee, java, jee, platform, redmonkadvice, simple, soa, sunw