JDO 2.0 Public Draft Available

Discussions

News: JDO 2.0 Public Draft Available

  1. JDO 2.0 Public Draft Available (62 messages)

    The JDO Expert Group is pleased to announce the availability of the Public Draft of Java Data Objects, JSR 243. This represents the most significant milestone toward the release of JDO 2.0. The Public Draft is available for download at http://jcp.org/en/jsr/detail?id=243.

    The Public Draft Review is significant because it triggers the last required Executive Committee vote before actually building the implementation and finalizing the specification.

    A primary feature of JDO 2.0 is compatibility with JDO 1.0. Current users of JDO do not need to recompile their programs to run on JDO 2.0 implementations, and users can migrate their vendor-specific mapping metadata to the new standard without any program changes.

    JDO 2.0 aims to improve usability and portability of applications, with a few major features compared to JDO 1.0.

    • Significantly enhanced JDOQL that provides projections, aggregates, simplified programming of queries, and paging of results.

    • Standardized mapping of users' domain object models to relational databases.

    • Detached objects to simplify multiple tier (client, web server, application server) application programming.
    Since the release of the JDO 2.0 Early Draft in the summer, several enhancements have been made to the specification and to the strategy for building the Reference Implementation and Technology Compatibility Kit required by the Java Community Process.

    • A version of JDOQL that allows queries to be defined as a single string, used both in a program or defined in the metadata.

    • Simplifying the definition of identity classes that use a single value as the primary key.

    • Improving portability by making Map support required.

    • Improving usability by making the return type of queries be List instead of Collection.

    • Simplifying JDOQL by allowing automatic typing of variables and parameters.

    • Aligning detachment of objects with JSR 220. This will allow the same detachment programming model to be used with both JDO and the new persistence API being developed by the JSR 220 group.

    • Improving usability of fetch groups. Fetch groups are a performance enhancement that allows users to reduce round trips to the datastore by specifying which fields should be loaded into persistent objects when first fetched.

    • Improving object-relational metadata by providing for index, foreign key, and unique constraint definitions.
    JDO has been adopted as an open source project by the Apache Foundation. JDO will be developed in the Database top-level project, and will become a sister project to Derby and OJB. JDO will be developed to tightly integrate with Geronimo, Apache's open source Java 2 Enterprise Edition implementation. The JDO 2.0 API and TCK will be developed as Apache projects; the current JDO 1.0 API, RI, and TCK will be maintained in Apache as well.

    JPOX http://jpox.org will become the JDO 2.0 Reference Implementation.
    JPOX is a popular open source project developed in sourceforge http://sourceforge.net/projects/jpox/.

    With this announcement, Sun is expanding its commitment to the open source community. Apache, Sun, and the community can all benefit from the synergy created by developing JDO in open source.

    Threaded Messages (62)

  2. JDO 2.0 Public Draft Available[ Go to top ]

    The nice thing about JDO 2 is that it is an incremental improvement of JDO 1 based on feedback from users. The mature JDO 1 implementations already on the market do not have to be rewritten to support JDO 2. Users will not have to wait long for solid implementations of the final spec.

    Cheers David
    Versant Open Access JDO
  3. JDO 2.0 Public Draft Available[ Go to top ]

    JPOX http://jpox.org will become the JDO 2.0 Reference Implementation.
    Users will not have to wait long for solid implementations of the final spec.
    To coincide with the release of the public draft, JPOX has just released version 1.1.0-beta-1, providing more stability and additional JDO 2.0 features.
  4. jsr 220 compatability[ Go to top ]

    is there any planning to support the entity manager interface of jsr 220 (EJB3.0) to provide some compatability with it
    also why not to use the same syntax of the query language? do i need to care and keep up to date with 2 query languages came from the same comunity(jcp)?!!!
    last,why to care about the new jdo when ejb3 will support persistance outside the container?!!!!
    joe
  5. jsr 220 compatability[ Go to top ]

    Joe,

    I care about the new JDO because I have been using JDO 1.0 for two years and am looking forward to the new features. I suppose that if your project can wait until EJB3 has matured, then you could use that, but why wait when there is a robust, standardised ORM solution which works outside (or inside) EJB containers available from multiple vendors today? Dumping entity beans in favour of ORM, and creating a standardised ORM spec are both good ideas, and JDO provides both.

    Tom
  6. jsr 220 compatability[ Go to top ]

    last,why to care about the new jdo when ejb3 will support persistance outside the container?!!!!joe

    Because the new JDO spec is shortly to be published. Previews of it are already available in many commercial and open-source implementations. EJB 3 will not be out for a long time.
  7. jsr 220 compatability[ Go to top ]

    is there any planning to support the entity manager interface of jsr 220 (EJB3.0) to provide some compatability with it

    SolarMetric (makers of Kodo JDO, which powers TSS) is committed to supporting both the EJB 3 interfaces and JDO 2 interfaces and query languages. You'll be able to use the same object model with either interface, even mixing and matching within a single application. Other JDO vendors have voiced similar plans. But I don't think the JDO spec team is going to break compatibility with JDO 1 or otherwise degrade the JDO 2 spec simply for the sake of nominal compatibility with EJB 3. Where features align, the JDO team has tried to make sure semantics are compatible, but doing any more would just hurt the JDO spec -- not because the EJB 3 spec is bad, but simply because it would force the JDO spec in unnatural directions.
     
    also why not to use the same syntax of the query language? do i need to care and keep up to date with 2 query languages

    JDO already had a query language that thousands of customers use. As I said above, products like Kodo JDO will support both languages, but JDO isn't going to abandon JDOQL. Besides, JDOQL is trivial to learn, because it's basically just Java. For example, a filter for Employee objects might look like:
    "salary > 50000 && manager.empId == 10 && lastName.startsWith ('W')"

     
    why to care about the new jdo when ejb3 will support persistance outside the container?

    Because many vendors already support JDO 2 features, and the spec will be final soon, as opposed to a 2006 timetable for EJB 3. Because there are more JDO vendors to choose from. Because JDO 2 has features that EJB 3 lacks. Because choice is good. Some users will prefer the EJB 3 APIs, and some will prefer the JDO APIs. I think it's great that people will get to use what they feel most comfortable with.
  8. jsr 220 compatability[ Go to top ]

    Hi Joe

    Versant Open Access will support the JSR220 persistence API seemlessly alongside the JDO 2 API. You will be able to use both in the same application if you choose to. So our customers will be able to use the API they prefer. JDO 2 will likely support a much wider veriety of domain models than the JSR220 API and will be available a lot sooner. Dont wait for JSR220 to move to POJO persistence!

    Cheers
    David
    Versant Open Access JDO
  9. jsr 220 compatability[ Go to top ]

    JDO 2 will likely support a much wider veriety of domain models than the JSR220 API.

    What are the limiting aspects of JSR220 compared to JDO2?
  10. jsr 220 compatability[ Go to top ]

    Hi Jens
    JDO 2 will likely support a much wider veriety of domain models than the JSR220 API.
    What are the limiting aspects of JSR220 compared to JDO2?

    Entity beans must be concrete non-final classes vs JDO persists abstract classes.

    Persistent fields must either have getters and setters or be protected while JDO persists private fields.

    In addition to the usual String, int etc JSR220 only supports Collection and Set fields. JDO supports Collection, Set, HashSet, Map, Hashtable, HashMap. Others like List, ArrayList, Vector, LinkedList, TreeMap and TreeSet are optional. You will struggle to find an implementation that does not support List though. JDO also optionally supports arrays.

    JSR220 only supports collections of persistent classes. JDO supports Collections and Maps etc of Strings etc as well.

    JSR220 requires that the primary key be represented as field(s) in the class. JDO does not require this. Same story for the optimistic locking column.

    The philosophy of JSR220 is to persist POJOs that conform to a set of design restrictions. JDO persists just about any Java class. That is why JDO supports collections of Strings (because Java classes use them) and JSR220 does not (wrap it as an entity bean).

    These comments are subject to change as the JSR220 spec evolves.

    Cheers
    David
  11. jsr 220 compatability[ Go to top ]

    Half of this was plain wrong.
  12. jsr 220 compatability[ Go to top ]

    Half of this was plain wrong.

    Good. Now say something useful and tell us which half!
  13. jsr 220 compatability[ Go to top ]

    I'm not doing your homework for you. Ask your colleagues in the JSR-220 expert group.
  14. jsr 220 compatability[ Go to top ]

    Hi Christian

    I wrote that list of differences with the JDO and JSR220 draft specs in front of me and to the best of my knowledge it is correct. I may have misread or misunderstood something so please tell me which points are invalid and why.

    Cheers
    David
  15. jsr 220 compatability[ Go to top ]

    I don't have them in front of me, but are you seriously suggesting that JSR-220 persistence will not allow you to store collections of dependent values? Is that the early draft from June you are reading?
  16. jsr 220 compatability[ Go to top ]

    And... your "JDO does not need this" (id, version, etc.) statements are also true if you decide not to use bytecode processing and not to implement PersistenceCapable?
  17. jsr 220 compatability[ Go to top ]

    Our implementation (Versant Open Access) uses bytecode enhancement so I am not an expert on other techniques. However if you are generating subclasses or proxy classes surely you can easily add in fields for id and version?
  18. jsr 220 compatability[ Go to top ]

    And... your "JDO does not need this" (id, version, etc.) statements are also true if you decide not to use bytecode processing and not to implement PersistenceCapable?

    Christian, breath in, breath out, repeat a couple of times. I guess you're feeling better now.

    Let's try to have a reasonable discussion: all David said was that JDO does not require those fields in the classes. In the common scenarios, JDO can do without. In others, it may not. So this is about choice. Choice is good.

    He did not say that JSR-220 persistence was bad. He did not say Hibernate was bad.
  19. Hibernate and bytecode processing[ Go to top ]

    And... your "JDO does not need this" (id, version, etc.) statements are also true if you decide not to use bytecode processing and not to implement PersistenceCapable?

    Does anyone else find it odd that Hibernate developers are so vocal against bytecode processing while, in contrast, a significant number of their clients take advantage of it with systems like AspectWerkz?

    God bless,
    -Toby Reyelts
  20. jsr 220 compatability[ Go to top ]

    Hi Christian
    I don't have them in front of me, but are you seriously suggesting that JSR-220 persistence will not allow you to store collections of dependent values?

    I suggested that Strings be allowed as collection elements and this met very strong resistance.
    Is that the early draft from June you are reading?

    That and my recollection of mails on the expert group.

    Cheers
    David
  21. Attitude[ Go to top ]

    Christian:
    I'm not doing your homework for you.

    David:
    I wrote that list of differences with the JDO and JSR220 draft specs in front of me and to the best of my knowledge it is correct. I may have misread or misunderstood something so please tell me which points are invalid and why.

    Discussions like this make it very hard for me to ignore the personalities involved and focus on the technology issues. Thanks for taking the high road David.

    God bless,
    -Toby Reyelts
  22. jsr 220 compatability[ Go to top ]

    I'm not doing your homework for you. Ask your colleagues in the JSR-220 expert group.

    I am one of David's colleagues on the 220 expert group, and I believe that his list is entirely accurate. 220 has many months yet to evolve, but as of now everything he said is true, to the best of my knowledge.
  23. Why so hostile?[ Go to top ]

    Why do the hibernate people always react so hostile?

    Kees.
  24. Why so hostile?[ Go to top ]

    hi cube.
    I'm not a hibernate people, just one user who has been lost 2 years ago about which solution to use.
    My society spent too much money about it, one friend lost his job just because he has trusted commercial args and took the bas decision.
    I just don't want unexperiemented users to do the same mistake.
    As i said, we'll surely see more and more users satisfied JDO2.0 implementation and that's good because that means we'll finally have one BEST solution.
    What i can't admit is people saying "no" 2 months ago, then "yes" and finishing by "maybe", that don't help.

    Trust me i'm a cool guy ;)
  25. Why so hostile?[ Go to top ]

    I didn't mean you, persistent_user, but I got this
    nasty feeling of the posts of Christian Bauer.
  26. Why so hostile?[ Go to top ]

    trust me, i follow most of tss posts, we have 5 articles per weeks talking about JDO, i must admit that's too much.
    I have the feeling much articles are just here to have a "JDO" title on the homepage of tss.
    If we were having concrete informations, tutorials, benchmarks, ... but generally we don't know more....

    let's take an example:
    The philosophy of JSR220 is to persist POJOs that conform to a set of design restrictions. JDO persists just about any Java class. That is why JDO supports collections of Strings (because Java classes use them) and JSR220 does not (wrap it as an entity bean).
    i don't care about collections of strings... and about persisting other classes than POJOs!!! My domain model is composed of pojos, that's what i call an unusefull feature, but that's my POV maybe i don't understand what is a collection of strings and why i will have a better apps if i use it or when it should be usefull...

    So 1: obscure and probably unusefull features

    next, if you read all ORM related topic you'll see many lies about hibernate, and now about EJB3 that is not ended, so i don't understand why people are yet comparing it!
    And Christian is used to reply to tell the truth, and it seems he's busy today...

    let's proove by the example, as you probably know, Gavin King is also working on EJB3, we shouldn't find in hibernate 3 features not present in JSR220:
    Persistent fields must either have getters and setters or be protected while JDO persists private fields.
    i can persist private fields without get/set with hibernate

    In addition to the usual String, int etc JSR220 only supports Collection and Set fields. JDO supports Collection, Set, HashSet, Map, Hashtable, HashMap. Others like List, ArrayList, Vector, LinkedList, TreeMap and TreeSet are optional. You will struggle to find an implementation that does not support List though. JDO also optionally supports arrays.
    with hibernate i can persist list, map, array, set, and also bag which is very usefull. I have ordered and "non duplicated" collection interfaces, behind i can use a hashSet or hashMap implementation if i want... sounds like a lie no?

    JSR220 only supports collections of persistent classes. JDO supports Collections and Maps etc of Strings etc as well.
    proove me i need it

    JSR220 requires that the primary key be represented as field(s) in the class. JDO does not require this. Same story for the optimistic locking column.
    it's good to know about identity inside your pojo, i can be wrong, but it will be easy to "hide" the id property using bytecode processing.... you can do much fun and not critical and usefull features with such processing. The real problem is that persistance is a big thing, medium user will probably need many months to understand all features, if you had such "strange" feature, it won't help. I you communicate on it, user will think it is important: IT IS NOT ;)

    The philosophy of JSR220 is to persist POJOs that conform to a set of design restrictions. JDO persists just about any Java class. That is why JDO supports collections of Strings (because Java classes use them) and JSR220 does not (wrap it as an entity bean).
    already talk about this, but i don't know how i will model a serious oo rich domain model with all kind of classes. It is already complicated to design a resusable domain model with only Pojos...

    These comments are subject to change as the JSR220 spec evolves.
    no matter what will change, there'll always be strange args, this list is partially wrong, doesn't explain what is exactly behind the words, that doesn't help, trust me

    You may think Christian is rude, sometimes he is ;), i think he might be busy to say always the same things.
    Instead of wasting 5 minutes writing a superficial article, this guy has written a book to explain all about the orm problem... THAT IS USEFULL ;)

    i think i'm not going to make firends here... sorry guys
  27. Why so hostile?[ Go to top ]

    i don't care about collections of strings... and about persisting other classes than POJOs!!! My domain model is composed of pojos, that's what i call an unusefull feature, but that's my POV maybe i don't understand what is a collection of strings and why i will have a better apps if i use it or when it should be usefull

    If your persistent POJOs never have Collection fields that contain String elements, or never have any Map fields, then obviously persisting these field types isn't important to you. However, some people might use these field types in their persistent objects. David was asked for examples of domain models that JDO 2 supports and EJB 3 does not, and these are valid examples of that.

    The rest of your post talks about various domain model features in JDO 2 that David Tinker mentioned as being absent from EJB 3. You imply that David is lying because Hibernate supports the features he mentions. But Hibernate != EJB 3. Gavin is on the EJB 3 team, but so are representatives from Oracle, IBM, Websphere, SolarMetric, Versant, Xcalia, etc. The products of every one of these companies have proprietary features that are not in EJB 3. That's the way specs generally work: they define the most important functionality, and implementors then extend the spec with more features to differentiate themselves. I think you should read the EJB 3 draft spec yourself before you accuse anyone of lying. In addition to discovering that David was telling the truth, you will learn a lot about EJB 3, and you might give the spec team some valuable feedback they can incorporate into upcoming spec revisions.
  28. Why so hostile?[ Go to top ]

    So what?
    JDO isn't dead
    Hibernate != ejb3
    JDO 2.0 is better than ejb3

    but in many minds hibernate represents ejb3 implementation (or hibernate3.1 will).

    so what is the conclusion? people are lost and misunderstanding JDO, EJB and Hibernate, that's amazing!

    Will people stop saying this beta draft is better than this... at least wait final specs no? better wait first implementations.

    Is there a site dealing about all complete specs and comparing end implementations features?

    I knew an ORM comparision table (ugly but usefull)

    We should elaborate such a site and update it, refer it at each article dealing with JDO,EJB, Hibernate
    it would explain what is exactly behind each features.

    I'm thinking about users, we don't help them choosing a solution. I don't care other solution, i'm using hibernate and it works perfectly, all i want is to help other users. Please trust me.

    is this possible?
  29. Why so hostile?[ Go to top ]

    if you read all ORM related topic you'll see many lies about hibernate, and now about EJB3 that is not ended, so i don't understand why people are yet comparing it!

    There seems to be many statements of uncertain validity expressed in this matter. They include 'JDO is dead' and 'Hibernate is EJB3'. This is a highly-charged area where popular commercial, non-commercial, proprietary and non-proprietary products are competing.
    Gavin King is also working on EJB3, we shouldn't find in hibernate 3 features not present in JSR220:

    I don't see how this follows. JSRs are collaborations, not (hopefully) dominated by any one vendor or group. There are many highly qualified people working on EJB3, including JDO developers. Does this mean that you will find JDO features not present in JSR220? Very likely, you will. I would expect that all vendors of persistence mechanisms will provide their own value-added extensions. The difference is that with JDO 2.0, these are likely to conform to a standard.

    By the way, I also think you are confusing two things: EJB3 (a very broad specification) and the EJB3 POJO persistence mechanism, which is a subset. It's like confusing J2EE with the specification for servlets.
    JSR220 only supports collections of persistent classes. JDO supports Collections and Maps etc of Strings etc as well.proove me i need it

    I would say the opposite - prove why you don't! My experience is that Maps, other Collection types and Strings are fundamental to any object model. Why confuse and obscure things by having to include wrapper classes?
    It is already complicated to design a resusable domain model with only Pojos...

    Surely this is a good argument for the POJO mechanism getting in the way as little as possible, and giving you more freedom to design the way you want.
  30. JDO 2 feedback[ Go to top ]

    I just bloged it:
    http://www.sandrasf.com/adminBlog

    .V
  31. JDO 2 feedback[ Go to top ]

    I just bloged it:http://www.sandrasf.com/adminBlog.V

    Some comments:

    Who says Java developers don't create tables? Some do, some don't - depends on the situation. I'm sure there are many examples where Java developers are using a relational database (such as MySQL or PostgreSQL) as a convenient high-performance store for objects. We aren't all working in large organisations with DBAs.

    As for 'no business case for non-SQL DB', there are many vendors who would argue with that! One of the strengths of JDO is that it does not specify the kind of store.
  32. JDO 2 feedback[ Go to top ]

    I just bloged it:http://www.sandrasf.com/adminBlog.V
    Some comments:Who says Java developers don't create tables? Some do, some don't - depends on the situation.

    More importantly, why does it matter whether Java developers create the tables or not? How does that relate to the JDO 2 spec? JDO 2 standardizes ORM syntax. It doesn't matter whether the tables are created by the JDO vendor's forward mapping tool or are part of an existing schema.
  33. JDO 2 feedback[ Go to top ]

    Guys, Abe/Steve,

    I am willing to learn:
     How do I write a JDO v2 class that lets me access an existing schema?
    (part II is: How do I write a SQL string command to do a CRUD)

     I can't see it in the pdf or on the JDOX web site.

    tia,
    .V
  34. JDO 2 feedback[ Go to top ]

    Guys, Abe/Steve,I am willing to learn: How do I write a JDO v2 class that lets me access an existing schema? (part II is: How do I write a SQL string command to do a CRUD)

    Chapter 15 of the spec covers the basics of mapping a class to a schema with some examples. Chapter 18 is the definitive description of all metadata, including mapping metadata.

    SQL (as opposed to JDOQL) queries are covered in spec section 14.7. If you want to do any other SQL manually just grab the connection from the PersistenceManager and do whatever you want (section 12.16).
  35. JDO 2 feedback[ Go to top ]

    We aren't all working in large organisations with DBAs.

    HA! Quite right, I'm projectlead, DBA, spec developer and coder all in one. And no, it is not an tiny winy project. :-)
  36. How to provide JDO 2 feedback[ Go to top ]

    In your blog you ask where to provide feedback on the spec.

    That's easy:

    jsr-243-comments at jcp dot org (as per the JSR-243 web site at jcp.org)

    or

    jdo-comments at sun dot com (as per the spec's title page).


    Hope this helps,
    Oliver
  37. Since the release of the JDO 2.0 Early Draft in the summer, several enhancements have been made to the specification and to the strategy for building the Reference Implementation and Technology Compatibility Kit required by the Java Community Process.
    • ...
    • Simplifying the definition of identity classes that use a single value as the primary key.
    • ...

    I had a look in JPOX at the way this application primary key will be implented... Great Stuff! And it avoids vendor lock-in.

    Good work on the JDO 2.0 spec all! That's what I call listening to the needs of developers.
  38. How to perform joins?[ Go to top ]

    I cannot find in the specshow to perform joins or select multiple values from multiple objects: in my project i may select fields from different domain objects into some view tier object,how can i do that in jdo?
  39. How to perform joins?[ Go to top ]

    I cannot find in the specshow to perform joins or select multiple values from multiple objects: in my project i may select fields from different domain objects into some view tier object,how can i do that in jdo?

    Chapter 15 describes basic ORM, including mapping a class to multiple tables, and chapter 18 is the definitive guide on all metadata+mapping elements.

    Section 12.7 describes fetch groups. Fetch groups allow you to specify exactly which fields, relations, and even fields of relations get loaded when objects of a certain class are initially loaded or refreshed. You can have different fetch groups for different situations, and you can change the set of active fetch groups at runtime. The JDO implementation will generate the necessary SQL (including joins) to fetch all the data in the active fetch groups as efficiently as possible.

    Section 14.6.9 describes how to query for sets of fields instead of just candidate objects (these are called "projection" queries). There are examples of projections in 14.10. Once again, the JDO implementation creates the joins necessary to fetch the specified data.

    Once the spec is finalized, I'm sure you'll see new editions published of many of the JDO books out there today. These books should explain everything in a much more user-oriented fashion.
  40. How to perform joins?[ Go to top ]

    Once the spec is finalized, I'm sure you'll see new editions published of many of the JDO books out there today. These books should explain everything in a much more user-oriented fashion.

    I should have added that SolarMetric's Kodo JDO documentation on JDO Queries is one such user-oriented writeup. It describes most of the JDO 2 query functionality (since Kodo already implements it), though the docs need some minor updates now that the final draft is released.
  41. JDO 2.0 is promissing![ Go to top ]

    I always favor JDO (from it's introduction) over EJB and even Hibernate, for it's data source and runtime independance as well as very well designed API. I do not like Hibernate APIs that are full of method chaining support that: a) is less readable (viloates Java main characteristic) and b) is less performant (method result, that is the object against which the method has been invoked, has to be passed back over the stack).

    So, I still use hand written OR mapping layers on my projects. They are not generic (that would be overkill, sure) but custom or semi-generic. The limitations of the original JDO 1.0.x spec (in features, that are thankfully resolved in 2.0) forced me to it as well as the lack of the good free implementation.

    MC
  42. JDO 2.0 is promissing![ Go to top ]

    I do not like Hibernate APIs that are full of method chaining support that: a) is less readable (viloates Java main characteristic) and b) is less performant (method result, that is the object against which the method has been invoked, has to be passed back over the stack).

    You don't like a _feature_ that nobody forces you to use? Thats weird.
  43. JDO 2.0 is promissing![ Go to top ]

    I do not like Hibernate APIs that are full of method chaining support that: a) is less readable (viloates Java main characteristic) and b) is less performant (method result, that is the object against which the method has been invoked, has to be passed back over the stack).
    You don't like a _feature_ that nobody forces you to use? Thats weird.

    Well, actually, I AM forced, though in indirect way:
    a) Even if I do not use method chaining I am forced to pay performance hit (although minor, but still an unnecesary performance hit),
    b) I am forced to read Hibernate examples that use it!

    MC
  44. JDO 2.0 is promissing![ Go to top ]

    I think JDO 2.0 is more than just promising. It's a big leap forward for the JDO specification and also for Java data persistence in general.

    Unlike EJB 3.0, the JDO 2.0 specification has almost finished its way through JCP and is certain to get final approval. That means that product vendors can offer JDO 2.0 support now (rather than wait for EJB 3.0 later).

    Even if JDO is not favored by everyone in the Java community (J2EE vendors, Hibernate fans, etc), the new specification raises the bar for everyone else.

    Craig Russell and his team have done an outstanding job.

    Another reason why JDO will survive after EJB 3.0 is that there probably will never be a single perfect data persistence option. Every development project is different and every organization has different requirements. JDO will continue to carve out a niche with a combination of a great expert group and some very good quality implementations (and hopefully an great Apache version).


    For all of these reasons, CodeFutures is committed to supporting the JDO 2.0 specification.


    PJ Murray
    CodeFutures
    http://www.codefutures.com
  45. JPOX license[ Go to top ]

    Supposing this is the latest JPOX license

    http://www.ibiblio.org/maven/jpox/licenses/jpox-1.0.2.license

    my impression is it is BSD or ASL like, isn't it?

    Thanks,

    Oliver
  46. JPOX license[ Go to top ]

    Supposing this is the latest JPOX license
    That isn't the latest JPOX license - it's the license we used to use (JPOX v1.0.2 to be precise with your URL), and is Apache license v1.1. The latest JPOX license is Apache 2.
  47. JDO 2.0 yes , EJB3 no[ Go to top ]

    I think JDO 2.0 is great!, and I really won´t need EJB 3.

    This words from Abe White pleased me.
    -"I don't think the JDO spec team is going to break compatibility with JDO 1 or otherwise degrade the JDO 2 spec simply for the sake of nominal compatibility with EJB 3." -

    In fact, these mix up of expert groups (JDO-EJB) in EJB 3 will finish in a mess.

    LONG LIVE to J D O 2.0!!!
  48. JDO 2.0 yes , EJB3 no[ Go to top ]

    I think JDO 2.0 is great!, and I really won´t need EJB 3. This words from Abe White pleased me.-"I don't think the JDO spec team is going to break compatibility with JDO 1 or otherwise degrade the JDO 2 spec simply for the sake of nominal compatibility with EJB 3."

    Ouch; my quote sounds harsh taken out of context. For the record, as a member of both the EJB 3 and JDO 2 groups, I wasn't implying that EJB 3 is a bad spec. All I meant is that trying to force API compatibility would push JDO in unnatural directions and ruin the internal consistency of the API (which has already been in use for years). It would be like trying to retrofit the Java Collections framework with the C# Collections API. Many JDO vendors have committed to implementing both the JDO 2 and EJB 3 APIs so their customers can use what they feel most comfortable with, giving the best of both worlds without sacrificing the API consistency of either spec.
  49. So now people have many choices.... sure that is a real problem.... pffff
    Three years ago, we were all playing with ejb 1.0 and jdbc.
    It wasn't a solution, now users have many choices, THAT'S GOOD.
    Could we stop "fighting" debatting 3 days on each features (generally commercial but totally unusefull feature)?

    If many users say JDO 2.0 is excellent, i trust them, i don't want to hear about vendors, just users and for the moment java comunity is hearing more Hibernate users... that's a fact!

    But all this is not war, if JDO2.0 is as great as Hibernate and EJB 3.0, men that's cool.

    Now, message for Abe Write, you have said many many things about ejb3.0 specs... at the beginning not really good things ;)
    EJB3 spec was written following the most usefull features needed for persistance, most of these features were already present in Hibernate, am i wrong?

    Message about bytecode processing: it will always be better to run without such process if you can avoid it.
    Some framework really need it. Hibernate 3, as far as i know, uses it for new features like lazy loading at property level, but i may be wrong... i think it's better not to add an ant task for bycode processing is every application, but that's my point of view.

    In conclusion, in one or two years JDO core and EJB3 core (surely Hibernate will be the first and the best implementation) will be comparable.
    Then, we'll need to speak about other things, maybe documentation? online support? cost (cost is important isn't it)?

    Yes i'm a hibernate user, and i'm happy with it as i know what i'm doing, i don't need consultant, i've learned thanks to the docs, forum and training not more, we have really bigs apps and all works very fine.

    I'll try the first serious, free, final and stable release of a product implementing JDO2.0

    Have nice tests ;)
  50. Now, message for Abe Write, you have said many many things about ejb3.0 specs... at the beginning not really good things

    Where did I say anything negative about EJB 3? The only thing I said is that trying to force EJB 3 compatibility on top of JDO's existing APIs would be bad for JDO, because you'd end up with an inconsistent API. I specifically said that EJB 3 was not a bad spec. I've have had the privilege of working with the EJB 3 spec group myself to some extent, and I have the utmost respect for them. If I wasn't clear on this, then I apologize.
  51. no problem, that was the way i understood it (it seems many people understood it like me) that wasn't good.
    You must admit all these topics (hibernate or ejb3 or jdo) are not good for people who need to choose a solution.
    They are losts, most of us don't even understand what is behind the words we use.
    I'm afraid that won't help.
    Sorry if my replies are not optimistic
  52. They are losts, most of us don't even understand what is behind the words we use.
    I'm afraid that won't help.
    i wanted to say most of them... of course ;)
  53. Choose one!!!!!![ Go to top ]

    ok for anyone who is confused by the discussion and cannot decide which to use,we have to confess that they all of comparable features so my suggest is based on the time frame
    hibernate2 NOW
    jdo2 within 6 monthes
    ejb3 after about 2 years

    hibernate is anailable now with most the cool features required for ORM so,if u need robust solution NOW , use hibernate
    jdo2 final will b available by jan or feb 2005 and 3 or 4 monthes for TCK development and vendor certification (ok stay with hibernate if u liked it)
    ejb3 has time table of 2006 i think BUT it will b part of a very big spec(J2EE 5) so it may delay in the specprocess and in the implementation by your vendor for another 1 or may b 2 years ,even if u need pojo persistance alone, u will wait alot
  54. Then , how to migrate?[ Go to top ]

    ok , u have to expect that u may need in any time to migrate from one solution to another,whether this is ur decision or ur manager's so donot forget to structure ur code for easy migration ie
    1-use the DAO pattern
    2-use abstracted exceptions
    (mmm.... spring provide good solution for both)
    3-use named query defined IN THE METADATA file
  55. Choose one!!!!!![ Go to top ]

    ok for anyone who is confused by the discussion and cannot decide which to use,we have to confess that they all of comparable features so my suggest is based on the time frame...

    JDO 1 is also available now, and most JDO 1 vendors are already offering many JDO 2 features. And even though EJB 3 is in its early stages, evaluation implementations are already cropping up.
  56. Choose one!!!!!![ Go to top ]

    hibernate is anailable now with most the cool features required for ORM so,if u need robust solution NOW , use hibernate jdo2 final will b available by jan or feb 2005 and 3 or 4 monthes for TCK development and vendor certification

    It's true that Hibernate is available now, and has most of the features anyone would want for ORM (also, there is a new Beta version out, with some very nice new features). However, almost all JDO vendors (including some open source versions) have already included many, if not most, of the JDO 2 features in their products. These products also have most of the features anyone would want for ORM, with the (in my view) advantage that they implement a standard API.
  57. Hibernate has everything?
    Does that mean it should be consider as a specification and reference implementation?
    So why still have new development in it?
     
    As I’m an Xcalia consultant I’m not objective about LiDO but considering Hibernate as a reference freezes me!
    I’m very please to see LiDO running on BEA JRockit (Hibernate + JRockit 5) or within a PDA (J2ME), accessing XML file or Versant Object-Database and also having a good support of open-source databases like Postgres…
     
    LiDO is JDO-1 compliant; it proposes most of the JDO-2 features, its APIs are reduced to the essential (mostly JDO API) avoiding you to develop the product yourself.
    Because ORM is not so simple, (inheritance, bi-directinal associations, maps, … ) and tuning is even more complex than “having a caching system” (transactions, concurrency, …) LiDO is accompanied by several tools.
    - LiDO Studio to draw and test the mapping, very cool if you consider doing it with a DBA.
    - Administration Console (JMX yet another specification) to monitor and dynamically tune your applications with no need to reload the application.
     
    Another small advantage of being JDO compliant is you can develop with a product and deploy with another one. This is even truer with JDO 2 and for relational persistence because the mapping coming specified; it is like having (no) vendor-specific deployment descriptor.
     
    Regards,
    Stephane Passignat
    www.xcalia.com
  58. Hi Persistence user[ Go to top ]

    "I'll try the first serious, free, final and stable release of a product implementing JDO2.0"

    If you are really willing to try a free, final and stable release of a product implementing JDO 2.0 then why not give LiDO XD 3.1 a try. You can download it for free from the Xcalia web site at the end of January 2005.

    Let me know how you like it...
  59. JDO 2.0 Public Draft Available[ Go to top ]

    JDO is just what you are searching for object persistence:

    - It has all features you found in custom products
    - You can use RDBMS, ODBMS, XML and flat files
    - It's a STANDARD
    - You can already choose between a dozen of implementations and some of these are open source

    bye,
    Luca Garulli
    OrienTechnologies.com - Light ODBMS, All in one JDO solution
    www.Pro-Netics.com (member of Orixo.com - The XML business alliance)
  60. JDO 2.0 Public Draft Available[ Go to top ]

    - It's a STANDARD

    JDO is not a standard. It's a specification. Three is a big difference.

     - Don
  61. JDO 2.0 Public Draft Available[ Go to top ]

    Lousy spellcheckers don't catch context yet :) There...
  62. JDO2.0 is here to stay.[ Go to top ]

    JDO It's a STANDARD.
    JDO2.0 is here to stay.
    Just relax.
  63. JDO2.0 is here to stay.[ Go to top ]

    JDO 2.0 > Hibernate 3.x > EJB3.0