JDO Specification 0.92 and reference implementation available


News: JDO Specification 0.92 and reference implementation available

  1. The Java Data Objects (JDO) 0.92 specification has been released, with a limited functionality file-based reference implementation. JDO is an object-oriented interface to data stores such as relational or object databases. JDO allows truly transparent object persistence, and may one day be used as a replacement to EJB entity beans.

    Visit the JDO homepage.
  2. May as well start what could be a hot discussion....

    Here is an 'opinion'.

    "Entity beans are redundant. I don't see much point in having them. The JDO stuff should be made a first class part of J2EE, i.e. I should be able to get to them directly without an entity bean. and entity beans per say should be removed from the spec."

    Anyone agree or disagree
  3. Billy,

       Are you referring to removing entity beans from the EJB spec or the JDO spec?

      If you are referring to the JDO spec, then I whole heartedly agree. Using JDO as a persistence mechanism behind entity beans is ridiculous. It forces you to execute a remote invocation to an entity bean which will then do a local call on a JDO. Direct Session bean to JDO interaction is much better.

      If you are referring to the EJB spec, thats a tough call to make. Although I believe JDO access from session beans "services" to be a better architecture than using entity beans, there would be severe political and practical ramifications of deprecating entity beans in favour of JDO. None of the vendors have JDO implementations, they would likely kick and scream in favour of entity beans to protect their existing investments.

  4. I'll take the bait, it's Friday. I say "Entity beans be damned! Remove them from the EJB spec."

    If no one uses entity beans remotely (few will argue the contrary, I believe) then what advantage do they hold over session bean + JDO?

    A) Entity beans have finder methods etc but with the advent of the new OSQL like language in 2.0 then the only purpose of finder methods is to prevent ad hoc queries in object space, i.e. restrict the set of queries possible to get at JDO objects, not necessarily a bad thing possibly.

    B) Security and declarative transactions are two other things that come to mind but seeing as you can't get to JDO except through a session bean in the "entity bean free" scenario then I believe you're covered in this respect anyway as the session bean has these attributes also.

    I think future applications may be comprised of very few entity beans and the rest of the persistent objects being JDO based. The only reason any entity beans are here at all is because the developer was forced to do this as JDO objects are not accessible directly.

    Taking this to a (il)logical conclusion, we'll end up with message beans, session beans and JDO (implementing object persistence). I don't see where entity beans fit here, I don't see what we're losing by doing this other than a simpler, cleaner runtime environment.
  5. Let me make the discussion a bit hotter ...

    "Let the entity beans be damned". Your damn right.
    As Floyd put it, this a very tough political issue, not only for Sun who put them there, but also for many people who recommended them and who implemented them.

    The problem to be discussed is: should we "jump" into JDO ?

    Somehow I connect efforts in the object persistence area with a funny thing that happened years ago.

    A computer science teacher objected against a student's use of an algebraic trick to solve a programming problem (it was supposed to be an illustration of recursion).
    Of course, student's solution was cleaner and ran faster.
    "Wrong - said the teacher- we use computers so that we are finally able to get rid of the hairy mathematic."
    The student was of course speechless.

    Isn't it legitimate to ask why do we need to get rid of SQL ?
    Anyways, the guys who do want that, they can happily do it to themselves, but if they want to full others into jumping in their boat, they'd better present themselves with a running product, a nicely written project, and last but not least numbers (transactional throughput, performance overhead and so on).

    Ideally, they should be able to submit a result to the new TPC-W benchmark, which one has to agree isn't a big deal of a project to write (unless you're constrained by bad technology).

    After all that, we'll ask them to share with us their vision in form a new and hot Java spec.

    But meanwhile, I'll stay skeptical and continue programming the way I see fit for my humble needs.
  6. all I can do is agree wholeheartedly with respect to the replacing EJB issue. What I wonder about, however, is why this is coming up now. There have been good OO/relational mappers out there for quite a while, and JDO is just a standard API for that. I was never able to figure out what benefit would result from remote accessibility to business objects (which are most often fine-grained).
  7. Christian,

       The reason that this is coming out now is because finally there is a standard API that the industry could rally around. You are right, there were always good object relational mappers, but these were always proprietary. Different vendors could not offer their "own" cocobase, it would always be the cocobase engine and Cocobase company making profits behind the scenes.

       As a standard, every vendor can implement JDO, thus bringing true choice to developers.

  8. What about the high memory consumption by JDO?
  9. Hi Floyd,

    I agree with your opinion about Entity Beans. There are several articles and experiences (some of my own, too) which clearly describe and prove the shortcomings of the entity bean model.

    Implementig a Session Bean, which encapsulates a Persistence Manager, seems to be the right choice:

    a) Just one Session Bean to configure and deploy!!!

    b) Scalable Persistence Manager

    c) Transactions (JTS), Security, and all other infrastructure services

    There are several ORMappings available, already. Is JDO the best alternative? When I started reading the spec I thought it would be. But the I entered an area which gives access to a mine field: JDO Enhancer.
    I just can't believe why anyone wants to modify byte code! What about debugging ans all other problems with such an idea. There are better ways which are already available to use (Persistence Broke which use Java Reflection, Mappings via XML Descriptors, ...).

    JDO seems to be a good idea, which is followed by a bad design and implementation.


    Hartmut Wilms
  10. I wholeheartedly agree to that (Hartmot).

    Just to give a quote from log4j docs about some kind of equivalent "JSR".
    "Log4j is written by the people who use it daily, not by a committee. ".
    The same I think it's true about JDO.

    Hartmut said of a problem, there are others too, but I don';t think it's wise to discuss the technicvalities, because we have to trust those people that they had something in mind when they thought of bytecode modifiers, "everything should be persistable", another impotent query language and the likes.

    Probably there is debate in the commitee as there is within the EJB commitee.

    What is fundamentally wrong is the architecture of the process in this case. You have "let the engineers design the house" anti-pattern here.
    The people who are writing the specs will not have to suffer the consequences of what they design.

    So, I wish them best of luck, but for those waiting eagerly to get another bunch of papers from Sun, they all have my deepest sympathy.
  11. I think that's important to clarify what's JDO and how it interacts with EJB.

    JDO is a standard that allows to access data from any kind of data sources (be careful there are two other products with the same name, which are not compliant). This is done with the same semantic: the Java language. Currently a way to access data is JDBC.
    But it is relational oriented, it deals with rows from a table.
    With JDO no more rows in your java program, only objects. Of course, for a RDBMS it's implemented through a mapping engine (like Toplink or Cocobase).
    But you have to keep in mind that there are other kind of datasources: files, XML streams, ERP, mainframes, object databases.
    The same JDO program is able to run on top of a RDBMS, a XML storage manager, or an ODBMS.
    It's wonderful! If one datasource doesn't meet your needs chose another one. You don't have to rewrite your code. You just have to rewrite your data mapping files.

    I think that EJB specifications are gone in the wrong direction because they tried (with EJB CMP) to merge two orthogonal concepts: distribution and persistence (and it's against all what we learn in any good school).
    Entity beans are interesting if you want to distribute an object that has its own identity (not only a service). For that, like in CORBA, you need activation from a key, and a way to get/set the state from a datasource.
    Everybody here knows that it's currently (due to network limitations) stupid to distribute all the data objects as entity objects. (The intergalactic distributed object network is not for today ;) )

    JDO can be used as the persistent layer for EJB (either session bean or entity bean). This allows to avoid coupling between data model and distribution model. If you want to reuse the data model directly from a Servlet or through a 2 tiers java program, you can do it.

    EJB specifications should not drop Entity Beans (BMP), but they should keep focused on distribution and only distribution. They have to integrate transparently JDO.
    Let's JDO take care of the persistence.


  12. May be you should take a look to the object database technologies that already use byte code enhancement with success.


    They have evaluation version of their product (not JDO compliant) that will show you how JDO should work.
  13. I know about both of these products. We have already evaluated them. Besides, a Poet Evaluation IS NOT for free.

    Byte code modification works, unfortunately. It's ugly, ugly and ugly. Did you ever try to debug code after byte code modification??? What about all those beautiful features of SOURCE LEVEL DEBUGGING? Byte code modification is even worse than using preprocessors. That code can at least be debugged.

    There are ways of debugging code after byte code modifications. Versant states that they are working on an integration into IBM VAJ 4.0. They don't promise anything, nor do they say anything about WHEN - who dares to tell anything about WHEN concerning IBM VAJ???

    An integration into an IDE is very complicated and costly. Only a few vendors of IDEs will cooperate with persistence vendors and vice versa. Is your IDE allowed to play along???

    As you might have guessed alreay, I hate byte code modifications. There are much more beautiful and elegant techniques which are as efficient.



    PS.: After going over JDO spec again, I realized that JDO does not demand byte code modifications. That's just Sun's idea of an implementation. I have to admit, that I do not have the time to evaluate JDO in detail. So maybe the spec isn't that awful at all.