An interview on the new persistence API, from the JDO side

Discussions

News: An interview on the new persistence API, from the JDO side

  1. A lot of questions have come out of the announcement by Sun, that JSR 220 will hold a separate Spec/RI/TCK for a new persistence API. Craig Russell, and Rick Cattell of Sun have been interviewed, and shed some light on the new persistence API, and how it affects the community.

    They answer questions such as:

    • What is going on with persistence in the Java community?
    • Is it practical to provide a single persistence API?
    • What are some characteristics of the proposed new API?
    • How will this work be organized?
    • What will happen to JDO 2.0?
    • How and when will JDO 2.0 be available?
    • How will the new persistence API be delivered?
    • What persistence features can we expect from the expanded JSR 220 group?
    Read the full interview

    Threaded Messages (37)

  2. My reading of this is that JDO 2.0 will come out, and then developers and JDO vendors will be encouraged to migrate to the new API.

    I find this very puzzling.

    I would have asked two more questions:

    "As JDO 2.0 is a very full specification for POJO persistence and years of work has been put into it, why isn't JDO 2.0 being used as the basis for the common persistence API?"

    "Can you guarantee easy migration from JDO 2.0 to the new API, for example by having JDO 2.0 Interfaces as part of the API?"

    If the answer to either question is "No", then it would seem that Sun intends to dump JDO in the long term, and some further questions need to be asked!
  3. Is this just politics?[ Go to top ]

    How does Sun plan to position JDO vs. this new API going forward?
    A: We will promote this new API as the preferred standard upon which you should build solutions. We'll encourage persistence API vendors including JDO vendors and EJB vendors to develop migration strategies to help developers move to this new API.
    If they want a standard, persistence framework that can be used in both J2SE and J2EE, they already have one.

    Sun should just deprecate entity EJBs and push adoption of JDO as its replacement.
    This seems a lot more sane than deprecating both persistence frameworks and starting a new one. Why waste the effort already put into JDO?
  4. Is this just politics?[ Go to top ]

    I don't know if this is politics, but it sure smells like it.

    Your suggestion of "deprecate entity beans and push adoption of JDO" would not please those people have invested alot of development effort in entity beans, hence I guess they decided to come up with a solution that no one would be happy with.

    I agree that shoehorning entity beans into JDO is the proper solution.
  5. deprecating entity beans[ Go to top ]

    Without deprecating entity beans, that mechanism would simply wither from future disuse anyway, as the market forces gravitate to JDO 2.0. Competition will naturally kill entity beans. Dare I say that entity beans are already a deadend, except for applications that have simplistic persistence needs.
  6. Why all this Q&As and press releases give us this poker-faced politician talk and do not say a word about what really going to happen. This was brewing for months. I am sure they must have worked out (before the announcement) how the merge will happen.

    GIVE US SOME TECHNICAL DETAILS (EVEN IF VERY GENERIC) ON THIS FUTURE API!!!

    For example will it be managed instance JDO like approach versus introspection based like Hibernate, Toplink, Cocobase etc.?

    In this interview, they call JDO 2 "updates to JDO 1.0, including enhancements to JDOQL". I think JDO expert group, after almost a year of hard work, produced a very good and exciting specs and they call it "updates to JDO 1.0".

    Many JDO users are eager to start with JDO-2 but this merger add lots of confusion and uncertainty - stay with JDO-1 and wait till new products are out or go JDO-2 or table JDO all together till these new specs and products are out. We (present users of JDO) can only guess just how much will be left of original JDO after EJB folks are done with it.

    I hope the purpose of this merger (acquisition?) is not to do what MS often does - purchase a good technology just to table it
  7. Hi,

    I agree with Alex.

    We need more technical specs in order to consider the changes in application development at the moment so we can adopt the new Persistence API.

    So how will the technical approach for implementing transparente persistence look like ?

    Will it be in JDO1 style by using bytecode enhancement or will it be introspection like hibernate ?
    Will the persistence-by-reachabilty-approach used or will there be something different ?

    Will the interface/class relations of the API look like JDO or will it be different ? What I exactly mean, will there be a factory(EntityFactory) for producing a manager (EntityManager), a transaction object, a query object ?
    If yes, we can build some wrapper classe around them.

    What will happen to the identity concepts from JDO ?
    Since persistence in relational databases will be the main focus PK-Identity (application identity) will likely included.
    But what about datastore identity ?
    If you want to use perisistence in object-database-manner where identity is managed by the system/runtime. Will it be there ?

    And finally how will queries look like. As I see the new Kodo JDO has something like "Single String Queries" which look like HQL oder EJBQL. So it look like JDOQL1 will be depricated.

    Will optimistic transactions be included ?

    And will there be some standardized identity-generating facilities ?

    Obviously we need some more informations about the API/interfaces that we have to consider for current application development in big projects.

    Thanks,
    Matthias
  8. We are designing a project right now and we are planning to use JDO at this time, the project implementation date is Aug 2005. This is tough situation for us to decide which way to go related to persistence. Entity Beans/JDO/O-R mapping/JDBC????
    Any suggestion based on project dates?
  9. We are designing a project right now and we are planning to use JDO at this time, the project implementation date is Aug 2005. This is tough situation for us to decide which way to go related to persistence. Entity Beans/JDO/O-R mapping/JDBC????Any suggestion based on project dates?
    So you want to decide your persistence solution based on time release points and not on the technology ? That's a bad precedence. JDO uses plain old java objects. Entity Beans don't. JDBC involves writing persistence code yourself. You should be looking at the relationship modelling of your system and judging your choice of technology based on that what you want to use.

    If you decide on the need for O/R mapping based on the complexity of the data to be mapped then you should be reviewing the O/R technologies around and look at which one will be in place by your implementation date. As a reference point for the technologies discussed here : EJB3 (and this O-R spec) will be out in 2006 (projected), whilst JDO2 will be out very soon (and vendor implementations of it will be out soon after that).
  10. First of all thank you Andy for your reply, Sorry if I am not clear, or if you understood wrong. I second you and your persistence options just do not depend on what some company is going to release in future. We cannot do project based on that. That’s very good point.
    But if you see my requirements as of now and implement my project in next 1 or 2 months, for just good to do in entity beans without complicating much and just using CMP.
    But what if I do not follow wants going to be released as part of SUN EJB3 or EJB/JDO common API and look out how the market is changing and blindly design the project based on my current requirements and assumptions without thinking of the future and suddenly by the time in implement in August 2005, we have to change all the entity beans to something else, then we have to put money again in project and waste the time and resources.
    So, if you see the other side of question, it is based on implementation date and choices you can use to implement you project wisely. And from those options think about which on suits you best for your requirements.
    We are designing a project right now and we are planning to use JDO at this time, the project implementation date is Aug 2005. This is tough situation for us to decide which way to go related to persistence. Entity Beans/JDO/O-R mapping/JDBC????Any suggestion based on project dates?
    So you want to decide your persistence solution based on time release points and not on the technology ? That's a bad precedence. JDO uses plain old java objects. Entity Beans don't. JDBC involves writing persistence code yourself. You should be looking at the relationship modelling of your system and judging your choice of technology based on that what you want to use. If you decide on the need for O/R mapping based on the complexity of the data to be mapped then you should be reviewing the O/R technologies around and look at which one will be in place by your implementation date. As a reference point for the technologies discussed here : EJB3 (and this O-R spec) will be out in 2006 (projected), whilst JDO2 will be out very soon (and vendor implementations of it will be out soon after that).
  11. This may provide some clarity, consider other alternatives:

    http://www.hibernate.org

    http://www.ibatis.com

    I am a fan of iBatis.

    Both are not JDO. Both are not EJB. Both are very good.
  12. This may provide some clarity, consider other alternatives:http://www.hibernate.orghttp://www.ibatis.comI am a fan of iBatis.Both are not JDO. Both are not EJB. Both are very good.
    Thank you Ben, We will definitely look into hibernate and ibatis and see whether it fits our requirements or not.
    By the way the project we are doing is from scratch/from nothing, at this point just gathering requirements. So we have the flexibility to chose different options and design accordingly based on our requirements.
  13. This may provide some clarity, consider other alternatives:http://www.hibernate.orghttp://www.ibatis.comI am a fan of iBatis.Both are not JDO. Both are not EJB. Both are very good.
    Thank you Ben, We will definitely look into hibernate and ibatis and see whether it fits our requirements or not. By the way the project we are doing is from scratch/from nothing, at this point just gathering requirements. So we have the flexibility to chose different options and design accordingly based on our requirements.
    There are many standard ways to persist objects in JAVA,
    do not forget to develop some standard home made tool for persistence yourself too.
  14. This may provide some clarity, consider other alternatives:http://www.hibernate.orghttp://www.ibatis.comI am a fan of iBatis.Both are not JDO. Both are not EJB. Both are very good.
    These are good solutions, but there is no reason not to continue with JDO. JDO 2.0 will be out soon, and many companies will be supporting it. The new POJO persistence mechanism is nothing more than a matter for discussion at the moment, whereas JDO is a well-supported reality.
  15. ... there is no reason not to continue with JDO. JDO 2.0 will be out soon, and many companies will be supporting it. The new POJO persistence mechanism is nothing more than a matter for discussion at the moment, whereas JDO is a well-supported reality.
    Even more, you could start with open source JDO implementation like JPOX(http://www.jpox.org) or TJDO(http://tjdo.sourceforge.net) and then when your project reaches "critical mass" you can switch to commercial implementation like KODO (http://www.solarmetric.com).

    This would be a pretty good and safe way for development! Without investing into commercial product from the start you can start using JDO!

    It is really like with JDBC. You can start doing your project with some open source DB (SQL-92 complaint) like Hypersonic DB (http://hsqldb.sourceforge.net) and then once your project graduates and requires commercial DB implementation you can switch to other vendor (like Oracle, Sybase or any other SQL-92 complaint DB)
  16. Thanks for all your replies, you make absolutely right point. Our clients and different groups were slightly inclined towards the JDO specification based on different analysis, which each group has done. But we do not want to implement that across all the projects. We would like to make decision based on project requirement.
    As a good start we would see how it fits our project, As Ruslan said before trying any commercial product, Its good to try with open source (JPOX(http://www.jpox.org) or TJDO(http://tjdo.sourceforge.net).

    More I read about the future of Entity bean, more I get feeling the Entity beans will slowly be taken out. Is that the trend, you all are seeing.

    I am glad that I posted my question here.
    Thank you,
    ... there is no reason not to continue with JDO. JDO 2.0 will be out soon, and many companies will be supporting it. The new POJO persistence mechanism is nothing more than a matter for discussion at the moment, whereas JDO is a well-supported reality.
    Even more, you could start with open source JDO implementation like JPOX(http://www.jpox.org) or TJDO(http://tjdo.sourceforge.net) and then when your project reaches "critical mass" you can switch to commercial implementation like KODO (http://www.solarmetric.com).This would be a pretty good and safe way for development! Without investing into commercial product from the start you can start using JDO!It is really like with JDBC. You can start doing your project with some open source DB (SQL-92 complaint) like Hypersonic DB (http://hsqldb.sourceforge.net) and then once your project graduates and requires commercial DB implementation you can switch to other vendor (like Oracle, Sybase or any other SQL-92 complaint DB)
  17. This announcement doesn't change the fact that there are solutions for ORM that work well right now. Hibernate, good JDO implementations and TopLink work just as well now as they did before this announcement or even before EJB3 was conceived. (And no doubt other ORM tools that I haven't used, so apologies for not mentioning.)

    The prudent path seems to me to be:

    1. Use what works now if you have requirements now. This promise is a long way off.
    2. Try to design apps to isolate dependence on the persistence API so if you ever want to migrate to whatever JSR-220 comes up with, you can without gutting your application.

    Point 2 implies to me staying well clear of 2.1 CMP, which is the real loser at this point. (It's already pretty much irrelevant in the market, if the clients I come into contact with are representative.) OTOH JDO and Hibernate seem fairly safe options. Hibernate/JDO/TopLink are basically about POJO persistence. Sure, there are semantic differences and you query differently etc, but you can persist POJOS and they can behave like objects, participating in inheritance relationships etc. Thus with appropriate application design, migrating from any of these to JSR-220 persistence is unlikely to result in a total rewrite. Whereas it's safe to argue that migrating from CMP2 to JSR-220 will have a huge impact. Of course you could continue to use your legacy CMP entity beans, but phasing them out would be inevitable and supporting two very different models in an application (or even a company) is unattractive.

    Rgds
    Rod
  18. Thanks for all your replies, you make absolutely right point. Our clients and different groups were slightly inclined towards the JDO specification based on different analysis, which each group has done. But we do not want to implement that across all the projects. We would like to make decision based on project requirement.As a good start we would see how it fits our project, As Ruslan said before trying any commercial product, Its good to try with open source (JPOX(http://www.jpox.org) or TJDO(http://tjdo.sourceforge.net).More I read about the future of Entity bean, more I get feeling the Entity beans will slowly be taken out. Is that the trend, you all are seeing.I am glad that I posted my question here.Thank you,
    Srikanth, I am not in your shoes and don't know your situation, but I would never make a technology decision based upon half a dozen posts on a TSS thread. No disrespect to the posters, but their opinions are not going to help you when the new Java Persistence API comes out and you have to answer to your boss about why you have to rewrite a boatload of code just to ensure that your application has a future. As soembody else (Rod?) mentioned, there are a number of good persistence solutions out there. They are all out there "now", and as far as standards go in a year or so they are on equal footing: they will either implement the new Java Persistence API, or they won't and will be non-standard. If I were you I would base my decision on how it answers two primary questions: a) Does the technology do what I need it to do now and going forward? b) Will the product provide me with a solid and dependable migration strategy to the new Persistence API? By demanding this of the vendors you and other potential customers will help ensure that the industry moves together towards a unified persistence standard.

    Regards,
    -Mike
  19. ..Srikanth, I am not in your shoes and don't know your situation, but I would never make a technology decision based upon half a dozen posts on a TSS thread. No disrespect to the posters, ...
    Good points. There are more than one troll on this forum. There are also vendors lurking around, I suspect ;-)

    Learn to spot FUD.
  20. We are designing a project right now and we are planning to use JDO at this time, the project implementation date is Aug 2005. This is tough situation for us to decide which way to go related to persistence. Entity Beans/JDO/O-R mapping/JDBC????Any suggestion based on project dates?
    If you are looking for a fast, flexible, and non-intrusive solution, you may want to consider JDX OR-Mapper. Currently shipping in version 4.5, JDX is also pretty lightweight.

    -- Damodar Periwal
    Software Tree, Inc.
    Simplify Data Integration
  21. look for stability[ Go to top ]

    Hello Srikanth,

    As was suggested several times - do not run for latest-greatest,
    it is mirage, never-ending saga... Most of technologies will
    easyly give you 90% of your persistence.

    1. Look for flexible functionalities to cover last 10%:
    -- streaming clob/blob support for your database,
    -- direct access to SQL, like
    ArList ar=(Student)DBEngine.getResult("select...."),
    and be DBA your best friend
    -- easy command line generation of POJOs and interfaces from tables with
    automatic discovery of 1:n and n:m traversable relationships
    -- plugable JTA, connection pools, connection validity test....
    -- direct hooks to Connection pre-check-out and pre-check-in,
    it is useful to identify client in database level...

    2. look for stability, long track of good records

    3. Consider persistence mechanizm/tool as part of overall
    project design. For example, TopLink is natural for
    Oracle/JDeveloper shop, while Hibernate is , may be, more
    suitable for JBoss-subscribed project.

    Persistence mechanizm has big impact on code and must be
    settled in the beginning of the project, not in 2005. The only
    alternative would be re-plugable JDO or SPING.

    Have a nice project!

    Alex V.
  22. Hi Matthias
    And finally how will queries look like. As I see the new Kodo JDO has something like "Single String Queries" which look like HQL oder EJBQL. So it look like JDOQL1 will be depricated.
    The single-string form of JDOQL is exactly that: a tokenized way of representing a JDOQL query in a single string instead of as a number of separate clauses. It is part of the JDO 2.0 standard, and will be specified in the Public Draft Specification being issued shortly.

    JDOQL 1.0 has been extended in JDO 2.0. The new features are discussed in a series of articles which I have written, Part I of which was published on TSS a few days ago. The single-string form is discussed in Part III.

    JDOQL 2.0 is a superset of JDOQL 1.0. Nothing has been deprecated, but many important capabilities have been added. The single-string representation is a convenience which I believe many people will use, but the content between the SELECT/FROM/WHERE/GROUP BY/HAVING/ORDER BY etc. tokens is identical between api-based and single-string representations.

    So the query:

    Query q = pm.newQuery(AuctionItem.class, "location.isoCode == 'UK'");
    q.setOrdering("title ascending");

    becomes: (case is not important)

    SELECT FROM org.hammer.domain.AuctionItem WHERE location.isoCode == 'UK' ORDER BY title ASCENDING

    Kind regards, Robin.
  23. They just killed JDO as a whole spec[ Go to top ]

    I think by doing this they simply killed JDO completely!

    The preferred "standard" way will be some "new POJO spec" that is not JDO or CMP.

    My guess is that they will rename CMP and add some "hyber" accent to it.
    This way they will satisfy app. server vendors.

    It was a mistake, to allow to "join" JDO2 with EJB3. JDO2 was practically assimilated!

    Too bad. Now we have to wait again X years for some standard API! What a mess...
    Java as a platform really loses to .Net on this...

    Also, they mentioned that they would have TWO "versions" of this mysterious "new POJO persistence" - one for J2EE and one for J2SE...

    Now I'm puzzled completely...at the end of the day can I write my j2SE app that will use "new POJO spec" APIs and then recompile my DAL classes for J2EE environment WITHOUT ANY REFACTORING?
    Will it be addressed too?
  24. What to do until new API is out?[ Go to top ]

    Hi Alex
    I think JDO expert group, after almost a year of hard work, produced a very good and exciting specs ... Many JDO users are eager to start with JDO-2 but this merger add lots of confusion and uncertainty - stay with JDO-1 and wait till new products are out or go JDO-2...
    JDO is currently the only standard available for developers wishing to adopt a lightweight POJO approach to persistence, the new API will be part of J2EE 1.5 which isn't likely to be delivered until the first half of 2006. JDO 2 will be released long before then. However, with the collaboration between the two expert groups, users can expect to see their JDO implementations embrace the new API alongside continued support for JDO. This is very much inline with our vision here at Versant for our Open Access suite of products (formerly JDO Genie). You can begin developing with JDO and you will be able to continue with JDO tomorrow or try the newly defined API or mix and match both as required.

    Cheers
    David
    Versant Open Access www.versant.com
  25. What to do until new API is out?[ Go to top ]

    I second David's response here.

    JDO 1.0 has been out for a couple of years now, and we're shooting for being done with 2.0 by 2004 (I can't translate that into JCP terms exactly). It's the only JCP-ratified Java standard on transparent persistence.

    I say use it now if it solves well the problems that you have now. Whenever the next thing comes along, evaluate it and decide whether you want to move to it. The JDO 2.0 APIs are going to be around for a long time...

    --matthew
  26. David,

    Thanks for suggestion. We've been heavy JDO users since its inception several years ago. We are not going to drop it because of this announcement of course but we are worried about its future. And we might choose to stay with JDO1 because all advanced features which go far beyond O/R mapping and Queries might not be present in the new specs.
    As said in the statement new standard will be developed based on EJB3 with few JDO experts participating. So despite the fact that JDO2 is much better developed and to my opinion superior standard it will not be taking lead in persistence standards.
    So I personally have no confidence in the future of JDO2. For example due to managed nature of JDO instances, JDO users enjoyed highly efficient change tracking and persisting. If specs will mandate non-managed introspection POJOs, cost of persisting small changes to large graphs or collections will increase significantly - just one example.

    It reminds to be seen what will prevail in the end - need of java community or interest of big app server vendors and personal egos of certain individuals.
    I can just hope that least common denominator approach will not win in this case
  27. And we might choose to stay with JDO1 because all advanced features...might not be present in the new specs.
    I think it's sad if users feel that they should make much such choices, staying aware from things that are useful now and supported in real products, because a spec that's over one year from release might not provide them. To me that's a sign of a spec process that's not working too well. Good news for Microsoft though--they get a bonus of over a year to catch up to Java in the O/R mapping area...

    Personally I would use the features you need now, and worry about migration later. I am confident that with leading JDO vendors, TopLink and Hibernate there will be a migration path for users who want to move to JSR-220 persistence. And interoperability between their own APIs and the JSR-220 API. It might be prudent to try to abstract somewhat from the underlying API, where this is reasonable.

    Rgds
    Rod
  28. blockquote>I would use the features you need now, and worry about migration later.Yeah Rod this is what we likely will do. I just cant make myself to not to use all those great features. We might pay for it dearly later because I do not think you can abstract things like managed vs introspected approach out. If you use Detachment API instead of of value/transfer object and it is gone in future specs where will it leave us. I do not see muc chance to migrate this sort of things without MAJOR redevelopment. So JDO market will be fragmented with good vendors trying to provide -proprietary- support to their existing clients and clients being loked in their existing implementations.

    There will be no clear path for future JDO enhancements as any change in JDO will be dragged down by 100000 pound EJB begemote

    Why couldn't they leave JDO alone? It provided good integration with EJBs as is and would have supported any new EJB standards anyway and stay independent and innovative.

    Sorry for my whining. I posted more on TheServerSide in last few days than I didn in past 2 years. For us it is not an academic question of what's better - JDBC, iBatis, JDO, StoredProcedures, Hybernate, EJB - all our project in last 3 years have been built on top of JDO and we have been banking on JDO2 new features in planning and estimating our upcoming projects

    Thanks

    Alex
  29. GIVE US SOME TECHNICAL DETAILS (EVEN IF VERY GENERIC) ON THIS FUTURE API!!!
    There were given in the open letter :
      will be based on the EJB3 early draft
      some of the JDO EG members will join the EJB3 EG and think on it
    There is no magic spec ready and written within the night.
    Give'em time.
  30. I think by doing this they simply killed JDO completely!
    Which is a good thing! Really.

    JSR220 is not a political thing. It's a realization that JDO sucks. In fact, JDO has sucked up all the worst tradeoffs you can do in the process of crafting a persistence library.

    The Java community is going to need something simpler and yet more versatile if we're going to be able to compete with ObjectSpaces.NET, etc.
  31. I think by doing this they simply killed JDO completely!
    Which is a good thing! Really. JSR220 is not a political thing. It's a realization that JDO sucks. In fact, JDO has sucked up all the worst tradeoffs you can do in the process of crafting a persistence library.The Java community is going to need something simpler and yet more versatile if we're going to be able to compete with ObjectSpaces.NET, etc.
    Saying that ObjectSpaces is superior technology is like say JDO is superior as well.

    Do a google and find how ObjectSpaces is similar to JDO
    http://www.dotnetguru.org/us/articles/JDOvsObjectSpaces/JDOvsOS.htm
  32. ObjectSpaces is postponed[ Go to top ]

    Hi,

    the comparsion you are referencing is out-dated.

    By now ObjectSpaces has gone two steps further:

    The beta available earlier this year showed an reflection-based approach, instead the abstract properties approach of the first beta.

    The next step happened recently, please see
    http://msdn.microsoft.com/data/objectspaces.aspx

    ObjectSpaces is no longer available as beta, won't be in version 2.0
    of the .NET framework and will most probably look completely different if it
    should appear once.

    Best regards,

    Christian
  33. JSR220 is not a political thing. It's a realization that JDO sucks. In fact, JDO has sucked up all the worst tradeoffs you can do in the process of crafting a persistence library.
    Intriguing, particularly since over the last 6 months no significant technical deficiencies of JDO have been articulated against JDO in the TSS forums.
  34. JSR220 is not a political thing. It's a realization that JDO sucks. In fact, JDO has sucked up all the worst tradeoffs you can do in the process of crafting a persistence library.
    Intriguing, particularly since over the last 6 months no significant technical deficiencies of JDO have been articulated against JDO in the TSS forums.
    Probably because nobody uses for anything but mickey mouse apps.

    During the past two years, we've tried JDO, Hibernate, ObjectSpaces and our in-house development mapping tool (plus EJB entity beans... YIKES!)

    The conclusion is that ObjectSpaces (beta) and Hibernate rocks, and JDO just don't. The easy stuff is easy to do, while the hard stuff is close to impossible (that's what our programmers say), or the implementation just gets in the way in terms of performance and scalability (not JDO's fault, though)
  35. Hi "Han The Man"
    Probably because nobody uses [JDO] for anything but mickey mouse apps.
    That is TOO funny .. but how did you know that? (Hint: Mickey Mouse (tm))

    However, outside of that company, I've seen both JDO and Hibernate getting major traction in every major industry. For example, I know of two re-writes of trading systems being done right now, and one is in Hibernate and the other with one of the leading JDO vendors.
    The conclusion is that ObjectSpaces (beta) and Hibernate rocks, and JDO just don't. The easy stuff is easy to do, while the hard stuff is close to impossible (that's what our programmers say), or the implementation just gets in the way in terms of performance and scalability (not JDO's fault, though)
    I'd be interested in hearing more details, because I'm trying to collect tips on when to use one versus the other. Which JDO implementations did you use? Just the open source ones? Which commercial ones?

    What things were not performant? Scalable? Where you using just 1.0.1 features, or the new 2.0 support?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  36. That is TOO funny .. but how did you know that? (Hint: Mickey Mouse (tm))
    :-)
    However, outside of that company, I've seen both JDO and Hibernate getting major traction in every major industry
    Dunno how you know that. The only thing I know is this: I am a consultant in the telco industry, and the telco industry is a good barometer for technological pressure. I've yet to see a SINGLE JDO deployment in the 10-ish companies I've worked with the past two years.
    I'd be interested in hearing more details, because I'm trying to collect tips on when to use one versus the other. Which JDO implementations did you use? Just the open source ones? Which commercial ones?
    I've tried all of them (commercial ones which had demo/crapware versions) and at least 3 or 4 open source impl's. Like OJB (yuck, although i dig the virtual proxy implementation)
    What things were not performant? Scalable?
    Complex (attempts at) joins, for instance.
    Where you using just 1.0.1 features, or the new 2.0 support
    1.0.x, mostly.

    Performance and scalability issues aside (I'm sure they will be solved): I simply don't like JDO. It's not pleasant to work with. It seems to work against me.
  37. 1.0.x, mostly.Performance and scalability issues aside (I'm sure they will be solved): I simply don't like JDO. It's not pleasant to work with. It seems to work against me.
    Quite a weak argument against JDO. Same kind of arguments I have seen from other people...but when JDO experts asked about details - everyone went silent...
    C'mon, this is the fact. JDO is a standard for in J2SE world for POJO persistence.
    Also it has nice integration into J2EE (via JCA). If you prefer to write your own persistence framework, or use some open source one - no problem... there is a place for everyone under the Sun...
  38. However, outside of that company, I've seen both JDO and Hibernate getting major traction in every major industry
    Dunno how you know that. The only thing I know is this: I am a consultant in the telco industry, and the telco industry is a good barometer for technological pressure. I've yet to see a SINGLE JDO deployment in the 10-ish companies I've worked with the past two years.
    FWIW The largest telco in the US uses JDO in several projects that I'm aware of. However, as you say, the number of actual deployments of JDO and Hibernate have been pretty low until recently, but we're definitely seeing more now.
    What things were not performant? Scalable?
    Complex (attempts at) joins, for instance.
    I am not surprised, depending on how you were using it. What is different about how Hibernate does the same type of functionality that makes it a more scalable and/or performant approach?
    Performance and scalability issues aside (I'm sure they will be solved): I simply don't like JDO. It's not pleasant to work with. It seems to work against me.
    I wish I could get more time on both Hibernate and JDO. When I hear things like this, it's hard to relate because I haven't worked enough with them to "hit the wall" with either one. All the simple stuff is simple enough with either one.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters