LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
print Printable version 
Most Read Latest News Blog Resources
Kapow automates website data retrieval
Kapow Technology's Web Data Server 7.0 can be used to create modules that navigate through...

COBOL’s future lies in the clouds
After 50 years of use in businesses, COBOL is still lingering around mainframes. But the s...

Oracle's Fusion 11g lays groundwork for ERP platform
Fusion's components are standards-based and integrated, but some abilities are lost if non...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

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
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading