J2EE Obsolete? Really?

One of the various functions we as IT Industry Analysts play is to identify and highlight trends within the technology industry. Pattern recognition, in other words, this involves the monitoring of a variety of communication channels – including news, analysis, gossip, opinions, and virtually anything else of potential importance to try and distill out a series of seemingly disconnected datapoints a cogent, understandable set of conclusions. Connect-the-dots, in other words. I could riff about how this essentially makes us Phippsian editors, but I’ll leave that for another time (and entry).

Instead, I’d like to highlight a series of thoughts that I believe are tied together by a common theme and encapsulate a growing discontent with Java as a platform. Here are a few salient excerpts:

1. Peter Yared – 9.1.2003

If Java does not meet these requirements, what does? Apparently what is needed is a language/environment that is loosely typed in order to encapsulate XML well and that can efficiently process text. It should be very well suited for specifying control flow. And it should be a thin veneer over the operating system.

Most Linux distribution in fact bundle three such languages, PHP, Python, and Perl. PHP is by far the most popular, Python is considered the most elegant (if not odd), and Perl the tried-and-true workhorse. All three languages are open source and free. (link)

2. Peter Yared – 9.1.2003

So perhaps the next generation Application Server is to have NO Application Server in the middle of everything. This is the “donut”, peer-to-peer architecture where there is nothing in the middle, versus the “muffin” architecture, where the Application Server sits in the middle of everything. (link)

3. Miguel de Icaza – 7.15.2004

The problem with J2EE really is that it became very, very academic and the complexity of all these perfectly designed systems in schools does not necessarily map when you have deadlines and all kinds of other things. (link)

4: Richard Monson-Haefel – 10.15.2004

“Customers need to be wary of whom they ask to provide their J2EE stack and they should also consider some of the alternative frameworks,” report author and Burton analyst Richard Monson-Haefel told internetnews.com. “We’re not saying that companies should abandon J2EE, but we recommend that they turn over the responsibility to the open source world while the major vendors focus on what we’re terming as a J2EE super platform.”(link)

5: Phil Wainewright – 11.18.2004

Some combination of XML web services grid/mesh/fabric/bus, once we all get through the experimentation stage and begin to agree on what works best, is going to obsolete every previous generation of integration middleware — and that includes J2EE application servers. (link)

6. Jeff Schneider [read his blog BTW, it’s excellent] – 11.23.2004

1. J2EE is a bloated set of deprecated patches.
2. Static Java objects and dynamic XML collide
3. Contract first programming make “languages less important”
4. If you’re in an SO world, you might as well pick an SO friendly language
5. J2EE was designed to scale across a VM that sits on a multi-CPU box
6. Oh, Sun owns Java and J2EE, and what do you know… they sell multi-CPU boxes
7. Rip & replace Intel/AMD/Linux boxes are fast, cheap and reliable
8. LAMP is here to stay.
9. The growth rate of transactions inside an enterprise is significant.
10. The last-gen computing method will hit an ‘economic breaking point’. (link)

7. Phil Wainewright – 11.26.2004

It was interesting to see that a couple of comments noted that the ‘text-pump’ concept described by ActiveGrid’s Peter Jared is exactly what Microsoft has designed Indigo to do. On one count, that’s interesting because Microsoft people are not stupid. If they pursue a concept, you can be sure that it has a lot of merit. On another count, it means there is now a race in progress. Can ActiveGrid and other open source pioneers perfect this technology before Microsoft does? (link)

Strong words (maybe even fighting words for Java advocates) from some very smart folks. And I agree with them, to some extent. I personally made many of these same arguments myself in the Scalable Java Development webinar presentation I gave a few weeks ago (get the deck here in PPT format), using the same quote from Miguel in the process. Truthfully, apart perhaps from Yared’s comments, you’ve heard these arguments before, maybe even made them yourself. Java’s too hard, too complicated, overkill for small projects, etc, etc.

