Java Data Objects (JDO) 1.0 Proposed Final Draft now available


News: Java Data Objects (JDO) 1.0 Proposed Final Draft now available

  1. After much anticipation, the Proposed Final Draft of the Java Data Object (JDO) 1.0 specification is available. The Java Data Objects spec defines a mechanism for persisting the state of plain java objects in a truely transparent fashion. Designed to integrate seamlessly with J2EE app. servers, JDO is seen by many as a superior alternative to entity beans.

    Check out the unofficial (but the real) Java Data Objects Homepage.
    Download JDO 1.0 Proposed Final Draft.
    Home page for JSR 11: Java Data Objects.
    Read Java Data Objects vs. Entity Beans thread on

    Threaded Messages (24)

  2. The JDO approach to object persistence is at least much more consistent than Entities.

    But JDO and Entity EJBs should not be alternatives in the first place.
    JDO has still to prove itself and it hasn't have time to address some issues in the spec like relations between objects and inheritance also is not addressed from an information modelling perspective.

    Of coures JDO is a brandly new effort and it is a tough proposition to have transparent object persistence.

    As far as it got it really looks very promising especially in terms of cutting development cost.

    But the main point that I want to make here is that it is a waste of time and energy to have two persistence models.

    If Sun has the courage to dettach the persistence problem from the other problems that are succesfully adressed by EJB (security, transactions distribution), you'll and join the two in an unitary effort, then I guess a lot of issues could be solved.

    I see that JDO specification is trying really hard to position itself as a lower level thing that will allow EntityBeans to be implemented as JDO objects.

    I'm not sure if this is only politically correct or the right thing to do.

    Anyway, if you put the problem the way Floyd put it ("JDO versus Entity" ) then you can only hurt the JDO effort.

    Entity Beans have too much money investment (with little return though) for them to be replaced by JDO, so the best thing would be to unite the two efforts.
  3. Are there any implementations of JDO available currently.
  4. The JavaOne 2000 presentation by Heiko dot Bobzin at poet dot de on JDO sounded like they are close to or in production.
    I dont speak German (I think their Website is German) seems to be the site.
  5. There seems to be a project at Sourceforge:
  6. Castor as well:
  7. What the fuss is all about?
    Why even bother with all this persistence frameworks?
    Why not just go with OODBMS in the first place if one just can not live without objects?

    Plus, if one goes relational way, one can develop framework that would allow for efficient application development without business object based O/R mapping. Tools like Delphi, Magic, PowerBuilder and others are the testament to it.

    Same kind of framework can be developed for purely object-based approach.

    O/R mapping does not give you that much from the development point of view. One needs lots of UI mapping and other utility code to do the actual development. And this is what Sun should really concentrate on.

  8. Artem,

    First of all you should know that I am the last guy on this site who wouldn't advocate relational model, my friends here have had enough of me on this subject.

    And thank God, Delphi is not a "testament", it's still a model to follow and pretty much live and kicking butts. Boy, I would love to go back again to Delphi.
    But Delphi is not an OR mapping tool, and I'm glad it is not.
    It has a very good component library that allows us to take advantage of the relational model, but has no facility for OR mapping.

    That's the same approach taken by Microsoft, they just don't care about OR mapping problem, they provide a very handy way to access relational database (OleDB,ADO), provide transaction managent with MTS and that's it, if you want to think "everything is an object" you're on your own.

    I guess they are very smart to stay away from this thing.

    But in the Java community, you just can't ignore the O/R problem, Java folks are too much entrenched in the OO.
    Here many folks think of a database just as a bin where you throw your objects and expect to get it back by id.

    And OODBMS are cool, except it's not very easy to query informtation, and CIO/CTO will just say NO we go with Oracle.

    So there is a need for JDO and JDO tries to be a solution.
    It still has a way to go but it looks like a good start.
  9. I thought, that this site is all about seeing through the hype and common misconceptions and about finding sensible alternative ways of doing things. That is why I brought this up.

    There are lots of companies that do not have CTO and CIO to force people to use tools they do not need. There are also many companies that choose most suitable technology for their solution regardless of the market perception.

    So for people like that there should be a variety of options open besides RDBMS and legacy systems. And if these other options are better then why not give them a try on the larger scale?

  10. OODBMS have still to prove themselves.

    They are successfull in niche applications like providing repositories for CAD/CAE, but they have yet to prove themselves in building scaleable business systems.

    This should be enough to convince you why CIOs/CTOs are reasonable to request that RDBMS's be used for business aplications, whithout going any further into technical details.

    For you and me as developers the ODBMS might look like an interesting and challenging proposition, but this is not enough from management perspective.

    So RDBMS's in general are not tool that you don't need, but I consider them the lesser of evils, and, let aside having not supporting objects in an easy way, they are quite capable and trustworthy.

    Who ever proved that ODBMS's are better and in what regard ?

    If you say ODBMS's are a better option this would indeed qualify as hype , it was THE HYPE in the early 90's.
  11. OODBMS have still to prove themselves.

    > ...

    Well they do have to do something that is for sure!
    On the one hand, one can visit sites of any OODBMS vendor and see examples of big systems implemented on top of them. Systems like GeoCities, Southwest Airlines, Sotheby's...
    But on the other hand, one does not hear about any OODBMS vendors, while hearing about IBM, Microsoft and Oracle on almost everyday basis.
    So may be it is just marketing thing?

    Anyways, I am not huge proponent of OODBMS myself moreover I think in most cases pure relational approach suffices just fine.

    But I can not deny what I see clearly!
    And that is that Sun is basically moving in the direction of OODBMS with all recent changes in the EJB specification. And because they would not admit to it resulting EJB model gets so much criticism from all sides.

    One just has to look at the latest development in the field of caching, query language, dependent objects and such. And one will immediately see that EJB container is going to be an OODBMS.

  12. Well,

    You can come up with examples I'll come with more numerous examples but it doesn't prove anything; do you want to make a visit top to look for OODBMS (you'll see tpc is not complex enough, but that proves that OODBMS don't superced relational databases as they say in marketing materials that RDBMSs are "legacy"), anyway it's off topic.

    Do you want Sun to dictate to everybody else to use OODBMS ?

    This would hardly solve anything, they dictate a lot already and it ain't good (see Entity beans).

    It is enough that a lot of what they come up is very much against basic things in relational model, and therefore implementations over an OODBMS should perform better if they are indeed capable.

  13. Do you want Sun to dictate to everybody else to use OODBMS ?

    No I do not want them to do it.
    But they do it anyway, without admitting to it.
    And this is what I am talking about!

    There are many things, including J2EE, MySQL and IBM IMS, which do not have TPC benchmarks but people still successfully use them.

  14. Guys,
    If you would like talking about ODBMSs you better do it here
    here and try to be more concrete, otherwise somebody who trying to read very long posting chain wouldn't have enough endurance to read it up to the end..

    I don't know what is you ODBMS experience, but I guess that you have some misconceptions with it.
    well, I tried to find any adequate ODBMS benchmarking specification but found no one. Again this is not only about ODBMS.
    Even when we talk about pure relational world, where are SAP, SAS, NCR, Adabas benchmarks? I think that’s not because all of these ones could show mediocre results, quite the contrary(NCR, Adabas).

    Costin, do YOU ever tried to build something not trivial with ODBMS? The truth is that you never have the luxury to trust any benchmarks or press/marketing hype: the only way to be sure is to try it yourself - build a prototype, and you'll see..
    Many thing which are too boosted from well known 'brands' are in fact not so good as they seem to be. While there are a lot of better(a bad word, I know) things which are on their own, not in the MAINSTREAM. I could give a lot of examples here.
    But why the vast majority succeeds with Oracle and Microsoft? In fact you can succeed building the same system on most any production platform, and it will work anyway. The problem is how to reduce efforts and time and raise the efficacy.
    Being software engineers we should state all alternatives and choose the best one on basis of technology, but not only vendor stock indices and brands( Of cause when you have a lot of legacy software and information to maintain you do not have a luxury to choose). But when your CTO / CIO force you which way to go without any consultations it leads company to the vicious circle.
    Another issue to consider is "network effects" that Daniel Weinreb have mentioned. But look at XML. It is still a new thing, especially comparing to ODBMS. So why XML Database Servers seem to have more propagation? Again because of marketing hype .. works!
  15. Basil,

    It's not the case to start a flame war here.

    XML databases are nonsense and they will dissapear soon.
    OODBMS's are a good solution for certain problems but they are not a panaceea and they don't supercede relational systems. Features sets are divergent and no one can replace the other.

    If you really want to know what hype was, in the early 90's, based on the extraordinary suceess of C++ every research article and every marketing material from OODBMS's predicted that relational databases were legacy and would be replaced by OO ones, and you can see now it was market hype indeed.
    When Oracle/MS/IBM publish TCP benchmarks, it's not marketing hype it's a concrete fact that happened.

    You can tell stories about irrelevance of TPC benchmarks, but nobody will believe you, TPC benchmarks do have their rellevance.
    They are not the absolute measure, but they have to be taken into considerations.

    My ODBMS experience is simple, I downloaded a couple few years ago (Jasmine, Poet) and didn't like it.
    Nor the OQL language.
    Nobody is perfect and nobody has the time to study all the technologies in the world.

    So even us the developers have to take into considerations marketing hype or market trends, but the diference is that we can check it out for ourselves.
    You can tell no matter how many storioes about Oracle,SQL Server,Sybase,Informix,DB2 but you can't say they are not capable or they don't perform well.

    Quite the contrary, and OODBMS have to prove something by real facts (TPC - why not ?) if they are to be trusted to replace RDBMSs.

    By the way, Adabas and NCR do have results posted at TPC.

    The problem debated here was not which one is better (OODBMS or RDBMS) but the strange idea of Artem that
     Sun should mandate Java persistence technologies (JDO, Entity EJB) to use OODBMS only.

  16. The problem debated here was not

    > which one is better (OODBMS or RDBMS)
    > but the strange idea of Artem that
    > Sun should mandate Java persistence
    > technologies (JDO, Entity EJB) to use OODBMS only.

    Well, Costin, that was not my idea at all.

    I was saying exactly the following:

    Sun is in fact moving in the direction of turning EJB server into an OODBMS.

    Again, I did not say that "Sun should mandate Java persistence technologies (JDO, Entity EJB) to use OODBMS only.".

  17. Costin,

     I never sad that ODBMS will ever supercede RDBMS, or that ODBMS is always preferred, I only meant that ODBMSs deserve more attention than that is paid to them at the moment and RBDMS is not the only way to go.
    ODBMS will beat any app. server in providing persistent entities and entity specification is moving towards providing the same services (but on the top of RDBMS).
    ODBMS relationships model is what EJB 2.0 relationships are trying to be,
    OQL is far superior to EJB QL. Strictly speaking, EJB QL being a pretty enhancement to simple finders is not query language at all. The only advantage of Entity bean against persistent object is that all major services are declarative.
     Anyway I think M$s favorite “I did it my way” will not become Sun’s too and JDO will be appropriately integrated with EJB model.
    IMHO there is no other way to go for Entity EJB model.
    As for JDO, I'll wait until there will be mature implementations from any ISVs.
  18. Basil,

    I agree with you.
    But I would rather preffer Entity Beans being taken out of the EJB spec and united with JDO.
    EJB is already a 500+ monster, and EJB should only be concerned with distribution and propagating transaction and securoty context,things which it got right until now.

    Persistence is too tough of a problem to expect that EJB will get it right even the third time it tries.

    Yes, youre right the app server will tend to look more and more like OODB, but I don't want to use an OODB until I feel the need to, much less to pay for functionality that I don't use, and instead of having monolythic architectures like we have now we should have pluggable services.

    That's another reason to make persistence an effort separate from EJB.
    And in any case we shouldn't have two disparate efforts.

  19. Castor's JDO implementation is different from Sun's JDO spec. They are similar in name only. Check the FAQ on for details.
  20. No, Castor JDO doesn't comply with the SUN's JDO specification.

    Although Castor JDO carries very similar goals as SUN's JDO, it has been developed independently from the JSR.

    Although it is not impossible to shape (perhaps "hammer" is a more descriptive verb) Castor JDO into the SUN's JDO specification, there are several major technical differences which make it unfavorable to do so. Castor is RDBMS centric. Each persistence object loaded by Castor is locked. Locks in Castor are observable, meaning that locks may not be granted because of timeout or deadlock. On the other hand, the SUN's JDO hides details about locks.

    Internally, Castor JDO maintains a single copy of lock (and cache) for each active persistence object for all transaction. SUN's JDO specification implicitly requires a copy of cache per object per transaction. SUN's JDO also implicitly require a bytecode modifier which Castor doesn't require.

    Castor also provides other features, such as key generators, long transaction support and OQL query which cannot be found in SUN's JSR.
  21. Orient Technologies will provide a JDO implementation of your Orient ODBMS engine.

    A beta-version will be on-line at days...

    Bye, Lvc@
  22. Versant has a good implementation for there ODBMS calle Judo. Well at the moment it's not in production state, but from my point of view it's only a little step forward.<br>

  23. PrismTech have a Java Data Objects (JDO) preview implementation available for download on our website at:
  24. Well, I have built business systems with ODBMS (moderate scale), and I've seen others build large-scale systems with them (i.e. OOCL, Florida Power & Light, etc. all use GemStone/smalltalk).

    My impression is pretty similar to what a lot of RDBMS proponents have been saying all along:

    1) ODBMS have never really tried to be full fledged DBMS'. They don't cater to the administration and maintainance of -data-, they cater to programmers.

    2) ODBMS are really "database toolkits". They give you the tools to build your own access paths and storage structures. This is heaven in the hands of experts, hell in the hands of novices.

    3) Because of the above point, ad-hoc querying is generally difficult to do. Especially traversing over collections.

    4) ODBMS are mainly a backlash against the limitations of SQL and current relational products, not the relational model itself. The relational model can (and should) be able to do everything ODBMS can do while preserving traditional benefits, and perhaps inspiring a new age of dynamic object languages.

    5) Nevertheless, in the Real World, relational databases are probably the most flexible / maintainable way of storing -data-, and object databases are the highest performance and easiest to maintain way of storing -application specific data structures-. Hence the need for object/relational frameworks like TopLink, JDO, PowerTier, etc.

  25. I agree with your point that RDMBS should be able to do the things that OODBMS give developers- they have just been resistant to change. They have left it up to the "Object" people to figure it out and talk to their databases in the old fashioned SQL way just like the COBOL programs in the beginning of SQL. If the database vendors - well I guess there is really only one, maybe two if you don't live in the Redmond world - had taken this more seriously they could have made life a lot easier for OO developers - Java, smalltalk, C++, any language. So, it is up to Sun or Java tool vendors to make this happen.

    I think part of the problem here is that the industry is too divided between "Object Oriented" thinkers and "data oriented" people. Anyone who worked in an old shop based on flat-files knows the data management nightmare that was solved by the RDBMS. It seems that the OODBMS are almost a step back to that- inaccessable, no central design. You had to write a program just to get a list of records with a simple search. Data was not well thought-out and redundant data was EVERYWHERE, spread over hundreds of datafiles, each with their own file layout. Think about how important it is for a CIO/CTO to know exactly where his customer list is, and how it links to the orders list, etc. And he can even go in with a quick and dirty query tool and browse the data. And you are going to ask them to give this up to store it in an array of blobs? That is not going to happen.

    I guess the main problem is that of perspective. I can't tell you how many times I have heard an OO person say "just persist the object". This just shows how they view the storage mechanism- only from the viewpoint of their Class they developed and nothing else. But enterprise data management is about open, centralized, cohesively designed data.

    So, all this ranting aside, this brings us to the situation. Really, really smart OO developers who can do powerful things with their tools, and the corporate interests of data management. Who is responsible to bridge the gap? Up until now, it has been a hodge-podge of half-baked tools and alot of unnecessary sweat, creativity, and hacking by developers. Does anyone who has done any significant work with an enterprise-scale and complex database think that Entity beans are a well-thought out attempt at O/R mapping,or at least abstraction? IMHO they fall incredibly short, and portions of the spec sound as if they were written by first year CS students. They are just now debating the idea of dependent objects( which were dropped from EJB2.0 pfd). Duh - objects linked to objects? what a concept! - a little late ? come on guys. we are well down the road of enterprise development with java - and we are still having these discussions about persistance such as Entity vs JDO? I don't know if you are aware of it, but RDBMS have been around for alot longer than Java and J2EE. Its not like this is a new problem to popup -like Micro Edition/wireless. And yet we are responsible for architecting and delivering enterprise applications (hopefully using java) and this fundamental issue of database integration/persistence is still a question and not a "known quantity" yet. Please don't tell my project sponsors.