JDO 2.0 Passes

Discussions

News: JDO 2.0 Passes

  1. JDO 2.0 Passes (48 messages)

    Java Data Objects 2.0 (JSR 243) has passed its Final Approval Ballot. The final tally was 15 Yes votes, 0 No votes, and one member of the Executive Committee (JBoss) didn't vote.

    Congratulations to the entire JDO spec team, but in particular to Craig Russell, the spec lead for JDO 2.0. Despite the controversy that has followed JDO 2.0 since its inception, Craig has focused on developing a mature, well-written, and complete specification that builds on the JDO 1.0 specification and the lessons learned from 4 years of real world usage.

    What's your opinion on JDO? With the advent of EJB 3's persistence architecture (which has learned from many other persistence architectures, including Hibernate, Toplink, and JDO, for example), does JDO have an appeal beyond current JDO users?

    Threaded Messages (48)

  2. JDO 2.0 Passes[ Go to top ]

    I would say despite a certain general "disengagement".
    About the appeal.
    Well, it is quite evident that strategies aimed to push (oversell) JPA against JDO, without fair comparison, would not help (any reference to BEA/Solarmetric announcement related to
    Kodo core & EJB3/JPA going opensource is purely casual).
    More that implementations, I think that the appeal could raise if more projects are built on top of JDO (see jfire.org).
    Even if JDOCentral.com would be better updated (maybe remebering the first 3 letters of its name).
    If, if, if....

    Guido.
  3. JDO 2.0 Passes[ Go to top ]

    With the advent of EJB 3's persistence architecture (which has learned from many other persistence architectures, including Hibernate, Toplink, and JDO, for example), does JDO have an appeal beyond current JDO users?

    It certainly should. There is much that JDO can do that EJB 3.0 persistence can't. Persistence to non-relational stores (and this means more than just object databases), much finer control of object lifecycle, and much finer tuning of what is loaded (fetch groups and fetch plans), a truer model of POJO persistence (no need for explicit version fields, and less restrictions on classes, fewer restrictions on the objects in Collections, Lists, Sets and Maps).

    There is much interest in generalised forms of persistence in other frameworks: Microsoft's LINQ will handle a range of stores. JDO takes this modern approach - limiting developers to relational stores is backward-looking.

    If the idea that JDO and EJB persistence should be united is still valid, then there is more work to be done, with more JDO features yet to be added to JPA.

    JDO 1.0 had, in my view, significant flaws that hindered its acceptance somewhat, requiring vendor extensions for many uses. JDO 2.0 is a far better specification.
  4. JDO 2.0 Passes[ Go to top ]

    no need for explicit version fields

    What I should have said is 'no need for explicit identity fields'.
  5. JDO 2.0 Passes[ Go to top ]

    There is much interest in generalised forms of persistence in other frameworks: Microsoft's LINQ will handle a range of stores.
    Even though LINQ is a ways off - what intrigues me about it is its non-datastore querying capability. There is a good article on it in CoDe Magazine (Mar/Apr 2006). The closest thing I can find in the Java world is JOSql.
  6. JDO 2.0 Passes[ Go to top ]

    There is much interest in generalised forms of persistence in other frameworks: Microsoft's LINQ will handle a range of stores.
    Even though LINQ is a ways off - what intrigues me about it is its non-datastore querying capability. There is a good article on it in CoDe Magazine (Mar/Apr 2006). The closest thing I can find in the Java world is JOSql.

    It seems similar. However, I don't see any reason why JDO should not be used to query just about anything - even in-memory objects. Information about thing you are quering is, after all, simply passed as properties when you create the PersistenceManagerFactory. JDO 2.0 does not require byte-code enhancement, so things can be done far more dynamically.

    Many consider having the query language as part of the C# (or VB.NET), as with LINQ, as a good idea. On balance, I am against this; I prefer strings which can potentially be externalised, so optimised and changed outside of the code. Having JDO as a set of libraries and not language extensions also means that non-Java languages on the JVM can potentially make use of it - I have used JDO from groovy and beanshell.
  7. JDO 2.0 Passes[ Go to top ]

    There is much interest in generalised forms of persistence in other frameworks: Microsoft's LINQ will handle a range of stores.
    Even though LINQ is a ways off - what intrigues me about it is its non-datastore querying capability. There is a good article on it in CoDe Magazine (Mar/Apr 2006). The closest thing I can find in the Java world is JOSql.
    It seems similar. However, I don't see any reason why JDO should not be used to query just about anything - even in-memory objects. Information about thing you are quering is, after all, simply passed as properties when you create the PersistenceManagerFactory. JDO 2.0 does not require byte-code enhancement, so things can be done far more dynamically.Many consider having the query language as part of the C# (or VB.NET), as with LINQ, as a good idea. On balance, I am against this; I prefer strings which can potentially be externalised, so optimised and changed outside of the code. Having JDO as a set of libraries and not language extensions also means that non-Java languages on the JVM can potentially make use of it - I have used JDO from groovy and beanshell.
    I agree. I wasn't so much thrilled with the embeding of the queries.

    I really wish someone involved in JDO -or where ever - would take this and run with it. The problem I see is that, just like rich clients vs web clients, not one "wants" it. Trying to seperate people from their beloved rdbms is like trying to get Anna Nichole to date someone within 20 years of her age. :) (Ok, that is the best I can come up with on short notice) Anyway, we have to wait for someone like Microsoft to "come up with" the idea for everyone to go "WOW" and "OOOOOH" and think it actually might be good idea. Just like they did with Smart Client. (How long has Web Start been available?).

    We are getting there with Grids and Clustered Caches. But we need a "standard" querying interface.
  8. JDO 2.0 Passes[ Go to top ]

    There is much interest in generalised forms of persistence in other frameworks: Microsoft's LINQ will handle a range of stores.
    Even though LINQ is a ways off - what intrigues me about it is its non-datastore querying capability. There is a good article on it in CoDe Magazine (Mar/Apr 2006). The closest thing I can find in the Java world is JOSql.
    It seems similar. However, I don't see any reason why JDO should not be used to query just about anything - even in-memory objects. Information about thing you are quering is, after all, simply passed as properties when you create the PersistenceManagerFactory. JDO 2.0 does not require byte-code enhancement, so things can be done far more dynamically.Many consider having the query language as part of the C# (or VB.NET), as with LINQ, as a good idea. On balance, I am against this; I prefer strings which can potentially be externalised, so optimised and changed outside of the code. Having JDO as a set of libraries and not language extensions also means that non-Java languages on the JVM can potentially make use of it - I have used JDO from groovy and beanshell.
    I agree. I wasn't so much thrilled with the embeding of the queries. I really wish someone involved in JDO -or where ever - would take this and run with it. The problem I see is that, just like rich clients vs web clients, not one "wants" it. Trying to seperate people from their beloved rdbms is like trying to get Anna Nichole to date someone within 20 years of her age. :) (Ok, that is the best I can come up with on short notice) Anyway, we have to wait for someone like Microsoft to "come up with" the idea for everyone to go "WOW" and "OOOOOH" and think it actually might be good idea. Just like they did with Smart Client. (How long has Web Start been available?).We are getting there with Grids and Clustered Caches. But we need a "standard" querying interface.

    Well Linq to my understanding is not a language extension but a set of lambda expressions ...
  9. JDO 2.0 Passes[ Go to top ]

    Well Linq to my understanding is not a language extension but a set of lambda expressions ...

    http://msdn.microsoft.com/netframework/future/linq/

    "The LINQ Project is a codename for a set of extensions to the .NET Framework that encompass language-integrated query, set, and transform operations. It extends C# and Visual Basic with native language syntax for queries and provides class libraries to take advantage of these capabilities."
  10. JDO 2.0 Passes[ Go to top ]

    I like the concept of being able to persist to any Data Store with JDO. Unfortunately the JDO 1.0 Spec had a lot of flaws and lacked a lot of features needed for relational databases (which are still around in most of todays enterprise apps). JDO 2.0 looks better in this regard but it is very late and it will have a hard time to compete against EJB 3 and Hibernate when it comes down to relational persistence.

    My opinion is that JDO has lost the race against Hibernate and EJB3 in the field of relational persistence. But I'm curious if JDO will grow in the area of xml / flatfile / objectdatabase / .... persistence.
  11. JDO 2.0 Passes[ Go to top ]

    In all accuracy, EJB3 persistence doesn't force you to bind to a relational database either.
  12. JDO 2.0 Passes[ Go to top ]

    In all accuracy, EJB3 persistence doesn't force you to bind to a relational database either.

    It doesn't force you, but the focus is clearly primarily on relational systems; just compare the EJBQL in EJB 3.0 with JDOQL - the former is pretty much relational SQL. It is a narrowing of focus compared with JDO.
  13. JDO 2.0 Passes[ Go to top ]

    First, congratulations to the JDO team. It's a great specification that has a lot to offer.

    It is a real shame that it took so long for 2.0 to arrive and that there was not a major open source version (from Apache, for example) from the very start.
    But I'm curious if JDO will grow in the area of xml / flatfile / objectdatabase / .... persistence.

    It's much more likely that Service Data Objects will be the API that emerges as the appropriate choice for data access to multiple data sources - especially in service-oriented architectures.
  14. Service Data Objects..[ Go to top ]

    I saw your comments about service data objects...I too was woundering about the need for datatype abstraction layers. Does anyone have a comparison, functional or otherwise, between SDO and JDO? I would be facinated to understand the differences in motivation and design intent.
  15. JDO 2.0 Passes[ Go to top ]

    JDO 2.0 looks better in this regard but it is very late

    I don't see how this applies - it is out before EJB 3.0, after all - is EJB 3.0 late? Perhaps it is!
    and it will have a hard time to compete against EJB 3 and Hibernate when it comes down to relational persistence.

    Many vendors who produce EJB 3.0 persistence are also supplying JDO 2.0 persistence in the same product, and which can even be used at the same time on the same objects in the same application. So, you have an API which can be used interchangeably with EJB 3.0 persistence, but has a superset of features, and lesser requirements (does not need Java 1.5). Given this, I would imagine that the number of developers who at least try JDO may well increase. On the other hand, the fact that some vendors are open sourcing their JPA implementations, but not their JDO implementations does not help in this regard.
  16. JDO 2.0 Passes[ Go to top ]

    On the other hand, the fact that some vendors are open sourcing their JPA implementations, but not their JDO implementations does not help in this regard.
    This is really a shame, especially when dealing with exceptions. I have been working with a very buggy closed source (and obfuscated) jdo implementation... it was no fun at all.
    I don't see how this applies - it is out before EJB 3.0, after all - is EJB 3.0 late? Perhaps it is!
    Looking at how long it took JDO 2.0 to finally pass is a pretty big amount of time.. that's what I meant. Especially regarding the flaws in the 1.0 spec and all the vendor extensions being out there.
  17. But I'm curious if JDO will grow in the area of xml / flatfile / objectdatabase / .... persistence.

    Note: this is a shameless plug, but worth the read.

    I can assure you that there is one implementation out there that has gone way beyond relational support, even beyond database support. Xcalia's XIC has introduced the notion of intermediation and dynamic composition so that you can build a composite application against a true business-level POJO domain model without regard to where and how the parts of that model are stored, whether it be in relataional databases, object databases, embedded databases, XML files & streams, or via services, including web services, EJB session beans, message queue destinations, mainframes, packaged applications (like SAP R/3, Oracle Financials, etc), or anything else that you can access from Java.

    I know this sounds too good to be true, but it's not. Please check out the Xcalia Developer's Network articles on how to do this. Intermediation is a technology that enables the dynamic composition of resources (databases and services) at runtime, so that just as an OR mapper frees you from writing SQL code, intermediation frees you from having to write procedural code to orchestrate the resource that you have to access during the course of your application's execution.

    Please don't flame me for trying to share this technology; this is the healthy result of how open source commoditizes things and encourages companies to innovate, which Xcalia has certainly done. I'd be making noise about this technology even if I didn't work for Xcalia, as I have felt the pain firsthand of only having a tool that can persist my model to only relational databases!

    While we can and will expose this functionality through EJB 3.0's JPA, JDO 2.0 is the interface that allowed us to pursue the idea of intermediation and dynamic composition and still remain compliant with the standard.

    --matthew
  18. Thanks for sharing that but please don't be mad at me posting the following...

    I have already wasted too much of my time with Lido and all it's bugs, so I'm not the biggest Xcalia fan around.
  19. Hi Michael,

    I'm sorry that you have that impression. When was the last time that you used LiDO? It was superceded by Xcalia Intermediation Core in 2005, so I expect that it's been a while. Drop me a line and I'd be happy to discuss!

    Thanks,
    Matthew
  20. JDO 2.0 Passes[ Go to top ]

    JDO 2 is now the most complete datastore agnostic standard persistence specification. The long wait of this version is paid back with improvements to RDBMS databases standarization, the heavily expanded JDOQL language and Query API, detachment, lifecycle listeners and many other features.

    The JDO TCK has also received many improvements, like changing to the junit framework, and the more important, the JDO TCK increased considerably the test coverage of the API, tested models and mappings. This will certify that JDO 2 compliant implementations are exceeding the most quality expectations
  21. JDO 2.0 Passes[ Go to top ]

    by the way, Congratulations Craig. ;)
  22. JDO 2.0 Passes[ Go to top ]

    I sure am glad that JDO is still alive and kicking. IMHO there should never have been entity beans or any of its successors. They taint the OO environment. JDO does a better job of hiding O-R mapping from an OO middle tier.

    However, since its so quiet here, maybe I should say something negative and provacative that involves Ruby on Rails, Spring, and Java EE. Maybe that would draw in the ravers and scripters.
  23. JDO 2.0 Passes[ Go to top ]

    Congratulations to Craig and everyone else involved on JDO 2.0! It's a great spec and it's obvious they've put in a lot of work and dedication.

    Yes, it is quite here. I was thinking the same thing. I almost can't believe it... but, I'll leave it to a 'raver' to pull the trigger... ;)
  24. sorry, this is a shameless rant, but I can not resist ...

    I must admit that the bugs in your fantastic product have cost us way too much time to believe any of your blurb.

    And w.r.t. open source: your product contains obfuscated open source code, which is probably legally ok, but the obfuscation is really helpful when one of your meaningless Exception messages is thrown at the desk of an unsuspecting developer

    Victor
  25. Ironically.... 1 year ago...[ Go to top ]

    Ironically, exactly 1 year ago:
    http://theserverside.com/news/thread.tss?thread_id=32547

    Back then there were 36 jobs with the word "JDO" on monster.com, and 123 with the word "hibernate".

    Exactly 1 year later, there are 40 jobs with the word JDO and 586 with the word "hibernate". Of the 40 jobs mentioning JDO, there are only 18 that don't also mention hibernate/toplink/kodo.

     - Don
  26. Ironically.... 1 year ago...[ Go to top ]

    Ironically, exactly 1 year ago:http://theserverside.com/news/thread.tss?thread_id=32547Back then there were 36 jobs with the word "JDO" on monster.com, and 123 with the word "hibernate".Exactly 1 year later, there are 40 jobs with the word JDO and 586 with the word "hibernate". Of the 40 jobs mentioning JDO, there are only 18 that don't also mention hibernate/toplink/kodo. - Don

    I don't find that surprising at all, or ironic in any sense. In my opinion Hibernate is and was a better API than JDO 1.0. Improvements were needed in JDO.

    Regarding job adverts, there are only 55 jobs for such a well-regarded persistence product as TopLink.... and iBatis has only 18....

    Even though I have used job advert numbers to debate matters of popularity, I realise they are flawed. I don't believe the number of users of of JDO - or Hibernate or TopLink - is as low as this indicates. Of course, I personally don't have any other measure I that I think is suitable for estimating use.

    But anyway, if JDO had even that fraction of the vast Hibernate 'market', it would be impressive; especially considering developers would be stuck with JDO 1.0 and vendor extensions.
  27. Ironically.... 1 year ago...[ Go to top ]

    I think that was your response last year too.

     - Don
  28. 1 year ago... a vibrant community[ Go to top ]

    I think that was your response last year too. - Don

    Which is, of course, irrelevant as to whether or not I am right or wrong.

    This time last year BEA commented that "After further review, BEA has concluded that there is a vibrant JDO community...". Whether or not they were right, I don't think these job ads say anything interesting. If you really want to conclude that JDO use is low - which I assume is your intention - using these figures, you also have to conclude that TopLink use is low and not much greater than JDO.

    But anyway, who cares? EJB 3.0 should be out soon. The effort now should be to continue the work on JPA to ensure that future versions combine the strengths of EJB 3.0 persistence and JDO 2.0. Currently JPA includes only a subset of JDO features. There is more work to be done.
  29. LiDO is stable now[ Go to top ]

    LiDO was at first a real beta software. But with time, it keep going better and the v3 is usable in production.
    When I compare the problems I've had with LiDO and the ones I'm having with hibernate, I really prefer LiDO.
    Another thing is that Xcalia read and try to understand their customers needs, unlike Gavin King (I really like some of his answers like "it's not a bug, it's a feature").

    Hibernate is the most popular OR/mapping tool used today but if it haven't been the first real open source OR tool on the "market", it would't have such a popularity today. Hibernate has too many flaws in conception (in my opinion) like proxies and behavior of the pojo too tied to the mapping settings. Life cycle of JDO objects can seem too complicated but it is, imho, a must go.
    I wish Jboss have choosed another persistance tool than hibernate...

    JDO group is slow to publish new specifications but when we have the result, we can see there was a lot of discussions on many points. JDO spec is really mature and can have a long future (if commercially successfull) because it is really well designed.
  30. Thanks for the feedback, Sylvain, both on LiDO and on JDO 2.0.

    I encourage you all to look beyond OR mapping, as it is largely a problem solved, and consider what's next: dynamic composition in a service-oriented architecture. That's where Xcalia is putting is energy now, with really impressive results.

    --matthew
  31. JDO 2.0 Passes[ Go to top ]

    Not to put the finger in the plague (hope have the same meaning in english), but the full arm, see
    http://java.sun.com/products/jdo/
    and you will not find any reference to the approval.
    On JDOCentral.com the last (!) breaking (ouch!) news date is 2/22/06....
    It is rather clear that there are non-technical forces that work against JDO success.
    There is no "advent of EJB 3's persistence architecture", there is simply a scientific attempt to kill JDO technology with, IMO, less than orthodox methods (you can also read "rather dirty", as you like).
    Hope not to hear from the same people: JDO ? Oh, yes, but the developer community did not accept it!!

    Guido.
  32. JDO and EJB 3.0[ Go to top ]

    Hi,
    What happen with the plans: Sun creates new Persistence API: EJB & JDO join forces? (http://www.theserverside.com/news/thread.tss?thread_id=28995 )

    "The new POJO persistence model will be delivered by JSR-220 as a separate specification, Reference Implementation, and Technology Compatibility Kit, usable independently of EJB 3.0"

    Is there a new POJO persistence model in Java EE 5.0 that will replace JDO 2.0 or?

    Could anyone explain the that?

    -Ove
  33. JDO and EJB 3.0[ Go to top ]

    Hi,What happen with the plans: Sun creates new Persistence API: EJB & JDO join forces? (http://www.theserverside.com/news/thread.tss?thread_id=28995 )"The new POJO persistence model will be delivered by JSR-220 as a separate specification, Reference Implementation, and Technology Compatibility Kit, usable independently of EJB 3.0"Is there a new POJO persistence model in Java EE 5.0 that will replace JDO 2.0 or?Could anyone explain the that?-Ove
    No, noone can and, I would say, will be able to explain it without being put in ridicule.

    Guido.

    P.S.
    Java EE 5.0!!!
    And the happy users of J2SE 1.4 what should they do ?
    Really SUN & Co. thinks that the only job of developers (read companies) is porting applications from old platforms to new (and better ?) ones ?
    Should we regret M$ ?
  34. JDO and EJB 3.0[ Go to top ]

    Hi,What happen with the plans: Sun creates new Persistence API: EJB & JDO join forces? (http://www.theserverside.com/news/thread.tss?thread_id=28995 )"The new POJO persistence model will be delivered by JSR-220 as a separate specification, Reference Implementation, and Technology Compatibility Kit, usable independently of EJB 3.0"Is there a new POJO persistence model in Java EE 5.0 that will replace JDO 2.0 or?Could anyone explain the that?-Ove

    I'll have a go. There is a new persistence model that is part of EJB 3.0. It is called JPA, and is based partly on Hibernate, Toplink and JDO. It is a POJO persistence API and is far easier to use than previous persistence methods in EJB. The big debate is going to be whether this new API is ready to replace JDO or not. There will be some who say that it is, as it is based on quality products that have a proven record for POJO persistence on relational stores.

    There will be others (me included) who think otherwise - that the features of JDO that JPA lacks (finer control of object state, fewer requirements for the structure of the objects that are to be persisted, fetch groups and plans, fewer restrictions on the contents of persistent Collections, working well with more than just relational stores) mean that JPA has some way to go before many of us JDO users will switch. I accept that JPA is a huge step forward for EJB and with its emphasis on relational persistence, it will be fine for probably the majority of developers (even if they do find some of the restrictions irritating), but Java has always been about having choices. The vast majority of Java use is now about server side development, but does that mean that Sun should give up on technologies for other uses? Does the success of J2EE mean that Sun should drop Swing? Of course not. This is why I believe that unless JPA adopts more JDO features, JDO won't be entirely replaced by it, and after all, JDO 2.0 is very close to the current specification for JPA so also works fine for relational stores. JDO certainly hasn't had anything like the use of products like Hibernate, as previous versions were somewhat awkward to use in some cases and relied on proprietary vendor extensions, but it still seems to have a reasonable number of users, and there are many vendors producing quality implementations, and JDO 2.0 is now an accepted specification. What is the motivation to switch?
  35. JDO, Entity Beans, Hibernate[ Go to top ]

    I still get the impression that entity beans of are not really such a good idea. Maybe I should restrict this statement to EJB <= 2.x, because the EJB 2.x entity beans have been dropped in EJB 3.x and given their name to something new, which is btw. much closer to hibernate and JDO than to EJB 2.x-entity beans from what I have seen so far. But this requires a painful switch, including Java >= 1.5, new application servers and migrations which are off course non-issues, as long as you read the information of the app-server-vendors, up to the time when you really have to do them...

    So hibernate and JDO still have there space for quite a time to go. I understand that hibernate is more adequate for database driven development, because it uses the ORM and bases objects on the given database structure. Slightly like the active record of Ruby-on-Rails, which goes quite a step further in this direction, but is somewhat the same in that it is also database driven. JDO is strong in creating the database structure from the Java-objects, which is just the other way around. This means that these are good for two different approaches and I do not see why either of these lacks justification for its existence. But the database driven approach is far more common in real life, so I find it only natural that hibernate is much more popular than JDO.

    I expect that in the Java world both hibernate and JDO will retain their current level popularity.
  36. JDO, Entity Beans, Hibernate[ Go to top ]

    JDO is strong in creating the database structure from the Java-objects, which is just the other way around. This means that these are good for two different approaches and I do not see why either of these lacks justification for its existence. But the database driven approach is far more common in real life, so I find it only natural that hibernate is much more popular than JDO.

    I don't have much experience in Hibernate, but regarding JDO; it is totally neutral as to whether you create the Java objects from the database or the other way around. The specification for JDO 2.0 includes much on the mapping between objects and relational stored, but says nothing about which comes first. What matters in this respect is the tools that come with individual JDO products. I have used JDO products which allow very flexible two-way evolution of database structures and Java classes - a change in one can be converted into a change in the other.

    I think you are setting up a false division between Hibernate and JDO here.
  37. JDO, Entity Beans, Hibernate[ Go to top ]

    I think you are setting up a false division between Hibernate and JDO here.
    I think so too. I've been using Hibernate for a while.

    Doing a data driven design (as opposed to middle out) is possible with Hibernate, but probably will end up causing more work in the persistance layer (ie concantenated keys).
  38. JDO, Entity Beans, Hibernate[ Go to top ]

    I think you are setting up a false division between Hibernate and JDO here.
    I think so too. I've been using Hibernate for a while. Doing a data driven design (as opposed to middle out) is possible with Hibernate, but probably will end up causing more work in the persistance layer (ie concantenated keys).

    All of CodeFutures Hibernate customers are doing data-driven design. So it's certainly possible, if a little strange given that Hibernate is for ORM. However, if an organization has standardized on Hibernate as its persistence tier, it makes sense to still use it on new projects starting from scratch (i.e. data first, with a new database schema).

    PJ Murray
    CodeFutures Software
    Data Access Objects and Service Data Objects
  39. JDO, Entity Beans, Hibernate[ Go to top ]

    However, if an organization has standardized on Hibernate as its persistence tier, it makes sense to still use it on new projects starting from scratch (i.e. data first, with a new database schema).PJ MurrayCodeFutures Software

    I think this is probably less true now that in the past. As Hibernate is going to be an implementation of EJB 3.0/JPA, surely this means that for new projects such organisations now have the opportunity to evaluate alternative implementations of JPA. Some of those implementations even give you the choice of evaluating JDO, and using JDO as the same time in the same code.
  40. JDO, Entity Beans, Hibernate[ Go to top ]

    All of CodeFutures Hibernate customers are doing data-driven design.
    See. It it possible.
     So it's certainly possible, if a little strange given that Hibernate is for ORM.
    Not really. It is flexible that way.
    However, if an organization has standardized on Hibernate as its persistence tier, it makes sense to still use it on new projects starting from scratch (i.e. data first, with a new database schema)
    Wouldn't that be objects first (with persistable objects and persistable attributes) and database schema second? The problem people run into doing it this way is they still insist on integrating at the database (not data) level.

    On a side note, when will someone come up with an ETL tool that maps to objects.
  41. JDO is dying[ Go to top ]

    I don't see why anyone would start using JDO today. EJB EntityBeans has the support from big vendors and is regulated by the JCP. Hibernate is roaming free to implement new features (for better or worse). There are no reason for the vendors or users to maintain several APIs when they are so similar.
  42. JDO isn't dying yet[ Go to top ]

    I don't see why anyone would start using JDO today. EJB EntityBeans has the support from big vendors and is regulated by the JCP. Hibernate is roaming free to implement new features (for better or worse). There are no reason for the vendors or users to maintain several APIs when they are so similar.

    Firstly, not everyone wants to base their persistence on EJB, with their focus entirely on relational stores. Hibernate is also focussed on such stores (and, no matter what its qualities, some developers prefer to use products that conform to specifications - having a product that can 'roam free' is not appealing to some).

    JDO 2.0 is a now first-rate API for relational persistence, but JDO was also designed from the start to be a general-purpose persistence mechanism, with far more exciting possibilities than just interfacing with databases.

    JDO 2.0 has many implementations, including open source and high-quality commercial products. The similarity of APIs mean that it is relatively easy for vendors to support both APIs, allowing developers to use JPA, or the superset of features that is JDO.

    Do Java developers really only see the need for routine database work, or should there be projects with more imagination and range? I think there should be - and some of the things that Xcalia are doing (described in a previous post) show the exciting possibilities that JDO allows.
  43. JDO isn't dying yet[ Go to top ]

    Do Java developers really only see the need for routine database work, or should there be projects with more imagination and range? I think there should be - and some of the things that Xcalia are doing (described in a previous post) show the exciting possibilities that JDO allows.
    Ah yes, the limited vision of the many. As I said before, people are so focused on persistance, they forget the bigger picture. I wish I knew how to break people from database trance they are in.
  44. JDO isn't dying yet[ Go to top ]

    Do Java developers really only see the need for routine database work, or should there be projects with more imagination and range? I think there should be - and some of the things that Xcalia are doing (described in a previous post) show the exciting possibilities that JDO allows.

    Thanks, Steve, for pointing us out. It seems Gartner thinks that we're worth noticing, too. They just announced today that we are one of the Gartner "Cool Vendors" of 2006:

    http://biz.yahoo.com/iw/060320/0113781.html

    Xcalia is firmly committed to both JDO 2.0 & EJB 3.0, so whatever you choose, you'll still be able to use our product. Granted, some of the parts of EJB 3.0 won't apply (mapping annotations), but I don't see it as a big problem not to use those parts of EJB 3.0.

    --matthew
  45. JDO isn't dying yet[ Go to top ]

    Thanks, Steve, for pointing us out. It seems Gartner thinks that we're worth noticing, too. They just announced today that we are one of the Gartner "Cool Vendors" of 2006

    Congratulations. JDO is a cool API!
  46. JDO is dying[ Go to top ]

    I don't see why anyone would start using JDO today. EJB EntityBeans has the support from big vendors and is regulated by the JCP. Hibernate is roaming free to implement new features (for better or worse). There are no reason for the vendors or users to maintain several APIs when they are so similar.

    No Thanks. Entity beans is well known for it's horrible API and poor implementions. It does not scale and you end up moving part of the code to JDBC.
  47. EJB is not horrible[ Go to top ]

    I don't see why anyone would start using JDO today. EJB EntityBeans has the support from big vendors and is regulated by the JCP. Hibernate is roaming free to implement new features (for better or worse). There are no reason for the vendors or users to maintain several APIs when they are so similar.
    No Thanks. Entity beans is well known for it's horrible API and poor implementions. It does not scale and you end up moving part of the code to JDBC.

    First of all I must thanks Steve Zara for the information about the new persistence model (JPA) that is part of EJB 3.0 and the explanation about the different between JDO and JPA!!

    I think it really ridiculous to say “Entity beans is well known for its horrible API and poor implementions”, Erik Bengtson have you ever used EJB 2.1?

    I have used EJB 2.1 and it works well I think!
    But I don’t say EJB is the only ways that do the work, some people like Hibernate better (but it is not a STANDARD)!

    EJB 3.0 I hope will do the work better, with a lot of improvement and also easier to use.
    I think good idea’s from Hibernate, Spring and even .Net, have made this happen --> the new improved standard, Java EE 5.0

    What will happen next with JPA and JDO?
    Move all good things with JDO 2.0 into JPA or?

    -ove
  48. EJB is not horrible[ Go to top ]

    I think it really ridiculous to say “Entity beans is well known for its horrible API and poor implementions”, Erik Bengtson have you ever used EJB 2.1?

    Happy to see that entity beans were good enough for you, but entity beans is not more than another ORM API built on the top of RMI. It allows fail over and load balancing with the means of the stubs on the client side, but this does not add much because it is not a best practice to invoke it remotelly (for the reasons that you know). Therefore the only worthwhile feature left only is the ORM persistence aspect, which unlike many mature persistence APIs (JDO or JPA) it requires a lot of work to implement and has limited support to match java models to rdbms models. Entity beans determines the way you work and how your model will look like.

    On the other hand, most JDO ORM implementations supports almost any model that you can ever come up with, plus many of them also has support to fail over and support to external caching products helping. Not mentioning the far better querying capabilities and usage patters
  49. EJB is not horrible[ Go to top ]

    I have used EJB 2.1 and it works well I think!
    Yes it might be possible.
    I have to admit that is the first time I hear such a statement.
    Well, not exactly.
    I have posted this story few times, see http://www.theserverside.com/news/thread.tss?thread_id=39111 (the one with " Performance??" comment).
    What will happen next with JPA and JDO?
    Move all good things with JDO 2.0 into JPA or?
    There is nothing in JPA that cannot be done in JDO, so, IMO,
    the other way around should be the preferred choice.
    About the opportunity to start using JDO today, I would suggest the same thread above at the subject
    "DAO is still needed", or this http://www.theserverside.com/news/thread.tss?thread_id=39236
    (this subject in particular - Standards, specs, execution environments and other BS... - ), just the get some ideas.
    But, if you like Entity Beans....

    Guido