Well, I think with some exceptions, that’s still largely the case all these years later. Sure, with advances such as JSF and some of the new toolsets like Java Studio Creator or IBM’s Rational Web Developer the Java development story is better than it was, but it’s still easier for many to pick up Perl/PHP/Python than Java (one of the IBM execs told me last week that his 12 year old son is becoming quite proficient in Perl).

The question I have is simple: what’s wrong with that? Stupid question on the one hand, but I find much of the commentary (though not, please note, the commentary from the folks above) around the languages and platforms to be based on a flawed – in my view – assumption that a single platform can be all things to all developers. If there is such a language/runtime combination, someone please let me know – it’ll make my job as an analyst a lot easier.

Now if you think I’m dealing Java a backhanded compliment by saying that it’s ok for it to be not easy to use, well, you’re partially correct. It is too hard to use and develop in, no question. But I do believe that the computing problems Java is designed to solve, i.e to run scalably and reliably across a host of different platforms, brings with it an overhead. In some areas were these very problematic (Swing, anyone)? Sure. At the same time, Java has long been employed with real, mission-critical workloads, and earned a reputation as a platform that while complex – scales very well. The problem, I believe, came when Java was branded as the solution to every computing problem. It’s not that now, and certainly wasn’t pre-JSF and J2SE 5.0.

What does all this mean to J2EE as a standard, and the vendor answer to that – the application server? Well, a few of the above quotes paint a very gloomy picture for the product category. And inasmuch as enterprises are beginning to realize that their building’s conference room booking system is not likely to see eBay-volume, I’d agree. J2EE’s days as the end-all and be-all of corporate development are likely over – if that were ever true in the first place. Instead, we’re seeing scripters take their rightful place alongside of Java developers, and .NET (and Mono) developers – hell, even COBOL developers. Frankly, between open-source commodization of platform functionality and a corrosive pricing attack from Sun and others, some erosion of application servers as a revenue source was inevitable, regardless of whether or not an alternative approach emerged.

But what I don’t see is Java being kicked out of the spaces where it’s an established, proven performer. After all, not everyone who bought WebLogic or WebSphere was simply going with the crowd. Not everyone was applying EJB’s to departmental web applications. My colleague and I have chided most of the big platform players for mistakenly treating every account – even the small ones – as if they were GE or Merrill Lynch. But as it turns out, GE and Merrill Lynch are in fact real companies, with real needs (and real money, importantly). And more often than not, those needs mean Java. I also don’t buy that – loosely typed or not loosely typed – the LAMP stack, as good as it is, is intrinsically more aligned with a services based approach (hold the flames, we’re running it).

I also think it’s very interesting that in the consumer space, services like Flickr, Paypal and others are running into some of the problems that Java is designed to address. Are they all going to, en masse, migrate to Java? Not likely. But some might. Of course that may mean Tomcat rather than WebSphere, but that’s what choice is all about.

The fact is that Java was expressly designed to solve problems that are far more relevant today – in a world that is increasingly network and service oriented – than they were 4 or 5 years ago. As a result, I find it very difficult to believe that the standard and the software platforms that serve it are facing extinction at the hands of a new category of software described as a “text pump.” I’m certainly interested in what Yared’s ActiveGrid has to offer, and will be speaking with them later this week, but I’m immensely skeptical of any technology that claims to replace another [1]. It simply doesn’t work that way. After all, as my colleague points out, CICS is a text pump that’s been around for a long time.

So while I agree with many of the objections to Java, and am following projects like Mono with great interest, I just can’t support some of the uber-aggressive conclusions that people are reaching. Extraordinary claims, after all, require extraordinary evidence. Haven’t seen that yet, though I’m willing to be persuaded.

[1] According to our logs, a fraction of our overall traffic is coming from OS/2 machines. It’s nearly impossible to kill off a platform – just ask the zSeries folks who’ve faced “mainframe-killers” year after year after year – and lived to tell the tale.

Update: Bad link fixed