Bruce Tate's Blog

Why the JCP will do the right thing by JDO 2.0

"Bring out your dead!"

Early this year, the JDO 2 expert group submitted the JDO 2.0 draft to the JCP Executive Committee, and requested permission to deliver a reference implementation. This is the standard process defined by the Java Community Process. In a startling reversal, the JCP executive committee did not accept the public draft.

"Bring out your dead!"

On the surface, to many on the committee, that may have seemed like a good idea at the time. The overwhelming sentiment of the executive committee was that Java needed only one common persistence specification, and the new persistence specification defined by the EJB expert group (for JSR 220) should fill that role. After all, how many ways of doing object relational mapping do we really need? And hasn’t JDO been all but dead, anyway? You can almost hear the Monte Python voices in your head, with the JCP expert group driving a cart full of carcasses, yelling "Bring out your dead." And on that cart, you can plainly see the festering bloated carcass of the elephant …

"I’m not dead yet."

Only, the whiny, little voice of JDO wouldn’t go away. Just as she’s being loaded onto the cart with the other Black Bloat victims, she shouts “I’m not dead.” In truth, hundreds of JDO customers are probably calling Sun as we speak. The reality is that if you couldn’t make entity beans work, and you wanted to do ORM with a standard API, then you were writing JDO. She just won’t shut up:"I feel happy!" But shouldn’t those JDO-zealots just die in peace, and let the executive committee lob just one more body onto the cart? I mean, what could it hurt?

"I’m feeling better."

Well, that depends on your perspective. Think of the customers who actually like JDO. Certain implementations do things that other frameworks just can’t. Solar Metric’s Kodo is much easier to manage than any of the EJB alternatives, or Hibernate, for that matter. You’ve got GUI tools that will monitor the execution, and help you tailor your caching strategy, or manage your eager/lazy scenarios. Versant’s JDO has an excellent user interface, making visual mappings much easier to create. So let’s assume that you’ve got a good reason to use JDO. You trusted the JCP when they accepted the first JDO standard. You may have turned your back on some proprietary solutions to pick a safer standard.

"Well, can you hang around a couple of minutes? She won't be long."

Now, just assume that the JCP votes down JDO 2. What do you do? Your situation has suddenly become much riskier. If you’re a JDO vendor, the rug has been neatly pulled right out from under you, partially by your competition. If you’re a customer, your vendors have been damaged, and you either lose maintenance and progress, or you must adopt a proprietary framework. If you’re the decision maker who chose JDO, you’ve lost credibility.

And what’s the alternative? It turns out that the EJB 3 expert group is supporting EJB 2 style persistence in name only. That one is a dead API. And right now, there is no credible standardized alternative! You’re really looking at late 2006 before you see any EJB 3 implementations in sufficient numbers. So you can go with a proprietary solution, a dead API, or you can bet on the JCP executive committee to actually adopt the combined persistence spec in JSR 220, in a year or so.

"He must be a king, He hasn’t got (expletive deleted) all over him."

Which brings me to the main point. Did you ever wonder what happened to the drivers of that cart? I mean, they’ve got to wheel this thing through all of the death and the germs, and get death splashed all over them. So here’s the real question. How many bodies can you safely handle before you’re effectively a walking corpse? This is why I think that the JCP executive committee will accept JSR 243 at the next vote. If they don’t, they lose credibility, and the confidence of the community that they’re trying to support. And ultimately, that path will lead to death.

"Bring out your dead!"

Comments

• Another good Monty Python metaphor...the JCP Executive Committee are really the Knights that say, "NI!" They want you to bring them a shrubbery! But not too tall. Or wide.
  
  A vote down on the JDO 2.0 specification looks, at best, an attempt by some of the competation to crush competitors or self-serving interests. Take a look at some of the "Nay" votes from the committee. Oracle? Their ORM is toplink. Plus they have their J2EE EJB container. IBM? Websphere EJB line. JBOSS? All about their EJB container. BEA? Their EJB container. SAP? Too much invested already into EJB...supporting a new JDO standard will cost SAP far too much if customers demand support of it in SAP.
  
  If this is kept up, why even bother using the executive comittee anymore? Hibernate's already an example of this...it doesn't follow the JDO or EJB specifications. And Hibernate is doing great without the "help" of a JSR. Apache has their ORM project, yet they stated to let the market decide. If the committee so choses to deny JDO yet again...don't be surprise if Java technology frameworks & standards will become a thing of the past, and every software vendor will go rogue (standards based, but better!) once again.
  
  Want standardization? Want one company to tell you what the technology solution is every time to your problem? Then you want to develop on .NET, not Java.

  Posted by: phlogistic on February 22, 2005 at 10:34 AM

