Do We Really Need the JCP?

By Allen Holub

December 15, 2004 —

The two interesting pieces of news of the past few weeks are Sun’s open-sourcing of Solaris and Sun’s creating a new Java-persistence community-process group by melding together the EJB and JDO efforts. These two events play off each other in interesting ways.

My outsider view of the Java Community Process is that it doesn’t work. All the good technology that’s come out of the process was good technology when it went into the process. Someone came up with something useful, built it, deployed it in real applications, and then put the technology into JCP because it seemed so useful that it would benefit the community.

Most of the other Java-related technology that I use on a daily basis—Eclipse, Hibernate, JUnit, Log4J—started out the same way, as a tested tool that was built for real applications. The authors of these tools never saw the point in handing control over to Sun, however, and I can’t say that I blame them. Hibernate didn’t become accepted because it was built by renegades; it was just better than JDO. Even now that JDO 2.0 has played catch-up, why should I go with a JDO Hibernate clone whose APIs are essentially untested in real applications?

Once any technology becomes widely used, it sets a standard, of course. Hibernate is the standard persistence technology right now, so what’s the point of yet another JCP committee churning out what will undoubtedly be a bad standard? I might buy the notion that Hibernate could be improved or extended by the people who actually use it, but I can’t buy the notion of a competing “standard” created out of whole cloth.

Sun, of course, wants control of the “official” persistence standard, but that argument doesn’t hold much weight. It’s not as if “official” standards like EJB, SQL, HTML, JavaScript and so on have made it possible to write portable code. Either nobody follows standards—the business reasons for not doing so are too compelling—or the standards are so bloated, inconsistent and imprecise that everybody can implement a different subset and claim to be conforming. Java succeeded not because of Sun’s iron hand, but because programmers understood the issues and didn’t use the nonstandard variants.

Moreover, bad standards are destructive. Just look at created-by-committee junk like EJB and JSF. I personally believe that EJB has been responsible for the failure of more companies than almost any other single technology. EJB is too expensive at every level. The servers themselves, the learning curve, the time required for building and debugging EJB code—all these cost too much either in dollars or effort (which, ultimately, translates to dollars). Nonetheless, companies jumped onto the EJB bandwagon precisely because Sun was pushing it. EJB was the official standard.

This thinking is counterproductive, of course. Companies used EJB even when the technology was absolutely inappropriate, and they often used the technology inappropriately. I’ve seen entirely too many EJB applications that did nothing other than send entity beans around using RMI—probably the world’s least efficient way to access a database. I don’t buy the “if they knew what they were doing, they wouldn’t do that” argument. Well-thought-out technology doesn’t let you hang yourself in this way.

For a small Web app, direct JDBC calls to the database can work just fine (let the database server do the transactioning, failover and connection management). Wrap the JDBC in a “factory” layer, and you have the option of going to something else in the future if you need to. Similarly, messaging is often a much better solution than EJB for interprocess communication. (Message-related beans are a kludge—a desperate attempt on the part of the EJB folks to keep themselves relevant.)

You get the idea. Many bad systems that didn’t need or leverage EJB were built at the cost of many millions of dollars, and many of these systems were so complicated that they never worked at all, much less worked correctly.

That’s the danger of bad standards.

So, in the news we have Sun open-sourcing Solaris—a robust, tested, nonstandard technology—possibly setting a standard by doing so (a good thing). We also have Sun cobbling together a committee to wrest control of persistence away from open-source standards like Hibernate (a bad thing). I could support welcoming Hibernate into the JCP, but creating yet another competing technology is divisive and (I hope) an effort doomed to failure. The last thing we need is another bad standard.

Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design. Reach him at www.holub.com.

Share this link: http://www.sdtimes.com/link/28308

From the Editors: Election should shake up JCP Rod Johnson has the right ideas for opening up the Java Community Process, and he may be able to prevent the language from being overtaken, assuming the JCP cooperates. Also, Microsoft's cloud computing efforts are more open and flexible than Google's, and that's the way cloud services should be.

JCP enters general elections phase Four seats in two committees are on the line as the next round of elections in the Java Community Process begin. Intel and Sony Ericsson are among those running to hold onto seats they already own.

Rod Johnson on a mission to open up JCP Following his election to the Java Community Process committee, Rod Johnson explains why the governing body should be more transparent and less complacent. He also defended the approval of the OSGi spec as a Java standard, saying that the group should welcome outside contributors to Java.

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST