Robert F. Kennedy once said, "There is a Chinese curse which says, 'May he live in interesting times.'" The enterprise Java space is "interesting."

Not too long ago, folks like Bruce Tate, Gavin King, and Rod Johnson were pushing lightweight frameworks such as Spring and Hibernate, and there is still a lot of true innovation going on with AspectJ, Spring, Hibernate, WebWork, JBoss (method invocation handlers), and more. This lightweight POJO revolution shook the enterprise Java world.

Having endured building applications with EJB 2.x and Struts, using Spring and Hibernate was like a breath of fresh air. Development was easier and less time was spent working around the limitations of the platform.

J2EE has good ideas, which inspired a lot of additional ideas. This evolution led to innovative and productive practices outside of the JCP.

The JCP has had some very good JSRs, but you have to admit there have been some real stinkers.

EJB in general, except as a learning experience, is generally viewed as a failure. The real problem was not just EJB but the misapplications of EJB. This was widespread as it was promoted with the J2EE Blueprint, not to mention the misapplication of JTA, and more features of J2EE. Not to say that applications can't benefit from JTA and EJB, it's just that many, many Web applications don't need them.

EJB 3.0 is much better than EJB 2.x. If you compare EJB3 to an older version of EJB, EJB3 is a boon; however, if you compare EJB3 to Spring and Hibernate, it stinks.

The related OR (Object Relation) Persistent API does not have a criteria API specified; any persistent API that does not define a criteria API is not finished.

The AOP support in EJB3 is broken. EJB3 has a method interceptor, but no pointcuts. In addition, the method interceptors are declared and imported with class-level annotations. This effectively tightly couples the class to the method interceptors that decorate it (Can you smell the bad odor?).

Rod Johnson mentioned thess same problems about EJB3 Method Interceptors at a recent Java enterprise conference (in his talk "Are We There Yet") and went on to mention many limitations on the @Resource style of DI, the absence of FactoryBeans, post processors, Constructor Injection, lists/maps, and a lot of the features Spring developers know and love are just missing. The EJB3 JSR members did not look at any of the prior art in this space and created their own limited version of what was already available.

I've heard some call EJB3 a dumbed-down version of what is available by using Spring and Hibernate. "EJB3 is Spring and Hibernate's stupid cousin" is frequently echoed.

After three years of deliberation, the JCPs delivered EJB3, which is inferior to de facto standards. Many parts of EJB3 are a big step backward from Spring, and, to many, EJB3 is broken. As Bruce Tate says about EJB3: "Don't make me eat the elephant again."

It's not just the persistent API and the AOP support that's broken in EJB3, it's also the random use of annotations, another misguided effort. The idea of annotations is good. The implementation of the annotations ruins some of the principles of the POJO model; namely, it ties your Java classes through a compile-time dependency to the standard API you're using and to any value-add annotations the vendor supports. Now why would vendors like this approach? Hmmm...I wonder. (Hint: Follow the money!)

In that question lies the real problem with the JCP. The JCP is heavily influenced by vendors that have "business need(s) or corporate agenda(s)." Parts of the enterprise Java community is innovative, parts stink, but there are many parts.

Strangely enough, RoR, which is currently being championed by Bruce Tate among others, is a safe haven for Java developers who are sick of vendor-driven APIs. In short, vendor-centric JSRs, Struts, and EJB have driven many a developer, who just wanted to get things done, to RoR.

My feelings on RoR is, been there done that, no thanks. Don't get me wrong, RoR has a lot of good ideas, but bad tool support. For me and many other Java developers, scripting languages are a step backward for large apps.

Geert Bevin, the creator of Rife, sums up my thoughts on the subject nicely in a recent e-mail he sent: "RoR is one of the best things that could happen to the Java community because at least alternative approaches and meta programming are now getting the credibility they deserve. Technologically, though, I think that RoR is nothing special." An issue with Java is a wealth of riches, so much wealth that you can get lost. Conversely, RoR seems like a one-trick pony. Choice is a blessing and a curse.

There are good Java competitors to RoR, such as Rife and Seam (and many others). The way the Java competitors of RoR do things is better than RoR, and it's Java so you get code completion, refactoring support, debugging, and more. Java can attack the space that RoR addresses quite well, in fact, much better than RoR. As Gavin King recently wrote me: "...Seam is (not) exactly focused on the same kinds of problems that RoR is targeted at, but I would say that it does compete very nicely in that space."

The reality is, we need more independent voices in the JCP. To be successful, it has to become less vendor-driven.

At least we now have independent folks on the JCP like Hani Suleiman. Hani is a self-proclaimed independent voice of the JCP. Hani, a very popular blogger, petitioned Java developers to vote him into the JCP Executive Committee for J2SE/J2EE.

"If you're a JCP member, vote for me...! ... I'm the only nominee who is motivated purely by improving Java. Everyone else is there out of some business need or corporate agenda. Stick it to the man!" -Hani Suleiman

Of course, many of us are very happy to have such an independent voice, an independent developer who doesn't have any vested interest in any of the JSRs. But wait...

Hani also did an interview in which he states: "I am the CTO of Formicary, which ... (has a) portal product, Epix (a JSR-168 based Portlet Portal), and alongside all that I also work for IronFlare, which makes the Orion application server, and through that I represent them on a number of expert groups and that is the real work that I do."

Hani works for companies that produce a portal server and an application server that support EJB. IronFlare was contracted by Oracle to develop their J2EE application server (the second one, the good one). Hani is a vendor. If you read Hani's blog, he frequently speaks out against AOP, POJOs, and lightweight frameworks, not to mention bashing competitors like JBoss, etc. It also appears there has never been an EJB he didn't like. And, this is our "independent voice." Strange times indeed!

The question to Hani, which echos a popular U.S. TV commercial: "But sir, aren't you the man?"

Even so, many feel that Hani will defend the common developer against vendor's interests and that he will bring a new perspective to the JCP, while ignoring that Hani, pleasant chap though he is, is hardly an independent voice and often lashes out against innovation while supporting a broken specification like EJB. One thing for certain, Hani never pulls his punches.

Hani recently told me: "The JCP isn't really a technical body; it's a lot more about process and IP issues." So a big part of the JCP's work is about protecting the individual vendor's IP issues. Where is the focus on making developer's productive like RoR's focus? By and large, RoR does not beat out the Java community in tools and ideas, but on their focus on developer productivity. Contrast this to the JCP's focus on vendor profits. We need to focus.

We do live in interesting times in the Enterprise Java space. We have RoR-inspired frameworks and vendor-driven JSRs. We have Bruce Tate, a former promoter of lightweight Java frameworks, become an advocate for RoR. We have Hani, one of the chief opponents of lightweight POJO-based frameworks, get elected to the JCP Executive Committee.

On the other hand, we have great frameworks and ideas such as POJOs, domain-driven design, Spring, Hibernate, Rife continuations, Rife meta programming, JSF, Facelets, Seam, and AspectJ. It is time to promote true innovation wherever we find it: JCP or innovative projects. Avoid standard APIs and frameworks that don't make sense.