Skip to content

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.


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

Wile E Coyote

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: , , , , , , , , ,

Categories: Enterprise Software, Java, Programming.

Comment Feed

7 Responses

  1. I still need to read that report, but I think the fundamental principle that JEE is bloating is correct. It's insane to me that by this stage, scripting or *at least* and interpreter (Groovy, BeanShell) hasn't become integral. It's also amusing that all of the really slick, low-code APIs (think JDom vs. Xerces) come out of small incubators.

    I still think Java has a lot going for it, but simplicity is not a feather in it's cap (was it ever?).


  2. I agree. Bloat is due to the curse of backwards compatibility. Java and JEE will never cut fat just in case someone is using that fat.
    Cutting fat would give crazy cool simplicity, but as Bloch pointed out in his API design advice (here, among others), once you add public code in a “public class,” you can’t ever take it back.
    The cure for this when I do and think about JEE is to just ignore all that crap. That’s not a good cure but it’s what people did for years, ignoring EJB.
    As you point out, that means that you have to start using “all of the really slick, low-code APIs” which makes you think, “am I really doing JEE?” Perhaps not: you may just be treating JEE as a runtime/container, for JTA, servlets, JSPs…that is, treating JEE as a buffet to pick and choose from, just like you’d do from Jakarta, Codehaus, etc.
    And your JDOM vs. example points out the Red Headed Step Child point of discussion. It’s simply crazy when Java and JEE ignores existing de facto API standards in favor of newly created things. For example, I’m not really sure why Hibernate wasn’t just sucked into JEE. Well, I know why — vendors on the JSRs didn’t want to — but it seems like reinventing the wheel.
    Open sourcing Java and JEE might help cure things like that. Of course, in the gloom and doom open source scenarios, it just causes more bloat. Hmmm…something to think on.

  3. Java EE programers want two things: transactions and scalability

    They also probably wouldn’t mind some “productivity” with that 🙂

    On the dynamic languages, Sun is doing interesting (IMHO) experiments such as the server-side scripting Phobos project.

    Great podcasts btw (both of them). Thanks.

  4. Hah! 😉 Of course, you’re right, Alexis. I didn’t mean to exclude that. Those are just the two, you know, “primary” things that always jump out at me about JEE coders.
    I’ve heard good things about Phobos but haven’t checked it out hard-core yet. I’ll have to short-list it. Maybe I can get a briefing from Sun.
    Thanks for the kind words on the podcasts.

  5. NOBODY expects the Java Inquisition!

    “Java EE programers want two things: transactions and scalability” …and tools…. Our *three* wants are transactions, scalability, and tools…and an almost fanatical devotion to the UML…. Amongst our weaponry…are such elements as transactions, scalibility, tools, UML, and… nice IDEs – Oh damn!

    AnonymousJuly 19, 2006 @ 8:59 pm
  6. Don’t forget XML. The Java Inquisition also employs the might XML in it’s arsenal of devices.

Continuing the Discussion

  1. El Rey de Café

    As tbray mentioned, Sun hired “The JRuby Guys” today (rather, announced that they had). We were discussing the announcement in #redmonk (you were there, right? If not, check it out), and most folks seemed quite happy with it. I, of…