• A lot of technologies are doing just fine without being rubberstamped by the JCP.

  Publish the code, the specs, the compatibility tests, get your process out in the open without all that confidentiality business, and non-free software traps, and then, if JDO 2 is any good, the market would actually have a chance of deciding for or against it, no matter whether it's got JCP's brand all over it, or not.

  I don't understand what the big fuss about JDO 2 being voted down is. Just fix it, or make it possible for others to fix it, and it will sort itself out, if its worth it.

  cheers, dalibor topic

  Posted by: robilad on February 22, 2005 at 11:02 AM

• Standards encourage the development of supporting tools.

  I agree with dalibor that technologies don't need the JCP stamp to survive, but increasingly they do need design and run-time tool support to remain relevant. Note Bruce's comments regarding SolarMetric's Kodo: It's the GUI management and diagnostic tools that elevate it over Hibernate (in Bruce's opinion).

  I think this is why the JCP matters to the rank-and-file Java developers.... You may be able to convince your management to use Hibernate based on it's technical merits, but that might be the wrong decision if it turns out that Hibernate is more expensive to maintain, tune, and monitor then an EJB3 or JDO2 commercial product. It's not about the merits of a single product, it's about the whole ecosystem of products (and the JCP stamp tends to drive those ecosystems).

  Currently, Hibernate and Toplink have their own O/R mappings, and GUIs have been written to support each product individually. With EJB3 persistence, the O/R mapping GUI should be decoupled from specific EJB3 implementations. I am hoping that JDO2 survives and will be able to share the same O/R mapping tools.

  Posted by: johnreynolds on February 22, 2005 at 12:27 PM

• Sure, but you can only standardise on something people writing the code want to standardise on. If some software manufacturer thinks that they don't need a standard, than those vendors that really do want one, could submit a different JSR for the subset everyone agrees on, if they really care about the JCP stamp, a la JDO 1.5. Or they can go at it alone, as a JDO-NG alliance, and so on. If the resulting 'rogue' JDO2 is good enough, and marketed well as a successor to JDO, then the ecosystem of products around it will arrive, not least due to the lack of a rubberstamped alternative from the JCP.

  There are lots of possibilities, unless the licensing arrangements around JDO2 are of a kind that forbids participants from 'forking' with what's already there.

  For example, the rejection of the Mobile Game API, JSR 178, in 2002, has not led to people abandoning mobile gaming using Java; quite to the contrary. A year later, another Java gaming JSR was withdrawn, and it didn't stop people from developing games in Java, either. Eventually Sun finally ended up doing the right thing and opened up JOGL and its sister projects. while there is a JOGL JSR, it has been happilly dormant since years, and noone seems to care about it.

  cheers, dalibor topic

  Posted by: robilad on February 23, 2005 at 05:08 AM

• 
  JDO is dead for political reasons. That’s good! JDO should be terminated for technical reasons also. Here is why:
  
  Good object persistence APIs are non-intrusive. You just have to change the Database#store() method from one vendor to the next and you are done. A modern refactoring IDE will do that for you on any application in seconds. Accordingly the value of a “standard” on how the #store() method is called is ~zero. You run no risk if you use a proprietary solution.
  
  The most work and value that needs to be put into application persistence will go into writing code that queries the database. This is where a standard is badly needed to make persistence layers interchangeable. Hower this is where JDOQL is flawed most, a conglomerate of Java-Code-as-Strings, very bad to read, write, maintain, debug and refactor.
  
  Here is how JDOQL looks like:
  

  Query q = pm.newQuery (Employee.class, “salary > sal”);
  q.declareParameters (“Float sal”);
  q.setOrdering (“salary ascending”);
  Collection emps = (Collection) q.execute ();

  
  Here is how typesafe object querying should look like:

  Query q = database.query();
  q.from(Employee.class)
  q.where(“salary”).greater(sal).orderAscending();
  Collection emps = (Collection)q.execute();

  
  Notice that strings are ommitted at all costs. The last remaining string “salary” is due to a Java deficiency to access fields in a refactorable way. Here is an RFC to improve this.
  
  Some more arguments against JDO can be found on my blog.
  
  Please stop JDO !
  Let’s do it right.
  --
  Carl Rosenberger
  Chief Software Architect
  db4objects Inc.
  http://www.db4o.com
  
  

  Posted by: carlrosenberger on February 23, 2005 at 05:27 AM

• Carl, I could say that the JCP gives JDO a chance to right some of the mistakes made by the first iteration of JDO, and with customer-based experience rather than around a round table...like the string-based version of JDOQL added to JDO 2.x. But a tit-for-tat JDO debate here would miss the point of the blog. There are no perfect persistence solutions out there: products or specs. You could hammer similar holes in all of the existing solutions. For example, I

  Posted by: batate on February 23, 2005 at 06:49 AM

• Not sure why that cut off. Take Hibernate. I like it, and often use it. But sometimes, it lets me down. I often want more professional error messages, more complete mapping support (like that in JDO 2), and better management.

  Posted by: batate on February 23, 2005 at 06:58 AM

• roliad, good post. I do think that sometimes, the barrier to entry is too high for some specs. In those cases, standardization can help foster competition. I think that's been the case with JDO. But I'm not a blanket supporter of the JCP by any means. Lea's tools for concurrency, good. Log4j debacle, bad.

  Posted by: batate on February 23, 2005 at 07:00 AM

• Batate,
  the new string based querying in JDO 2.0 uses plain SQL, right?
  Now that's just like saying "Our querying approach was wrong, let's step back and specify nothing at all."
  
  We do need an object-based standard for querying and it has to omit strings at all costs because:
  - String typos are not checked by the IDE.
  - Automatic refactorings are not available.
  - Modular construction of queries with delegated method calls is much more difficult than with a clean API.
  - Strings consume more ressources in the app library than necessary.
  - Strings need time to get parsed.
  - Strings can be subject to injection attacks.
  
  As long as JDO has been around, it was difficult for yet another object querying standard to evolve. I am sure that we will see such a standard after JDO is finally gone.

  Posted by: carlrosenberger on February 23, 2005 at 08:16 AM

• You really want to get into a tit-for-tat debate, don't you? I tend to think that string-based query languages are easy to use, but a good spec should have a pluggable query language, no?

  Posted by: batate on February 23, 2005 at 08:42 AM

• I'm not particularly impressed with JCP's performance.

  For example, the core platform specifications, the Language and the Virtual Machine specifications have not been maintained *at all* in the last couple of years, despite numerous language and class format changes.

  The JCP never stepped in to force Sun to fix the problem of Sun locking in the platform more and more with unspecified changes to the language and the vm with each release of J2SE. Now the Class File Format JSR is recheduled to Mustang, so it may see the light of day in late 2006, but J2SE 5 is already turning those non-standard extensions to the Java-platform into a de-facto standard.

  A lot of the J2SE API specifications that come out of the JCP process are mediocre at best, and a certain amount (Swing in particular, but internationalization is quite bad, too) is ridiculously bad. It's taken more than 5 years to *not* specify what HTML 3.2 tags are supported by which swing widgets, for example. RTFEditor API spec? A joke. Calendar? StreamTokenizer? All have essentially useless specifications.

  These classes are part of the core API, so there would have to be a good, precise specification for them, if the JCP was functioning as advertisied, or these classes, and the language and VM changes should not have made it into J2SE. But the trouble is, that the JCP does not work as advertised. For example, the specification of the generics changes, JSR 201, is officially the 'J2SE 5.0 Development Kit'. That's obviously not a specification, that's an implementation of a specification. And the JCP did nothing to stop that sort of nonsense from happening.

  The JCP is a great idea, that's unfortunately executed poorly in the cases I'm familar with, i.e. the core plaform specifications and APIs. And that's what's undermining the credibility of the JCP as a standards body.

  cheers, dalibor topic

  Posted by: robilad on February 23, 2005 at 08:47 AM

• And it would be worse if it wasn't for doug lea and the ASF. :)

  Posted by: robilad on February 23, 2005 at 08:53 AM

• Carl, I don't want to get into a tit-for-tat debate, but your assumptions and comments in deriding JDO are simply wrong: Carl>>"The most work and value that needs to be put into application persistence will go into writing code that queries the database." What? Most developers I've worked with spend a fair amount of time writing code to query, but also spend alot of time to create, update and delete objects. Writing queries in JDO, especially JDO2.0, are not that hard. If you have to spend more than a few minutes writing the query code that you list above, you need to read some docs and learn the "JDO way." Carl>>"You run no risk if you use a proprietary solution." Spoken like a true developer. Even if you just need to do a quick refactoring using Eclipse, there are many nuances between any persistence framework implementation. What the standards buy you, well maybe not you, but the person/company you work for, is reduction of risk, both short term, and long term, on betting your software on a proprietary solution. Yes, I too would like JDOQL to be more like your second code example, so it can be more easily refactored/understood using a modern IDE. But again, it ain't that hard to begin with, so is not a show-stopper. "Carl Rosenberger Chief Software Architect db4objects Inc." hmmm. Looks like you're an object database proponent. I've recently worked with JDO, Hibernate, and a leading commercial OODBMS. Each one of these persistence tools has their pro's and con's. But I can tell you from experience I would choose which one to use in this order: First: JDO, Second: Hibernate, Third: OODBMS.

  Posted by: prpatel on February 23, 2005 at 01:15 PM

• prpatel wrote:
  >First: JDO, Second:Hibernate, Third: OODBMS
  
  The whole point about creating a "standard" for object persistence is that it should allow you to exchange implementations.
  
  If JDO would not be as technically flawed as it is, Hibernate would endorse it and we would also. Then you could write your application once and test which implementation provides the best performance, the lowest cost, the least memory consumption, the smallest database file, the best longterm-security of a healthy vendor...
  ...whatever you would need.
  
  I wonder what "your experience" is base upon. There is no such thing as a best database. It completely depends on the job that needs to get done.
  
  Object databases excel because of their very tight coupling to the objects in your application. That directly leads to:
  - maximum navigation performance
  - minimal ressource consumption
  - maximum development productivity
  - best handling of complex class hierarchies

  Posted by: carlrosenberger on February 23, 2005 at 02:25 PM

• Inheritance rulz. ;) But navigation of known relationships is usually only a very small part of the problem. Thus, the war's over. Relational databases won. (Twilight zone... OODBMS vendor speaks out against JDO.)

  Posted by: batate on February 23, 2005 at 02:54 PM

