I am, I am happy to admit, a novelty junky. I am comfortable using new tools and have been quite comfortable deploying customer-facing applications with unproven (to whom are these things ever "proven" anyway? As a profession we gave up on mathematically provable software before I even started programming) tools or libraries. As an ex-coworker put it once, "if the technology isn't actually ready yet, you tend to go help build it." I land in the early-adopter camp of the technology curve most of the time, and it treats me well. All of that said, Allen Holub's recent article made me cringe, really hard, because, I believe, it conflates two different problems in an effort to prove a (quite valid) point. The early-adopter segment, which Allen is speaking from (and he knows a lot more than I do), and in which I lump myself, does not represent the profession, not by a long shot.
Quotes like, "Hibernate is the standard persistence technology right now," are crazy. Hibernate is the standard persistence technology for the tragically hip. Heck, it may be passe for the tragically hip already -- I think JDBC is coming back into vogue. Retro, you know?
The reigning gems of hipness which have passed from chic to fashionable seem to be Hibernate, Spring, Webwork, and Jetty. All are wonderful technologies, none of which can be remotely called "standard technologies," however. The interesting bit here is that they have been designed for people who are relatively smart and competent developers. Spring in particular is a fine tool in the hands of a skilled programmer, and an out of control band saw in the hands of the incompetent.
Servlets are a standard technology. Struts is a standard technology. EJB is a standard technology. JSP is a standard technology. JDBC is a standard technology. The Apache Web Server is a standard technology. Heck, even Linux is a standard technology now, despite its politics. A standard technology is ubiquitous, and is rarely fashionable *.
This throw-away stab at EJB, "I personally believe that EJB has been responsible for the failure of more companies than almost any other single technology," is potentially the scariest part, though, as it melds so nicely into the fashionable view that most people won't even pause to think about it. He is right, because he throws in, "than almost any other single technology," but the implications of the statement are completely off. Companies don't fail because of EJB, or any other technology, they fail because of mismanagement or natural disaster. Mismanagement may be, "we are going to use EJB," coming from someone (management, armchair architect, a junior programmer with a Wombat.com Distinguished Engineer title) and the development team not knowing enough to say "that is inappropriate for this application, here is why...", which is really a human resources policy (failure) based on hiring incompetent people who are less expensive.
The interesting bit here, in my opinion, is that a big part of what the EJB movement has been about is taking less skilled developers and helping them create reasonably complex and reliable software. That is great marketing for app server vendors: "spend lots on this product which makes cheap programmers as productive as expensive programmers and you won't be dependent on those expensive and finicky programmers anymore." Corporations are very risk-averse and putting your eggs in one basket (a top notch programmer) is risky. One really good developer is much more expensive, and much harder to replace, than a college grad with a "this solves 80% of the problem" application server (note the magic 80%). J2EE is 4GL for the backend.
I take Allen's point to be that EJB is a standard created from the ether, and supported by a consortium of companies interested in prolonging their various business models more than raising the state of the art. The implication is that the rest of the JCP is the same thing, with James Gosling cast as Darth Vader (he was a great hero, now he's evil, but we all know he'll turn good again).
The JCP is a political battefield for J2EE vendors as well as a standards body. Some gems treat it as a standards body, others as a tool for creating barriers to entry. I suspect that is simply an unpleasent reality that is tough to change. Most of us want to make money, and some ways of doing so (some very profitable ways) do not involve solving problems, but rather prolonging them. I do think the JCP is relevant, but not all JSR's are (JSR220 is quite relevant, despite my jabs). The resistance that has been put up any type of standardization for AOP is a great example of good things in it. I suspect in another five years that Jonas Boner will be a spec lead for an AOP JSR, but as anyone seriously involved with AOP will tell you, it ain't mature enough to standardize, yet.
Allen seems to feel that once something is mature, it is the standard, and making a formal standard is pointless. Every RDBMS vendor has a slight variation on SQL, ever C compiler its extensions. You can say "this is where it varies" though. If you know GNU C, and need to write Microsoft C, finding the differences is easy (they're documented). Having the standard lets you do that. The JCP has some nasty licensing terms associated with its standards, which makes this tough (you cannot partially implement a JCP standard and still be allowed to use its name, except in JDBC, for instance). The JCP is wonderfully inclusive though (not as much as the IETF) and is getting better about back-room specs. Standards are useful, and making them is painful. The JCP pain is certainly less than the twitches I see from people who were involved with SQL though ;-)
*) I think the (standard technology) Apache Web Server is becoming fashionable in Java circles, mostly because people are (re) discovering that you can use Ruby or Python with it to get Java-level or better performance because, imagine this, all the infrastructure heavy lifting is in C optimized for performance (httpd, postgresql, fastcgi, memcached), and all the application logic is in a nice high level scripting language optimized for expressiveness, go figure.