• Relational databases won the battle for enterprise data warehousing, no doubt, and indeed relational databases work best for ever-changing new applications, using new views against an outdated large legacy system with hundreds or thousands of tables.
  
  However there is a new database war, the war for devices.
  
  Tradionally small devices were programmed in C (or other "hardware" languages, the automotive industry uses OSEK for instance).
  
  With todays cheap processing power and with the recent improvements of virtual machines, Java and C# become the best language of choice, even for small devices. And guess what: There is even enough computing power to run some database engines. This is where object databases will be dominant in the future.
  
  ...but performance is everything and the systems for sure
  - do not want to parse strings (JDOQL)
  - be deprived of the ability to move objects freely between databases because of the design flaw to have a reference to the PersistenceManage in every object (as JDO does)
  - need the ability to run code in non-persistence mode, without routing every field call through to the database because the class was enhanced (JDO)
  
  Indeed, it's funny, an object database vendor ranting against JDO instead of teaming up to fight relational databases...
  
  ...but JDO simply is not a match for us, where we see a giant market and success for our product.
  
  --
  Carl Rosenberger
  Chief Software Architect
  db4objects Inc.
  http://www.db4o.com

  Posted by: carlrosenberger on February 23, 2005 at 04:36 PM

• So does db4objects follow any standard set forth by a development committee, or did it "go rogue" and has its own unique API? :)

  Posted by: phlogistic on February 25, 2005 at 11:12 AM

• They did the rigth thing!!!!! Last night JDO 2.0 passed the Reconsideration Ballot, with no votes against and 3 Abstains (IBM, Oracle and JBoss). http://www.jcp.org/en/jsr/results?id=3078 Congratulations!!!!!!!!!

  Posted by: jdavi on March 01, 2005 at 02:06 AM

• By golly Bruce, you were right!

  http://www.javalobby.org/forums/thread.jspa?threadID=17504

  Looks like folks in high places are listening.... even the nay-sayers simply abstained.

  Posted by: johnreynolds on March 01, 2005 at 07:04 AM

• Nice article! It's interesting, is it possible to improve this calling cards store or free advertising website using JDO 2.0. I think it's hard to do this.

  Posted by: adelante on October 02, 2007 at 02:26 AM

• Sure, that's interesting sounds but I don't believe that JDO 2.0. is fit for International area code directory or Digital SSL certificate service.

  Posted by: kabil on October 02, 2007 at 03:21 AM

• wow power leveling wow powerleveling wow power leveling wow gold wow items feelingame.com wow tips Most Valuable WOW Power Leveling Service wow power leveling faq cheap wow power leveling wow power leveling wow powerleveling wow power lvl

  Posted by: rinimade on December 24, 2007 at 05:04 PM

This work is licensed under a Creative Commons License.