Home

News: Hibernate responds to Versant attacks

  1. Hibernate responds to Versant attacks (210 messages)

    Responding to anti-Hibernate marketing materials from JDO vendor Versant, Hibernate founder Gavin King has published a blog disputing a number of technical and marketing claims on Versant's part, offered as opinion and not fact, and offers a lot of marketing information himself.

    Read Gavin King's response to Versant Spam

    One of his starting points is that Versant is comparing their OODBMS to Hibernate 2.1 instead of the 3.0-rc, claiming that the release candidate is a formal release.

    Gavin concludes:
    Hibernate can boast tens of thousands of satisfied users; why should they start paying for a closed source solution to a problem which is now very effectively solved by free software?
    Responses like this can be interesting, if only to see what the controversial points are to the authors. What do you think?

    Threaded Messages (210)

  2. 2 cents[ Go to top ]

    I would choose Hibernate over a proprietary thing in a heartbeat, because a (quality) open-source product with a huge install base carries minimal risk, even if I I am sure that someone can design someone proprietary which may be superior here and there.
  3. 2 cents[ Go to top ]

    I would choose Hibernate over a proprietary thing in a heartbeat, because a (quality) open-source product with a huge install base carries minimal risk, even if I I am sure that someone can design someone proprietary which may be superior here and there.
    Dont get me wrong. I'm a Hibernate fan and use it on several projects, however in many respects, Hibernate is the proprietary spec in this comparison. I think your comment would apply more directly to a "commercial" vs "open source" implementation, as JDO is a non-proprietary specification.
  4. Right, both are proprietary ;-)[ Go to top ]

    Hibernate and Versant are both proprietary. At least, if you take in consideration that their core technology (the persisting engine) is not define by any standard so far.

    But as there are not standard but on the accessing API, who cares ;-)

    Ok, Versant ODBMS is a great DBMS and it has some JDO capability so at least it is "interroperable".

    But Hibernate is opensource and pure Java made, plus the team are working with the EJB3 group.

    So at the end personally, I understand Versant position, but I also understand that Hibernate team is not happy. But ey, this is marketing ;-) Do people scream when MS is claiming webservice to be fast and reliable solutions ?

    By the way, even if Hibernate is great, I am a bit uncomfortable with the fact it is assuming that RDBMS are good and should be there til the end of time. Guys, are you not fed up to be all "object" oriented but on the storage tier ?

    ORM or ODBMS who cares as long as we get rid of the RDBMS's burden. IMHO, what is still missing for a solution to "win" is : cross-version access to object graph, incremental update of schema, realy efficient GC solution.

    By the way, anybody still up at http://www.ozone-db.org ?
  5. Right, both are proprietary ;-)[ Go to top ]

    Everywhere I've worked (inc. small, medium and large companies) uses a relational database, and I don't see that changing anytime soon. Hibernate solves the specific problem of ORM elegantly and efficiently. If you read this page: http://www.hibernate.org/38.html (Why This Project is Successful), you will see the point "do one thing well". And they do.

    On a side note, I've often wondered if the Hibernate team should throw a JDO interface on top of it just like they're throwing an EJB 3.0 interface on top of it for JBoss. Then maybe people will stop whining about standards. They'd have 2 to choose from, JDO or EJB, with Hibernate under the hood. Of course, whenever you choose to go with a "standard" you lose some of the power the underlying tool gives you. Standards can often be thought of as the common denominator.

    Personally I don't care because I hide my Hibernate-specific code behind Spring.
  6. Right, both are proprietary ;-)[ Go to top ]

    On a side note, I've often wondered if the Hibernate team should throw a JDO interface on top of it just like they're throwing an EJB 3.0 interface on top of it for JBoss. Then maybe people will stop whining about standards.

    Also on a side note: In almost two years since we have the current forum software, from more than 10.000 registered users, in more than 65.000 postings, there have been only two (2) request for a JDO API. It took me a moment to even find them but I think you can see why nobody on the dev team considered it a viable thing to do. I also don't see people whining about it. Except on TSS, naturally.
  7. Right, both are proprietary ;-)[ Go to top ]

    On a side note, I've often wondered if the Hibernate team should throw a JDO interface on top of it just like they're throwing an EJB 3.0 interface on top of it for JBoss. Then maybe people will stop whining about standards.
    Also on a side note: In almost two years since we have the current forum software, from more than 10.000 registered users, in more than 65.000 postings, there have been only two (2) request for a JDO API. It took me a moment to even find them but I think you can see why nobody on the dev team considered it a viable thing to do. I also don't see people whining about it. Except on TSS, naturally.

    This is exactly right.

    We usually try to implement stuff our users ask for. Not stuff our competitors ask for. Surely this is a reasonable approach to take?

    BTW, I don't think "proprietary" is at all a reasonable description of a piece of software that you or anyone else can fork at any time, if it pleases you to do so. Most OSS projects get forked at some stage. I guess the fact that noone has yet bothered forking Hibernate is a massive validation of the fact that we have done a good job of delivering the things our users really want and need.
  8. Right, both are proprietary ;-)[ Go to top ]

    We usually try to implement stuff our users ask for. Not stuff our competitors ask for. Surely this is a reasonable approach to take?

    Yup.

    Rant (not directed at you, Gavin!):

    Ya' know, I used to be a "standards" bigot, but not anymore. Standards have their benefit and place (and many definitions), but when it comes down to actually getting the job done - and getting it done well - an experienced developer knows to just buckle down and choose the best tool for the job. There is no "golden hammer" or "silver bullet" in software.

    The implication? Well, sometimes that means you'll being doing an import from a package other than java.foo or javax.foo (gasp!). People don't seem to mind doing an import of org.apache.log4j code (or most other org.apache projects for that matter), so what's so different about import net.sf.hibernate (or better yet, org.hibernate)?!?!

    These are strong OSS projects with a large and active user base. What are people so afraid about? Do the import!!!
  9. Right, both are proprietary ;-)[ Go to top ]

    People don't seem to mind doing an import of org.apache.log4j code (or most other org.apache projects for that matter), so what's so different about import net.sf.hibernate (or better yet, org.hibernate)?!?!These are strong OSS projects with a large and active user base. What are people so afraid about? Do the import!!!

    I think it is a matter of scale. I am reasonably happy to import logging code and other stuff of a similar scale because I'm pretty sure I could write much of that myself, and I'm confident I could debug the imported code as well if required, so using these imported features is a matter of convenience, and not necessity. However, something like Hibernate is large and rich and complex.

    It may be a personal thing, but I get a kind of claustrophobic feeling if I am using something that large that I can't replace with an alternative from another vendor without too much work. This is why I chose Java in the first place - so I can swap platforms, and can source my VMs from different suppliers.

    OK, so that's what at least one person is afraid of!

    Perhaps when EJB 3.0 POJO persistence is out and approved and Hibernate implements it, then I'll be comfortable using it.
  10. Right, both are proprietary ;-)[ Go to top ]

    I'm not saying to sprinkle org.hibernate imports across your entire app. Make your data access code an impl behind an interface, and use the interface from the rest of your code. Then your HibernateFooDaoImpl is very localized and replaceable. How you wire the specific impl to the interface for the rest of your app can be done in many ways. For example, IOC / Dependency Injection tools make it a breeze.
  11. Right, both are proprietary ;-)[ Go to top ]

    I'm not saying to sprinkle org.hibernate imports across your entire app. Make your data access code an impl behind an interface, and use the interface from the rest of your code. Then your HibernateFooDaoImpl is very localized and replaceable. How you wire the specific impl to the interface for the rest of your app can be done in many ways. For example, IOC / Dependency Injection tools make it a breeze.

    There are still matters of the mapping files, and the query design and optimisation. I'm currently working on an application where a lot of work has gone into these. With JDO 2.0 these should be largely interchangeable between products. However, I take your point.
  12. De facto standards...[ Go to top ]

    I used to be a "standards" bigot, but not anymore. Standards have their benefit and place (and many definitions), but when it comes down to actually getting the job done - and getting it done well - an experienced developer knows to just buckle down and choose the best tool for the job.
    Craig MaClanahan (sp?) had an interesting take on this at TSSJS... basically you need an official standard when there is a reasonable expectation that there will be multiple implementations of the standard. As Gavin and others have pointed out, there isn't really a present need for multiple Hibernate implementations, so it doesn't make sense to submit it to the JCP. The only other reason to make it a standard would be if Sun wanted to bundle it with J2SE or J2EE.
  13. good reply from gavin[ Go to top ]

    Just wanted to point out that Gavins reply was quite fair and in any way a "normal" reaction to false claims from a competitor. I am saying this while NOT using Hibernate but a JDO implementation Patrick knows quite well :-) The point is, if a product vendor wants to sell licences by ranting about other products, he is most likely in trouble. Good products dont need to do that kind of marketing.

    The only point i am disagreeing with is the last sentence. We all know that there are some benefits in using commercial products when it comes to support and documentation. Sometimes the speed of inovations is also better. Mike and others will most likely second me in that oppinion. I still think Hibernate is a pretty good choice when it comes to ORM, but i was one of the guys not asking for JDO support in Hibernate forums and decided to use a JDO product because Hibernate doesnt support it. If Hibernate would support JDO and in the same time would offer commercial support, i probably would be a hibernate user.

    And folks, dont use this thread for a JDO vs. Hibernate discussion which it isnt. Its just a Versant vs. Hibernate discussion. I, in contrast to _some_ JSR-220 guys, dont have anything against choices.

    Marc Logemann
    http://www.logemann.org
  14. Right, both are proprietary ;-)[ Go to top ]

    I guess the fact that noone has yet bothered forking Hibernate is a massive validation of the fact that we have done a good job of delivering the things our users really want and need.
    Other than NHibernate which, because of what it is, is still validation.
  15. Also on a side note: In almost two years since we have the current forum software, from more than 10.000 registered users, in more than 65.000 postings, there have been only two (2) request for a JDO API.

    I would consider evaluating Hibernate if it implemented JDO - just as I have evaluated other JDO implementations like JPOX and TJDO. You've never heard my opinion on your board, because I don't frequent boards of products I don't evaluate/use. If I were to hazard a guess, I would say that there is probably a significant population that shares that characteristic with me.

    (A happy JDO user)
    God bless,
    -Toby Reyelts
  16. Right, both are proprietary ;-)[ Go to top ]

    On a side note, I've often wondered if the Hibernate team should throw a JDO interface on top of it just like they're throwing an EJB 3.0 interface on top of it for JBoss. Then maybe people will stop whining about standards.
    Also on a side note: In almost two years since we have the current forum software, from more than 10.000 registered users, in more than 65.000 postings, there have been only two (2) request for a JDO API. It took me a moment to even find them but I think you can see why nobody on the dev team considered it a viable thing to do. I also don't see people whining about it. Except on TSS, naturally.

    Count me as the 3rd request for a JDO API and additionally JDO 2.0 spec compliance.
         - signed "Proud TSS Whinner"
  17. Right, both are proprietary ;-)[ Go to top ]

    Count me as the 3rd request for a JDO API and additionally JDO 2.0 spec compliance. - signed "Proud TSS Whinner"
    I'm sorry, but again, we listen to actual users on this, not TSS posters. I see that perhaps this poses a catch-22 for some people :-(

    I hope you will be very happy with our JSR-220 implementation when it is ready :-)
  18. Count me as the 3rd request for a JDO API and additionally JDO 2.0 spec compliance. - signed "Proud TSS Whinner"
    I'm sorry, but again, we listen to actual users on this, not TSS posters. I see that perhaps this poses a catch-22 for some people :-(I hope you will be very happy with our JSR-220 implementation when it is ready :-)
    And how many hibernate registered users actually asked for EJB3 spec compliance, or any spec compliance at all, besides JDO?
  19. And how many hibernate registered users actually asked for EJB3 spec compliance, or any spec compliance at all, besides JDO?

    That's a good question, Henrique! Probably hardly any at all, neither for EJB3 nor for JDO.

    Even once EJB3 is finalized, using Hibernate3 directly will remain a compelling alternative - after all, even the current Hibernate 3.0 is already a superset of what EJB3 persistence will provide.

    Juergen
  20. And how many hibernate registered users actually asked for EJB3 spec compliance, or any spec compliance at all, besides JDO?

    Has anyone asked this question:

    Does Hibernate's popularity today has anything to do with the slogan "Hibernate is EJB3"?

    If yes, to what extent?
  21. Count me as the 3rd request for a JDO API and additionally JDO 2.0 spec compliance. - signed "Proud TSS Whinner"
    I'm sorry, but again, we listen to actual users on this, not TSS posters. I see that perhaps this poses a catch-22 for some people :-(I hope you will be very happy with our JSR-220 implementation when it is ready :-)
    And how many hibernate registered users actually asked for EJB3 spec compliance, or any spec compliance at all, besides JDO?

    I thought it but never actually asked , those guys are
    so good they can read your mind.

    ( off to buy a tinfoil hat )
  22. Right, both are proprietary ;-)[ Go to top ]

    Count me as the 3rd request for a JDO API and additionally JDO 2.0 spec compliance. - signed "Proud TSS Whinner"
    I'm sorry, but again, we listen to actual users on this, not TSS posters. I see that perhaps this poses a catch-22 for some people :-(I hope you will be very happy with our JSR-220 implementation when it is ready :-)

    As long as the final spec emminating out of JSR-220 is as good or better than the JDO 2.0 spec (assessment is necessarilty qualitative, I know) then I will be on board.

    I am very fearful, however that JSR-220, will be a step back from JDO 2.0. A couple of things that I absolutely do not want to see dropped in JSR-220 that JDO provides are (off the top of my head):
  23. Right, both are proprietary ;-)[ Go to top ]

    Count me as the 3rd request for a JDO API and additionally JDO 2.0 spec compliance. - signed "Proud TSS Whinner"
    I'm sorry, but again, we listen to actual users on this, not TSS posters. I see that perhaps this poses a catch-22 for some people :-(I hope you will be very happy with our JSR-220 implementation when it is ready :-)

    As long as the final spec emminating out of JSR-220 is as good or better than the JDO 2.0 spec (assessment is necessarilty qualitative, I know) then I will be on board.

    I am very fearful, however that JSR-220, will be a step back from JDO 2.0. A couple of things that I absolutely do not want to see dropped in JSR-220 that JDO provides are (off the top of my head):

      - Persistence operations and queries that are written with the focus on the domain object model; not the datastore.

      - Following from the above, JSR-220 needs to also maintain datastore independence. The new persistene spec absolutely cannot act as if RDBMS are the only datastore implementations that developers want to persist objects in. Yes, RDBMS are the most popular and hence should receive the most focus. But they should not be the only supported datastore.

      - JSR-220 should impose as few restricitons on persistable POJOs as JDO 2.0. Only real restriction in JDO is that a persistence-capable class have at least a private,protected or public no-arg constructor. And have at least one private, protected OR public primitive or persistence-capable field.

      - The types of classes that can be made persistence-capable should be at least the same set that is persistence-capable in JDO 2.0 (most of the Collections API, etc.).

    Summerizing, JSR-220 should be a superset of JDO features not a subset. If it ends up being less featureful then JDO 2.0, then why would I migrate to it again?!??!
  24. JSR-220[ Go to top ]

    Count me as the 3rd request for a JDO API and additionally JDO 2.0 spec compliance. - signed "Proud TSS Whinner"
    I'm sorry, but again, we listen to actual users on this, not TSS posters. I see that perhaps this poses a catch-22 for some people :-(I hope you will be very happy with our JSR-220 implementation when it is ready :-)
    As long as the final spec emminating out of JSR-220 is as good or better than the JDO 2.0 spec (assessment is necessarilty qualitative, I know) then I will be on board. I am very fearful, however that JSR-220, will be a step back from JDO 2.0. A couple of things that I absolutely do not want to see dropped in JSR-220 that JDO provides are (off the top of my head):  - Persistence operations and queries that are written with the focus on the domain object model; not the datastore.  - Following from the above, JSR-220 needs to also maintain datastore independence. The new persistene spec absolutely cannot act as if RDBMS are the only datastore implementations that developers want to persist objects in. Yes, RDBMS are the most popular and hence should receive the most focus. But they should not be the only supported datastore.  - JSR-220 should impose as few restricitons on persistable POJOs as JDO 2.0. Only real restriction in JDO is that a persistence-capable class have at least a private,protected or public no-arg constructor. And have at least one private, protected OR public primitive or persistence-capable field.  - The types of classes that can be made persistence-capable should be at least the same set that is persistence-capable in JDO 2.0 (most of the Collections API, etc.). Summerizing, JSR-220 should be a superset of JDO features not a subset. If it ends up being less featureful then JDO 2.0, then why would I migrate to it again?!??!

    This is an interesting post! ANY JSR-220 EG members want to address Joe's concerns?
  25. Winning marketshare[ Go to top ]

    Count me as the 3rd request for a JDO API and additionally JDO 2.0 spec compliance
    I'm sorry, but again, we listen to actual users on this, not TSS posters.

    LOL. That's an excellent strategy for winning marketshare. ;)

    God bless,
    -Toby Reyelts
  26. aren't they....[ Go to top ]

    defining the ejb3 interface based on the hibernate3 implementation?

    i think this aspect is what irritates alot of people and draws criticism about the JCP, because JDO is a good ORM standard that's JCP and although Hibernate is a good open-source product is not standard (until ejb3).

    i think the feeling of some people is that the jboss crew has 'hijacked' the jsr220 spec, and is acting more in the interest of jboss than the java community, but we all know the JCP is safe from such abuses, right?

    anyhow, jdo impls will be the ones adding on the ejb3 interface when it's done, won't they? or they will just front the jdo domain/data models with session beans like it's done now, or just ignore the ejb container entirely and use spring, etc...
  27. aren't they....[ Go to top ]

    i think the feeling of some people is that the jboss crew has 'hijacked' the jsr220 spec, and is acting more in the interest of jboss than the java community, but we all know the JCP is safe from such abuses, right?

    Please explain to me how it is possible that we could "hijack" a spec committee where 25 other companies (including the #1 competitor to Hibernate, TopLink) and 11 individuals are represented? We don't lead the spec group. We don't have the spec group stacked with our friends. We weren't even involved in the original decision to go down the path of simplifying entity beans (we joined shortly after the EG started work on the simplified entity bean model).

    We have certainly argued for certain technology decisions, but they are, of course, only ever adopted to the extent that other people agree with our arguments.

    JSR-220, as it stands today, combines the input of many individuals and companies with a stake in J2EE, and the EJB 3.0 persistence model is influenced not only by the two market-leading ORM solutions for Java (Hibernate, TopLink), but also by the ideas of the other big J2EE vendors (especially SUN, BEA, Sybase, IBM), and is now incorporating input from the more successful JDO vendors (especially Solarmetric).

    And, IMO, it is exactly right for the JCP to look to successful existing solutions for inspiration, instead of "inventing" in committee. We have seen where that approach has failed in the past.

    This has gotta be the most broad-based "hijacking" I have ever seen. If you take a look at the size of customer bases of the organizations I have named above, you will see that they represent hundreds of thousands or tens of hundreds of thousands of users: a much, much, much broader cross-section of the Java community than is available in any other forum. Certainly a broader representation of the community than is available in most other JCP expert groups or TSS comment threads.
  28. take a deep breath....[ Go to top ]

    i said "i think the feeling of some people is...", not that this is the case.

    i believe the many improvements to the spec are largely in part to the influence of the jboss crew, and that the blatant ignoring of jdo in favor of a hibernate-like solution is also based on this influence.

    i will applaud and with open arms greet the stable-production ready ejb implementations when they arrive, and until then i'll stick with 2.1 and one of the many orm solutions on the market until then.
  29. 2 cents[ Go to top ]

    Hibernate is the proprietary spec in this comparison. I think your comment would apply more directly to a "commercial" vs "open source" implementation, as JDO is a non-proprietary specification.


    Hibernate is proprietary at the moment, but that's just until EJB 3.0.


    PJ Murray
    CodeFutures Software
    Java Code Generation for Data Persistence
    http://www.codefutures.com
  30. Sheer hypocrisy![ Go to top ]

    Gavin's rants are hypocritical and reprehensible. The moment the JCP defeated the first draft of the JDO 2 JSR due to the dishonest campaign by certain anti-JDO vendors, Gavin's own company started sending out e-mails gloating that "JDO is dead" and that it was "time to start considering moving to Hibernate". They sent these to KNOWN JDO CUSTOMERS, and were full of lies and distortions. Funny, I never received a retraction in my inbox when JDO 2 was UNANIMOUSLY APPROVED in the reconsideration ballot.

    And now he comes out and complains about a straight-up product comparison sent out by one of the vendors that they have been lying about for as long as anyone can remember?

    My patience with their crap has completely run out. How can anyone trust anything these guys say? It's almost as comical as Ward Mullin's hysterical and wounded posts of yore (before CocoBase did an about-face and adopted JDO).
  31. Sheer hypocrisy![ Go to top ]

    Gavin's rants are hypocritical and reprehensible. The moment the JCP defeated the first draft of the JDO 2 JSR due to the dishonest campaign by certain anti-JDO vendors, Gavin's own company started sending out e-mails gloating that "JDO is dead" and that it was "time to start considering moving to Hibernate". They sent these to KNOWN JDO CUSTOMERS, and were full of lies and distortions.

    AFAIK, this is simply not even remotely true. Do you have any evidence that this claim is anything more than a complete, dishonest fabrication?

    If anyone from JBoss had sent such an email, I would be extremely upset. However, I believe that this has never happened.

    Who are you?
  32. Sheer hypocrisy![ Go to top ]

    The moment the JCP defeated the first draft of the JDO 2 JSR due to the dishonest campaign by certain anti-JDO vendors, Gavin's own company started sending out e-mails gloating that "JDO is dead" and that it was "time to start considering moving to Hibernate". They sent these to KNOWN JDO CUSTOMERS, and were full of lies and distortions.
    AFAIK, this is simply not even remotely true. Do you have any evidence that this claim is anything more than a complete, dishonest fabrication?If anyone from JBoss had sent such an email, I would be extremely upset.

    Gavin,

    SolarMetric doesn't want to get involved in the Versant/Hibernate dispute (or any others), but we can confirm that JBoss sent emails to known JDO customers hours after the first failed JDO 2 ballot was made public. We had a developer on-site with a client when that client received one. The email that we saw wasn't as blatant as the the poster's quote above, but it linked to the ballot and its intent was clear. You might want to talk to JBoss' sales team if you disapprove. If left unchecked, I think all sales people have a tendency to get a little over-zealous :)
  33. Sheer hypocrisy![ Go to top ]

    The moment the JCP defeated the first draft of the JDO 2 JSR due to the dishonest campaign by certain anti-JDO vendors, Gavin's own company started sending out e-mails gloating that "JDO is dead" and that it was "time to start considering moving to Hibernate". They sent these to KNOWN JDO CUSTOMERS, and were full of lies and distortions.
    AFAIK, this is simply not even remotely true. Do you have any evidence that this claim is anything more than a complete, dishonest fabrication?If anyone from JBoss had sent such an email, I would be extremely upset.
    Gavin,SolarMetric doesn't want to get involved in the Versant/Hibernate dispute (or any others), but we can confirm that JBoss sent emails to known JDO customers hours after the first failed JDO 2 ballot was made public. We had a developer on-site with a client when that client received one. The email that we saw wasn't as blatant as the the poster's quote above, but it linked to the ballot and its intent was clear. You might want to talk to JBoss' sales team if you disapprove. If left unchecked, I think all sales people have a tendency to get a little over-zealous :)

    Abe, I have confirmed with JBoss Marketing that this was message was *never* approved (our VP of marketing was insulted that I even had to ask), and that we most certainly did not do any mailout as was claimed, and that it is certainly not part of our strategy to target existing JDO customers. (The reponse I got back was "that's not how we do business".)

    I am in the process of checking with our sales organization to see if any of our sales people referenced the EC vote as part of the sales process, and it looks like we have exactly *one single instance* of this happening and, given the actual content of the email in question, and the context in which it was sent - as part of an ongoing discussion with a potential customer - I would say it was just barely "overzealous". Certainly the content was nothing like what was claimed by the original poster. Certainly the two quotations above did not appear (nor anything remotely similar). Certainly, it was accurate and made no false claims.

    (I mean, the idea that JBoss is targetting existing JDO customers is absurd on the face of it - that segment of the market is so small as to be not worth the effort. We are interested in expanding the market for ORM technology, not fighting over scraps.)
  34. arrogance[ Go to top ]

    I mean, the idea that JBoss is targetting existing JDO customers is absurd on the face of it - that segment of the market is so small as to be not worth the effort. We are interested in expanding the market for ORM technology, not fighting over scraps

    wonder why people don't like you guys at jboss?
  35. arrogance[ Go to top ]

    Over the past few years, I have done projects with TopLink, Hibernate, EJB CMP, JDO and have been successful with all of these solutions. But even though I have a lot of respect for Hibernate as a product, I regret to say that the incredible arrogance displayed by Gavin and Christian (see numerous examples in this thread alone) is eventually going to turn me away. Unless they take some lessons in modesty and have their egos downsized, I don't think we will be talking about Hibernate in three years time - except of course when cursing the idiots who developed these annoying "legacy" applications with it :-)
  36. Really?[ Go to top ]

    Over the past few years, I have done projects with TopLink, Hibernate, EJB CMP, JDO and have been successful with all of these solutions. But even though I have a lot of respect for Hibernate as a product, I regret to say that the incredible arrogance displayed by Gavin and Christian (see numerous examples in this thread alone) is eventually going to turn me away. Unless they take some lessons in modesty and have their egos downsized, I don't think we will be talking about Hibernate in three years time - except of course when cursing the idiots who developed these annoying "legacy" applications with it :-)

    Really?

    Are you basing your choice of a product on the level of arrogance of the product's leaders, rather than the own technical merits of that product?

    What if a TopLink executive posts one day some 'arrogant' message here? Are you going to turn away from TopLink too?

    What happened to 'the right tool for the right job'?

    You seem way too emotional for a developer.
  37. Huh?[ Go to top ]

    But even though I have a lot of respect for Hibernate as a product, I regret to say that the incredible arrogance displayed by Gavin...

    I think arrogance and confidence are often confused. The writer mistook Gavin's confidence, and competence for arrogance.

    I find Gavin's response to be measured and controlled. I am sure he resisted the urge to say what he was really thinking about Versant.

    I agree with Tony.
    What happened to 'the right tool for the right job'?
  38. Huh? +1[ Go to top ]

    I think arrogance and confidence are often confused. The writer mistook Gavin's confidence, and competence for arrogance.
    +1

    My POV is that when some marketing guys are lying everybody find it normal, that's the rule of commercial war.
    But when famous (or not, no matter) technical guys just explain things, it's arrogance.
    I don't think it's normal Gavin has to spend so much time explaining the way he feels and that Versant don't even say a simple "excuse Versant for the mistake".

    my 2 cents.
    Anthony
  39. lack of support[ Go to top ]

    Over the past few years, I have done projects with TopLink, Hibernate, EJB CMP, JDO and have been successful with all of these solutions. But even though I have a lot of respect for Hibernate as a product, I regret to say that the incredible arrogance displayed by Gavin and Christian (see numerous examples in this thread alone) is eventually going to turn me away. Unless they take some lessons in modesty and have their egos downsized, I don't think we will be talking about Hibernate in three years time - except of course when cursing the idiots who developed these annoying "legacy" applications with it :-)

    I have to say I agree with this statement. Having posted a few questions to the hibernate forums, I have noticed that many questions go unanswered, or receive unhelpful responses.

    Until this situation improves, its difficult for some to justify the use of hibernate
  40. lack of support[ Go to top ]

    I have to say I agree with this statement. Having posted a few questions to the hibernate forums, I have noticed that many questions go unanswered, or receive unhelpful responses. Until this situation improves, its difficult for some to justify the use of hibernate

    I had a similar experience a while back. I was coding up some persistence work which I needed to do some so-called 'batch processing', involving large transactions with tens of thousands of objects. Database independence was important to me so I was investigating JDO and Hibernate. Initially keen on Hibernate (I had heard good things about it) I turned and looked at the forums. What did I see? Statements that they were 'very skeptical of the idea that Java is the right place [to do this]', however they said they would 'swallow our pride, and accept that lots of people are actually doing this, and make sure they are doing it the Right Way'.

    At that point, I abandoned the idea of using Hibernate.

    I am not saying that the Hibernate people were wrong! What I was doing was almost certainly potentially innefficient and tricky to manage, but I was strongly discouraged from using a product that the designers said from the start was not designed for what I wanted to do. I also did not want to have the feeling I was being lectured at by superior minds if I were to ask a question.

    I went to a JDO vendor, got considerable friendly help, and managed to get the code working reasonably well. At no point did they state that I was misusing their product, and they felt no need to show this poor ignorant coder the 'Right Way'.

    Maybe I just like that old-fashioned 'the customer is always right' attitude...
  41. lack of support[ Go to top ]

    you have titled this "lack of support"

    let's go here: http://blog.hibernate.org/cgi-bin/blosxom.cgi/index.html?find=batch&plugin=find&path=
    and tell me if this is not the best support you can have to do batch processing with hibernate.

    The hibernate Team has helped 19235 times in the forum, go in the forum and check this!

    We love our community and help our friendly user (not customer, excuse me we haven't the same kind of relation with our community) the best we can, can you just realise how much work the documentation represent? All this for free! Our friendly Chinese, Japanese, French, Italian ... users spent a lot of time to translate the guide for FREE.

    I'm really disappointed by you guys, this topic was about lies from a particular vendor. We all have to fight against this.

    Now this topic is full of personnal attacks, unrelated debate about JDO and now what you are trying is to tell Hibernate is "evil".

    I thought, at least, you Steve wasn't like this, i had a lot of respect for you...

    Anthony
  42. not about lack of support[ Go to top ]

    you have titled this "lack of support"let's go here: http://blog.hibernate.org/cgi-bin/blosxom.cgi/index.html?find=batch&plugin=find&path=and tell me if this is not the best support you can have to do batch processing with hibernate.

    I apologise. My post was certainly not about lack of support - I lazily allowed the comment title to continue. I am not questioning the level of support given for Hibernate.
    Now this topic is full of personnal attacks, unrelated debate about JDO and now what you are trying is to tell Hibernate is "evil".

    I am not trying to attack anyone personally, or accuse anyone of being wicked or evil! The blogs/forums present the public face of an organisation or vendor. Surely it is fair for potential users or customers to judge an organisation by the nature and contents of comments they see there.

    I am simply explaining honestly something that put me, as a potential user, off of Hibernate. If I am considering whether or not to use a product for a major commercial development project, and I see a statement that they don't intend their product to be used in the way that I want to use it, of course that statement is going to be part of my decision about this (especially as I knew that certain JDO products had been used in the way I intended very successfully). I may well have been reading too much into the comments, but that is my perogative as a potential customer! I may have been dumb, and perhaps I should have respected their honesty. To see whether I was over-reacting, I showed the forums to a colleague. They agreed with me about my decision. Well, maybe that is just 2 people, and considering the huge success of Hibernate, they certainly need not worry about us, but there you go.
    I thought, at least, you Steve wasn't like this, i had a lot of respect for you...Anthony

    I hope I haven't damaged that respect too much!
  43. not about lack of support[ Go to top ]

    The blogs/forums present the public face of an organisation or vendor. Surely it is fair for potential users or customers to judge an organisation by the nature and contents of comments they see there. I am simply explaining honestly something that put me, as a potential user, off of Hibernate.
    Steve, I am the same kind of user as you are. If I can help then I will try to help you and I expect you will help me too. It is just a user forum not a marketing show. Probably it is not the case in marketing, but the right ansver is sometimes negative in user forum.
  44. Hibernate is free[ Go to top ]

    Maybe I just like that old-fashioned 'the customer is always right' attitude...

    The 'customer is always right' attitude was meant to matter when the customer was a paying customer.

    With a free product, you have to put up with forums, and eventually with some developers lecturing you. You have to swallow your pride sometimes. However you usually get good advice.

    If you can't deal with that (which you obviously couldn't), then open-source products are not for you. Go with commercial software with better support (which you obviously did), and dig into your pockets.
  45. Hibernate is free[ Go to top ]

    Maybe I just like that old-fashioned 'the customer is always right' attitude...
    The 'customer is always right' attitude was meant to matter when the customer was a paying customer.With a free product, you have to put up with forums, and eventually with some developers lecturing you. You have to swallow your pride sometimes. However you usually get good advice.If you can't deal with that (which you obviously couldn't), then open-source products are not for you. Go with commercial software with better support (which you obviously did), and dig into your pockets.

    I would expect some sort of 'customer is always right' attitude from any group or vendor that wanted me to use their product, free or not.

    I use open source products all the time. I find that you can't generalise about the nature of the forums or the attitude of developers. I disagree that commercial products necessarily have better support - I am not questioning at all the level of support for Hibernate, which I am sure is excellent. The documentation is first-rate.
  46. Hibernate is free[ Go to top ]

    I would expect some sort of 'customer is always right' attitude from any group or vendor that wanted me to use their product, free or not.

    Yet you cannot expect people in a forum for a free product to tell you that you're right if they feel that you're wrong.
    I use open source products all the time. I find that you can't generalise about the nature of the forums or the attitude of developers.

    I used the words 'eventually', 'some', 'sometimes'. I don't think those words lend themselves easily to generalization.
    You seemed to be surprised that some developers had lectured you in a public forum where you asked for help. That happens, sometimes.
    I disagree that commercial products necessarily have better support -


    ?? Never stated that all commercial products had better support. I only suggested to go with one that had better/friendlier support. Didn't you just do that?
  47. Hibernate is free[ Go to top ]

    I would expect some sort of 'customer is always right' attitude from any group or vendor that wanted me to use their product, free or not.
    Yet you cannot expect people in a forum for a free product to tell you that you're right if they feel that you're wrong.

    Fair enough. They did imply I (although not me personally - I was reading someone else's posts) was wrong (or rather, unwise). So I didn't use their product for what I was going to do. I used another product from a company that did not imply that what I was doing was unwise. They then worked with me to solve my problems. I'm sure that Hibernate would have done the same, but it was my decision as a potential customer to pick the vendor that did not consider what I was doing was unwise.

    I don't know why the emphasis is on 'free'. What I believe matters is whether or not a product is high quality (Hibernate certainly is) and whether or not a product wants to compete with others (I'm assuming Hibernate does). 'Free' is a bonus, though.
    I use open source products all the time. I find that you can't generalise about the nature of the forums or the attitude of developers.
    I used the words 'eventually', 'some', 'sometimes'. I don't think those words lend themselves easily to generalisation.

    You said:
    If you can't deal with that (which you obviously couldn't), then open-source products are not for you.

    I read that as open-source in general, as it was not qualified. I'm sorry if I misinterpreted you.
    You seemed to be surprised that some developers had lectured you in a public forum where you asked for help.

    They didn't. I hadn't posted anything. I was reading others posts.
    That happens, sometimes.

    Sure, but I am totally within my rights to allow that sort of lecturing to put me off using a product.
    I disagree that commercial products necessarily have better support -
    ?? Never stated that all commercial products had better support. I only suggested to go with one that had better/friendlier support. Didn't you just do that?

    Yes. I felt that your comment implied this. I wanted to make clear that I was not personally implying that open-source/free software can't have first-rate support.
  48. Hibernate is free[ Go to top ]

    Sure, but I am totally within my rights to allow that sort of lecturing to put me off using a product.

    Absolutely.

    I would not personnally behave the same way though.

    I would be more interested in finding the right tool for my project. And if I felt that Hibernate was the way to go for that particular project (and let's say I had no budget for a commercial product), then it would take more than some eventual lecturing by some developer(s) to put me off using that product.

    What I'm trying to say is that I'm more interested in the intrinsic quality of a given product and what it could do for me, than the attitude of some developer(s) in a forum that happen to know the product better than I do.
  49. Hibernate is free[ Go to top ]

    Sure, but I am totally within my rights to allow that sort of lecturing to put me off using a product.
    Absolutely. I would not personnally behave the same way though. I would be more interested in finding the right tool for my project. And if I felt that Hibernate was the way to go for that particular project (and let's say I had no budget for a commercial product), then it would take more than some eventual lecturing by some developer(s) to put me off using that product.

    Yes, but that wasn't the main thing that put me off.

    I wanted to do use ORM in a certain way, and had good reasons for this. Posts on the Hibernate forums from hibernate developers said that using ORM this way was not the really the right thing to do. I asked around and found that a users of a certain JDO implementation had been using ORM this way successfully. So I didn't use Hibernate. I didn't use that JDO implementation either! I used a cheaper JDO implementation from a different vendor, knowing I could switch to the more expensive one (or even free, open-source, implementations) if necessary. That is the beauty of multi-vendor specifications.
  50. The right tool[ Go to top ]

    Yes, but that wasn't the main thing that put me off.I wanted to do use ORM in a certain way, and had good reasons for this. Posts on the Hibernate forums from hibernate developers said that using ORM this way was not the really the right thing to do. I asked around and found that a users of a certain JDO implementation had been using ORM this way successfully. So I didn't use Hibernate. I didn't use that JDO implementation either! I used a cheaper JDO implementation from a different vendor, knowing I could switch to the more expensive one (or even free, open-source, implementations) if necessary. That is the beauty of multi-vendor specifications.

    1) If those developers were right, then Hibernate was not the right tool for your project. Therefore your choice of JDO was the right choice.

    2) If the developers were wrong, you had found an alternative that suited you anyway. And you seem pretty happy to have made that choice at the present time.

    So what's the problem?
  51. The right tool[ Go to top ]

    1) If those developers were right, then Hibernate was not the right tool for your project. Therefore your choice of JDO was the right choice.2) If the developers were wrong, you had found an alternative that suited you anyway. And you seem pretty happy to have made that choice at the present time.So what's the problem?

    Turns out I probably could have used Hibernate, and it could well have worked OK. They lost a potential user because of an 'I wouldn't do that if I were you' attitude to what I was intending to use ORM for.

    But, as you say, I am happy. The problem is theirs, although it probably isn't, as I guess they would not want a whining pest like me a customer/user!
  52. Hibernate is free[ Go to top ]

    then open-source products are not for you. Go with commercial software with better support (which you obviously did), and dig into your pockets.
    And be prepared for an answer that makes you happy (at least first) but will be wrong for your situation.
  53. Hibernate is free[ Go to top ]

    then open-source products are not for you. Go with commercial software with better support (which you obviously did), and dig into your pockets.
    And be prepared for an answer that makes you happy (at least first) but will be wrong for your situation.

    Heh. Rather cynical, perhaps?

    In my case I got a 'here's how to work around this' answer, followed by an update to the product that fixed the matter permanently.

    One of the reasons I like using multi-vendor implemented specifications is that I can easily take my code and money elsewhere if I don't like support from a Vendor. Choice is good.

    (Of course, now am I more familiar with Spring than I used to be I realise I can switch reasonably easily between Hibernate and JDO... but that is another matter).
  54. Hibernate is free[ Go to top ]

    Heh. Rather cynical, perhaps?
    Probably. But reality none the less. "The love of money is the root of all evil." Of course power and fame corrupt too. :)
    One of the reasons I like using multi-vendor implemented specifications is that I can easily take my code and money elsewhere if I don't like support from a Vendor. Choice is good.(
    Yes, choice is good. That is why I prefer Java over .Net and why I am careful not to code to a container, etc. My comment was an OSS vs Commercial rather than Hibernate vs JDO.
  55. lack of support[ Go to top ]

    I was strongly discouraged from using a product that the designers said from the start was not designed for what I wanted to do.

    Hibernate needs to keep stuff in memory to use cases and you need to find an alternative way to solve your problem, and I see you found it. It means this forum was very helpfull and honest, is not it ?
  56. lack of support[ Go to top ]

    I am not saying that the Hibernate people were wrong! What I was doing was almost certainly potentially innefficient and tricky to manage, but I was strongly discouraged from using a product that the designers said from the start was not designed for what I wanted to do. I also did not want to have the feeling I was being lectured at by superior minds if I were to ask a question.
    So, you prefer vendor that does what you want to the honest people who tell you truth about a product and what to do best...
    Unfortunately it is way too common approach.
  57. lack of support[ Go to top ]

    I am not saying that the Hibernate people were wrong! What I was doing was almost certainly potentially innefficient and tricky to manage, but I was strongly discouraged from using a product that the designers said from the start was not designed for what I wanted to do. I also did not want to have the feeling I was being lectured at by superior minds if I were to ask a question.
    So, you prefer vendor that does what you want to the honest people who tell you truth about a product and what to do best.

    No. Having decided to use ORM in a particular way, and with a good understanding of the problems involved, I decided to go with a vendor that was willing to work with me to solve my problem, and not with a vendor that would help me, but only after first having said that what I was doing was the wrong way to use their product! I didn't need to be told what to do by a vendor - I had good reasons for what I was doing.
  58. lack of support[ Go to top ]

    "The right tool for the job" is an ETL tool in this case
    ( Extract Transform Load ), is not it ? I think It is very exotic to use ORM as persistence tool, but it is more exotic to use it as ETL tool.
  59. lack of support[ Go to top ]

    "The right tool for the job" is an ETL tool in this case ( Extract Transform Load ), is not it ? I think It is very exotic to use ORM as persistence tool, but it is more exotic to use it as ETL tool.
    Cool! I always wanted to be exotic and doing something exotic.

    Really, there is no reason it couldn't be used WITH the ETL. Except that I don't know of any that support it. It would be nice to use something that already knows how to persist the transformed "data" and can apply validations. I've been through the pain - multiple times - of not having it.

    Why is that only user interfaces need to use OO techniques? In my mind, Browsers, Rich Clients, Reports, external systems and etc are all "UIs".
  60. lack of support[ Go to top ]

    Cool! I always wanted to be exotic and doing something exotic.Really, there is no reason it couldn't be used WITH the ETL.
    There is no code ("objects") in "typical" ETL projects. ETL tools exist for this reason. "Custom" solutions are not trivial too, it is needed if tool designed for this use case fails to solve problem and you need to implement a better tool in this case.
  61. There is no code ("objects") in "typical" ETL projects.
    True. Doesn't mean there shouldn't be.
     ETL tools exist for this reason.
    Sure. But they could use objects. But people are trained to think "Data". So no one has created a OO ETL tool. HMMMMMM.
    "Custom" solutions are not trivial too, it is needed if tool designed for this use case fails to solve problem and you need to implement a better tool in this case.
    Each transformation IS custom.
  62. People are trained to think about it as "Data" for a reason (ETL experts think in "GB" and "record count" terms). Transformation rules are the same for any data (there is a finite set of rules in ETL tools, but you can customise it using some "script" ). This kind of tools "abstracts" from domain, if you are ETL expert in some domain then you can reuse you knowlege in any domain (conceptual and logical model difference exists for this reason too).
    I see, I started to advocate ETL :)
  63. lack of support[ Go to top ]

    I have to say I agree with this statement. Having posted a few questions to the hibernate forums, I have noticed that many questions go unanswered, or receive unhelpful responses. Until this situation improves, its difficult for some to justify the use of hibernate
    out of topic???
    what's the problem?

    Let's answer,
    Hibernate is free, that doesn't mean you'll have all the support you need for free.
    If you need strong support, that is normal, let's get some commercial support from JBoss (note: i'm not working for JBoss).

    Have you, at least, already helped another user on hibernate forum?
    We try to do our best to help our community but when:
       - we see the topic is covered by the reference guide
       - or by another famous topic
       - or by the wiki
       - or when the poster doesn't give the informations needed to receive help (mapping file, java code, stracktrace)
    of course we just cannot help or prefer spending our FREE time with users that really need help.

    Anthony
  64. Sheer hypocrisy![ Go to top ]

    Gavin -

    I guess it is possible that we happened to have a developer on site with the one company JBoss targeted with an email using the initial JDO 2 ballot as marketing fodder. It seems extremely unlikely, but possible. However, note that our on-site developer has never heard of the original poster's name, and this was an existing Kodo customer (not a competitive eval situation where you'd be in "ongoing discussions"). So it is also possible that multiple emails were sent. As I said, we appreciate that sales people get a little carried away at times.
  65. Sheer hypocrisy![ Go to top ]

    Gavin -I guess it is possible that we happened to have a developer on site with the one company JBoss targeted with an email using the initial JDO 2 ballot as marketing fodder. It seems extremely unlikely, but possible. However, note that our on-site developer has never heard of the original poster's name, and this was an existing Kodo customer (not a competitive eval situation where you'd be in "ongoing discussions"). So it is also possible that multiple emails were sent. As I said, we appreciate that sales people get a little carried away at times.

    Abe, I am almost certain that the poster above is posting using an alias, since he/she has no TSS posting history, and google has never heard of the name. And they have not come forward with any further evidence. Basically this is someone trying to smear JBoss with fabricated claims.

    I'm not ruling out that there might have been more than one email mentioning the EC vote, but if so, our sales people are not owning up to it ;-)

    Certainly I can rule out that anyone ever sent any emails with the language claimed by the original poster. It's simply not our style.
  66. Sheer hypocrisy![ Go to top ]

    Gavin,

    Please do not call our customers "scraps" - it is offensive to them and to us. You are employing the classic sales / marketing technique of discounting the competition publicly to create a false perception of weakness.

    Meanwhile, whether the aforementioned email was a one-off incident or not, even you admit that a JBoss sales rep targeted Kodo customers. Considering how sales reps are compensated, it is probably safe to assume that the sales rep did not think the segment was too small to go after. This is not surprising because we have a strong and large paying customer base (of hundreds of companies). These customers are as happy and passionate about Kodo as your users seem to be about Hibernate. These supposed "scraps" played a large role in influencing the approval of the vote on the JDO 2 Public Draft Ballot, as I believe the JBoss rep on the JCP EC is well aware.

    Neelan Choksi
    President, SolarMetric
  67. whatever[ Go to top ]

    Gavin,Please do not call our customers "scraps" - it is offensive to them and to us.

    Wow, Neelan, that is an especially uncharitable interpretation of my sentence. Certainly not the interpretation I intended.

    But that's TSS for you.

    And this is my last post, got better things to do...
  68. Sheer hypocrisy![ Go to top ]

    (I mean, the idea that JBoss is targetting existing JDO customers is absurd on the face of it - that segment of the market is so small as to be not worth the effort. We are interested in expanding the market for ORM technology, not fighting over scraps.)

    Brutal quote Gavin. Just brutal.

    Even though I am a happy JDO user, I often like to listen to your presentations and posts because you seem to be a very intelligent individual who has created a very nice ORM product.

    BUT, when you say things like this it really turns me (and I'm sure others) off. JDO is alive and well in a large amount of customer sites. JDO market penetration can hardly be characterized as "scraps!"
  69. Sheer hypocrisy![ Go to top ]

    (I mean, the idea that JBoss is targetting existing JDO customers is absurd on the face of it - that segment of the market is so small as to be not worth the effort. We are interested in expanding the market for ORM technology, not fighting over scraps.)
    Brutal quote Gavin. Just brutal. Even though I am a happy JDO user, I often like to listen to your presentations and posts because you seem to be a very intelligent individual who has created a very nice ORM product. BUT, when you say things like this it really turns me (and I'm sure others) off.

    Tony, I had meant to dead this discussion there, but since you stroked my ego - which everyone here seems to agree is just *so* enormous - by complimenting me, I'll explain what I really meant.

    I'm dead serious about not fighting over scraps.

    Let me explain:

    There are hundreds of thousands of projects out there who are struggling with inappropriate persistence technologies. That is a huge market for ORM technology, and a huge number of people whose lives we can make a little bit easier. Hibernate is used today in tens of thousands of projects, and we are making a very nice business helping some of these projects build applications using Hibernate. That's just great. We have plenty of growth potential for our business among just those existing Hibernate users.

    But, when you are in a market leader position as we are, you are always thinking about how you can expand the market for your technology (I intentionally say "technology", not "product"). This is why we have been so keen on EJB3. We see it as the key to making ORM technology adoptable to the main stream, ie. to the hundreds of thousands of people out there who simply aren't able to use the latest new 'n cool thing on javablogs. For this, we need the power of J2EE.

    The absurdity I referred to is the idea that to grow we would be targetting Kodo users. According to Solarmetric they have hundreds of customers. OK, so how many of those customers could we realistically turn into paying Hibernate customers? Five? Ten? Twenty perhaps? And how many toes would we step on along the way to gaining ten new customers? No-one could possibly seriously suggest that this is our strategy!

    These ten customers we might be able to steal from Solarmetric are indeed "scraps", compared to the thousands of customers we expect to gain by having ORM become a first-class citizen in J2EE.

    This is the real difference between the worldview of the market leader - who grows business by growing the total market - and the niche player - who grows business by trying to take customers from the leader. Hence you see why our strategy is so different to Versant's, for example. There is simply nothing to be gained by us attacking our competitors.

    I hope that makes more sense to you now.

    Cheers,
  70. Sheer hypocrisy![ Go to top ]

    (I mean, the idea that JBoss is targetting existing JDO customers is absurd on the face of it - that segment of the market is so small as to be not worth the effort. We are interested in expanding the market for ORM technology, not fighting over scraps.)
    Brutal quote Gavin. Just brutal. Even though I am a happy JDO user, I often like to listen to your presentations and posts because you seem to be a very intelligent individual who has created a very nice ORM product. BUT, when you say things like this it really turns me (and I'm sure others) off.
    Tony, I had meant to dead this discussion there, but since you stroked my ego - which everyone here seems to agree is just *so* enormous - by complimenting me, I'll explain what I really meant.I'm dead serious about not fighting over scraps.Let me explain:There are hundreds of thousands of projects out there who are struggling with inappropriate persistence technologies. That is a huge market for ORM technology, and a huge number of people whose lives we can make a little bit easier. Hibernate is used today in tens of thousands of projects, and we are making a very nice business helping some of these projects build applications using Hibernate. That's just great. We have plenty of growth potential for our business among just those existing Hibernate users.But, when you are in a market leader position as we are, you are always thinking about how you can expand the market for your technology (I intentionally say "technology", not "product"). This is why we have been so keen on EJB3. We see it as the key to making ORM technology adoptable to the main stream, ie. to the hundreds of thousands of people out there who simply aren't able to use the latest new 'n cool thing on javablogs. For this, we need the power of J2EE.The absurdity I referred to is the idea that to grow we would be targetting Kodo users. According to Solarmetric they have hundreds of customers. OK, so how many of those customers could we realistically turn into paying Hibernate customers? Five? Ten? Twenty perhaps? And how many toes would we step on along the way to gaining ten new customers? No-one could possibly seriously suggest that this is our strategy!These ten customers we might be able to steal from Solarmetric are indeed "scraps", compared to the thousands of customers we expect to gain by having ORM become a first-class citizen in J2EE.This is the real difference between the worldview of the market leader - who grows business by growing the total market - and the niche player - who grows business by trying to take customers from the leader. Hence you see why our strategy is so different to Versant's, for example. There is simply nothing to be gained by us attacking our competitors.I hope that makes more sense to you now.Cheers,

    Yes it does. You are back in my good books now Gavin. :-)

    I wish you and all the persistence vendors all the best in growing the market for POJO based ORM via JSR-220. As a happy user of one of the prevelant persistence solutions (JDO), I just hope that JSR-220 has the best features of Hibernate, JDO, TopLink, etc.

    The new unified persistence spec absolutely cannot be a step back. I trust that you Mr. King will help to see that happen.
  71. Hibernate paying customers[ Go to top ]

    According to Solarmetric they have hundreds of customers. OK, so how many of those customers could we realistically turn into paying Hibernate customers?

    What is a paying Hibernate customer?
    How many Hibernate users are paying ones?
    How much do they pay for it?

    Best Regards, Eric.
  72. Count yourself[ Go to top ]

    Since this is now also used to drive flame wars and ad impressions on TSS:

    Of about 40 claims presented in the Versant marketing mail, more than 30 are actually completely false for Hibernate 2.x as well. This is not about 3.0 having a "final" in the name or not. See my comments to the blog entry for the reasons.
  73. and it's fun![ Go to top ]

    ...and it is always amusing to read about people that didn't do their homework properly!
    This is even more fun than some of the cartoons/jokes posted here... ;-)
  74. Never even heard of them. The top dog always gets attacked. Let your product and user base speak for itself.
  75. Hibernate 3.0[ Go to top ]

    A frequent problem I have run into with ORM systems is where the enterprise stores data in different databases depending on the customer or the age of the data.

    So, the data in an Orders object might be stored in:

    CustomerA..Orders
    CustomerB..Orders
    .
    .

    or it could be:

    History1998..Orders
    History1999..Orders
    .
    .

    (Please don't give advice for redesigning schemas, these are large enterprises where I don't control such things...)

    The database name can be dynamically computed based on the characteristics of the Order object, but in Hibernate 2.x the only way to map this is to create an explicit mapping/class for each database (not workable).

    Does Hibernate 3.0 have a way to handle this sort of mapping? I have reviewed the new features in Hibernate 3.0, and it is not obvious to me that there is any relief here.

    Do JDO products handle this sort of use-case?
  76. Better ask this on the forum[ Go to top ]

    Have a look at NamingStrategy, possibly ConnectionProvider, and the new Filters in H3. You could also easily create different SessionFactories from the same mapping/Configuration, no need to map it twice.
  77. Multiple DB access[ Go to top ]

    Hibernate 2.x supports multiple DB access through multiple configurations doesn't it? I'm pretty sure you can use the same mapping files to support access to the same schema on seperate DBs/connect strings.

    So have a CustomerA, B, History1998, History1999 configurations. Depending on the incoming data, choose the appropriate config (or cached SessionFactory) and Hibernate as usual.

    I haven't done this yet, but it seemed possible.
  78. Multiple DB access[ Go to top ]

    It is possible - I'm currently using cached SessionFactories for accessing many Oracle accounts (in the same database though) fetching connections from a static C3P0 pool through a facade connection provider. The configuration of each SessionFactory instance is done at creation time (runtime) and is pretty trivial (just setting the right default_schema)
  79. Hibernate 3.0[ Go to top ]

    A frequent problem I have run into with ORM systems is where the enterprise stores data in different databases depending on the customer or the age of the data.So, the data in an Orders object might be stored in:CustomerA..OrdersCustomerB..Orders..or it could be:History1998..OrdersHistory1999..Orders..(Please don't give advice for redesigning schemas, these are large enterprises where I don't control such things...)
    "CREATE VIEW ... " ?
  80. "Create View.."[ Go to top ]

    Create View only works well if the databases are from the same vendor.

    Many times the legacy database might be on Sybase, DB2, etc.. and the current development is happening on Oracle or something else.

    Instead of replicating the data to the new database, it is nice if the OR Mapping tool can handle this for you.
  81. Hibernate 3.0[ Go to top ]

    "CREATE VIEW ... " ?

    Create View is a wonderful solution for read-only data. Sadly, the data I am working with is read-write. Thanks anyway.
  82. Hibernate 3.0[ Go to top ]

    "CREATE VIEW ... " ?
    Create View is a wonderful solution for read-only data. Sadly, the data I am working with is read-write. Thanks anyway.
    This stuff is updatable and can "join" different vendors, this king of products are known as "distributed database" or "gateways" some RDBMS vendors provide this kind of products too ( they implement competitor protocols too ). I am not distributed database expert, but I am sure it is possible to find consultants.
  83. Hibernate 3.0[ Go to top ]

    Yes, Corby, this is possible using the Hibernate 3.0 notion of a "named entity". You can even implement Interceptor.getEntityName() to decide automatically which named entity an object is an instance of. :-)
  84. Hibernate 3.0[ Go to top ]

    Yes, Corby, this is possible using the Hibernate 3.0 notion of a "named entity". You can even implement Interceptor.getEntityName() to decide automatically which named entity an object is an instance of. :-)

    Thank you very much, Gavin. I will start researching this.
  85. Such slandering is what causing the market to get fragmented and then wither away in long run. Microsoft must be snikering seeing all this goofy political projectiles being fired from both sides. To implement the divide-and-rule policy they dont have to do anything but let the concerned parties beat up each other.

    Such bikering doesnt send the right message to corporate big-wigs. Developers understand but CIO, EVP and VPs dont. I suppose, if we want to survive as a whole then such drama doesnt help. Let the darwins theory of evolution decide if JDO wins the race or hibernate does!
  86. Microsoft must be snikering seeing all this goofy political projectiles being fired from both sides.
    I agree! I think the same religion-war is happening for frameworks (Tapestry, Struts, JSF, Spring...).
  87. Such slandering is what causing the market to get fragmented and then wither away in long run. Microsoft must be snikering seeing all this goofy political projectiles being fired from both sides. To implement the divide-and-rule policy they dont have to do anything but let the concerned parties beat up each other.Such bikering doesnt send the right message to corporate big-wigs. Developers understand but CIO, EVP and VPs dont. I suppose, if we want to survive as a whole then such drama doesnt help. Let the darwins theory of evolution decide if JDO wins the race or hibernate does!

    Bickering and slander?

    I thought the Hibernate response was extremely informative and professional.
  88. sorry, should have been more clear. Yes, Galvin's response was the best anyone could possibly come up. But if this was done as a general study it would have been even better but it was meant as a rebuttal to Versant's claims!

    In the realm of technology, one can research competing technologies carefully, study aspects, publish the result of the the studies and then start making claims. Unforunately, as I understand it, people are taking taking shortcuts to making claims.

    What I am saying is - this is not healthy. One cannot claim to be pretty by rubbing charcoal on others face. Claims should be the result of through study and should not lead to bickering among developers taking sides.
  89. sorry, should have been more clear. Yes, Galvin's response was the best anyone could possibly come up. But if this was done as a general study it would have been even better but it was meant as a rebuttal to Versant's claims! In the realm of technology, one can research competing technologies carefully, study aspects, publish the result of the the studies and then start making claims. Unforunately, as I understand it, people are taking taking shortcuts to making claims.What I am saying is - this is not healthy. One cannot claim to be pretty by rubbing charcoal on others face. Claims should be the result of through study and should not lead to bickering among developers taking sides.

    Agreed. You will notice that aside from Versant, all vendors and open source projects in this space have shied away from publishing this kind of material about competitors. ORM products are extremely complex, and it is difficult to get a really thorough understanding of any one product without having worked with it for many months, built real applications with it, and learned its real strengths and limitations.

    So, we don't produce these kinds of documents about TopLink or Kodo, and vice versa. At least, when we do perform these kinds of evaluations, it's for "internal consumption only".

    Versant have decided to go down the path of very aggressive anti-Hibernate marketing (with this document, and their equally misleading "Hibernate or JDO" webinar, which was all over google ads for months), and I think that's very unfortunate. The whole Java persistence space already has enough FUD and ill-feeling, we didn't need more now, especially not when the successful vendors in this space are now all making an honest, concerted effort to work together on the EJB 3.0 persistence standard. I had been seeing a real thawing of relationships over the last few weeks.

    I guess we could have ignored this longer, but if you don't respond at some stage, a lot of people will start to assume that these things are actually *true*. :-(
  90. First off, full disclosure: I am a huge Hibernate fan and to some extent, evangelist. I enjoy using it, especially behind Spring. Also, I have not used JDO, so obviously I am biased.

    Okay, now to play devil's advocate: In reading Gavin's blog I couldn't help but notice phrases like "Hibernate has oodles of features that Versant Open Access JDO does not have" and "Hibernate 3.0 offers ... oodles of options for performance tuning." This while himself criticizing Versant of using the phrase "several orders of magnitude better." He says, "How did they measure 'several orders of magnitude better'? With a tape measure?"

    While his points are probably true, if one is going to make an argument about measurement terminology, one should probably shy away from a word like "oodles."
  91. oodles and such..[ Go to top ]

    I agree with you, David. Gavin does sound a little unbalanced in his reply, and I couldnt help but wonder at times why he didnt stick to his initial intention of just ignoring the versant mail.
    Had I not recently started to use Hibernate in production and testing some of the more advanced features, I would have concluded that he has something to hide - but I know better than that. I can image it is no fun to run up against hibernate with a commercial product.

    christian
  92. interesting spin[ Go to top ]

    It's interesting how "marketing" material from company A can be positioned as "spam" and an "attack" while marketing material from company B can be spun as a "response". B sounds much more reasoned that way doesn't it? How on earth did this get onto TSS as a news story?
  93. interesting spin[ Go to top ]

    It's interesting how "marketing" material from company A can be positioned as "spam" and an "attack" while marketing material from company B can be spun as a "response". B sounds much more reasoned that way doesn't it? How on earth did this get onto TSS as a news story?

    "spam" means mass unsolicited emailing of marketing materials, correct? This is obviously a perfect description of the document in question, and how it came to fall into our hands.

    "attack" seems a perfect description of a document which spends most of its wordage making negative (and mostly false) claims about another product.

    Reasonable people can agree on that much, surely?

    "response" seems a perfect description of a blog entry which debunks the false claims of the orginal document, by correcting the record on the capabilities of the product which was "attacked".

    The only "spin" that is going on is the red-herring claim that my response depends upon capabilities of Hibernate 3.0. As Christian wrote on a blog comment: "Of about 40 claims presented here, more than 30 are actually completely false for Hibernate 2.x as well." My response was NOT Hibernate 3.0 specific, and I clearly labelled exactly where I referred to capabilities of Hibernate 3.0, leaving no room for confusion on these points.

    And, given that the production-readiness of Hibernate 3.0 was already announced everywhere, including the Hibernate website, this news site, and in official JBoss press releases, there is some definite disingeneous straw-grasping taking place here. At the very least, in this situation, Versant should have named the version of Hibernate that was evaluated. Every other product evaluation document I have ever seen makes clear the product version that was evaluated.

    (FTR, we did not post this item to TSS, so take that up with the management.)
  94. interesting spin[ Go to top ]

    It's interesting how "marketing" material from company A can be positioned as "spam" and an "attack" while marketing material from company B can be spun as a "response". B sounds much more reasoned that way doesn't it? How on earth did this get onto TSS as a news story?

    It's interesting mostly because of the refutations. It's been shown elsewhere that making a wrong claim is better than no claim at all, because people will crawl out of the woodwork to correct you if you're publicly wrong. Thus, while Gavin's marketspeak is ... well... marketspeak, the bullet points he makes are interesting largely because they're in one place.
  95. Background on Versant JDO[ Go to top ]

    Versant's JDO product used to be called JDO Genie. JDO Genie was built by a small consulting company called Hemtech based out of Africa. They had a small team led by David Tinker and their product was an excellent JDO implementation. Versant purchased JDO Genie a few months back and I believe some of the original team continues to work on the product.

    The tool is great but that's more of a testament to the folks at Hemtech than Versant. The support we received after the acquisition was certainly less helpful than that which we receieved before it. It will be interesting to see if Versant can keep the same customer base that supported Hemtech so much.

    Lastly, I always find it disturbing when any company launches a campaign to deface another company or their product. Of course that's business to some extent but as a developer I find that the general demeanor of a company and the quality of their products are often consistent. I think it would behoove Versant to take a different approach and play nice, especially with the open source community.
  96. Background on Versant JDO[ Go to top ]

    Versant's JDO product used to be called JDO Genie. JDO Genie was built by a small consulting company called Hemtech based out of Africa. They had a small team led by David Tinker and their product was an excellent JDO implementation. Versant purchased JDO Genie a few months back and I believe some of the original team continues to work on the product.The tool is great but that's more of a testament to the folks at Hemtech than Versant. The support we received after the acquisition was certainly less helpful than that which we receieved before it. It will be interesting to see if Versant can keep the same customer base that supported Hemtech so much.Lastly, I always find it disturbing when any company launches a campaign to deface another company or their product. Of course that's business to some extent but as a developer I find that the general demeanor of a company and the quality of their products are often consistent. I think it would behoove Versant to take a different approach and play nice, especially with the open source community.

    BTW, don't blame David Tinker for this fiasco. I suspect that this was a ploy concocted by the marketing geniuses at Versant who are probably fighting for their jobs at this point.

    -Mike
  97. Background on Versant JDO[ Go to top ]

    JDO Genie was built by a small consulting company called Hemtech based out of Africa.
    Africa? Which country?
    Africa is a continent.
  98. Background on Versant JDO[ Go to top ]

    JDO Genie was built by a small consulting company called Hemtech based out of Africa.
    Africa? Which country?Africa is a continent.

    Michael is probably from the USA.
    US citizens usually think that europe is one country, too.
    ;-)
  99. europe is one country[ Go to top ]

    LOL! It goes both ways. I know this is a technical site, but I just have to respond:

    Example 1: I live in New York. What does that mean to you? For *everyone* I met when I was in England and Wales a few years back, that meant New York City. Nope. I live over 5 hours from there, in a small upstate town that no one knows. Of course, I've heard the same thing from other USA citizens that live on the west coast...

    Example 2: When my mother-in-law had relatives from the Netherlands come to visit, they wanted to *drive* to see the Statue of Liberty AND the Grand Canyon all in the same weekend. Yeah right; there's probably a couple thousand mile (or should I say kilometer?) difference there. Problem is that one US state is often the same size as one European country. You can't drive across the US in a day like you can with many European countries.

    Example 3: When someone says "America" what do you think of? Probably the United States of America. Of course, North America also contains Canada and Mexico, then there are Central American countries, and South American countries. The USA does not own the term "America" in my mind. In fact, even "the United States" is not specific enough. The official name for Mexico is "Los Estados Unidos de Mexico," which means "The United States of Mexico."

    Anway, it's all just what you're experience has been. Yes, there is ignorance everywhere, which is very unfortunate. Travel boooks tell people from the USA to say they're from Canada for safety reasons. If people know you're from the USA, you could end up getting your head chopped off, even if you were part of the 49% of people who did NOT vote for our current president...

    All in peace and understanding,
    David
  100. europe is one country[ Go to top ]

    And I don't see anything wrong with generically saying Africa. It was true. You might as well demand the exact address.
  101. europe is one country[ Go to top ]

    And I don't see anything wrong with generically saying Africa. It was true. You might as well demand the exact address.
    And I don't see anything wrong with generically saying Earth. It was true. You might as well demand the exact address.

    So you won't mind me referring to the USA as "North America"
  102. europe is one country[ Go to top ]

    And I don't see anything wrong with generically saying Africa. It was true. You might as well demand the exact address.
    And I don't see anything wrong with generically saying Earth. It was true. You might as well demand the exact address.So you won't mind me referring to the USA as "North America"
    He wasn't referering to South Africa AS Africa. But, sure, you can say I am from North America - or the Americas. But don't say I am from Canada! :)
  103. europe is one country[ Go to top ]

    So you won't mind me referring to the USA as "North America"

    As I said, there are 3 countries in North America, so that would not be accurate. But no, I don't care what you call it. I was just trying to make a point that geo-political ignorance abounds no matter where you're from.
  104. europe is one country[ Go to top ]

    So you won't mind me referring to the USA as "North America"
    As I said, there are 3 countries in North America, so that would not be accurate. But no, I don't care what you call it. I was just trying to make a point that geo-political ignorance abounds no matter where you're from.
    Neither is grammatical and contextual ignorance. (not refering to you David)
  105. Huh?[ Go to top ]

    Michael is probably from the USA. US citizens usually think that europe is one country, too. ;-)

    I've never met a single person from the U.S.A. who thinks Europe is a country, and I travel the U.S.A. quite a bit.
  106. Huh?[ Go to top ]

    Michael is probably from the USA. US citizens usually think that europe is one country, too. ;-)
    I've never met a single person from the U.S.A. who thinks Europe is a country, and I travel the U.S.A. quite a bit.
    Well, here in the South (USA - South of the Mason Dixon) - if we check the Redneck Dictionary we find that Europe is what you are when the alarm goes of on the opening day of hunting season. "Hey Billy Joe - Europe? Lets go get a buck or doe one." :P
  107. Huh?[ Go to top ]

    - if we check the Redneck Dictionary we find that Europe is what you are when the alarm goes of on the opening day of hunting season. "Hey Billy Joe - Europe? Lets go get a buck or doe one." :P

    I had always thought 'european' in Redneck land was when you had too much beer and you needed to release yourself, like:

    "Hey Billy, turn the other way, european on my boots."
  108. Huh?[ Go to top ]

    - if we check the Redneck Dictionary we find that Europe is what you are when the alarm goes of on the opening day of hunting season. "Hey Billy Joe - Europe? Lets go get a buck or doe one." :P
    I had always thought 'european' in Redneck land was when you had too much beer and you needed to release yourself, like:"Hey Billy, turn the other way, european on my boots."
    What a difference 2 letters makes! :)
  109. Background on Versant JDO[ Go to top ]

    JDO Genie was built by a small consulting company called Hemtech based out of Africa.
    Africa? Which country?Africa is a continent.

    South Africa
  110. Lifecycle[ Go to top ]

    I work with Hibernate and I love it, however I deeply agree with the following critics regarding lifecycle states:
    The lifecycle states in Hibernate are not only insufficient, but also incomplete in their implementation.
    Oh really? Got any argument to back this up?
    Oh, here we go, one "example"...
    For example, the update callback in Hibernate which is used to notify when an objects state has changed and is going to be updated in the database is only called when the object is a transient object and being sent back for update. It is not called on any change of a persistent object that will cause an update to the database.
    This shows that the writer of the document does not really know Hibernate. The Lifecycle.onUpdate() callback is used to notify the application when a detached object is becoming managed via a call to update(). There is a completely different callback - Interceptor.onFlushDirty() - which is used to notify the application that a SQL UPDATE is about to occur. I'm not sure why the author could not find this callback, which is heavily documented and well-understood in the community.

    To clear up any doubts about the lifecycle model defined by Hibernate: the model is identical to the lifecycle used by TopLink and standardized by JSR-220 (EJB 3.0).

    I used to work with TopLink and by my experience it had much better support of lifecycle methods than Hibernate. The lifecycle was associated with "managed object" and not with the session.
  111. Lifecycle[ Go to top ]

    Here is a link to TopLink documentation: http://oraclelon1.oracle.com/docs/cd/B14099_04/web.1012/b10313/mapping.htm#1153917
  112. Lifecycle[ Go to top ]

    I used to work with TopLink and by my experience it had much better support of lifecycle methods than Hibernate. The lifecycle was associated with "managed object" and not with the session.

    Dominik, we usually refer to this kind of functionality as "events" or "callbacks". (To me, "lifecycle" means the user-visible states an instance of a persistent class can take on.)

    I think you'll be happy to know that the Hibernate 3.0 event architecture offers much a more sophisticated event/callback model than Hibernate 2.1. Let us know if you see any missing functionality there, we are very openminded about improvements in this area.

    Cheers.
  113. Lifecycle[ Go to top ]

    I think you'll be happy to know that the Hibernate 3.0 event architecture offers much a more sophisticated event/callback model than Hibernate 2.1. Let us know if you see any missing functionality there, we are very openminded about improvements in this area.Cheers.

    Thanks for the information. I have checked the Hibernate 3.0 API for event support and I think it is a great innovation by comparison with Hibernate version 2.

    However, I couldn't notice from the documentation, if it is possible for a persistent class interested in certain event triggered on its instances to simply just implement a suitable event interface (without need of any configuration). As much as I have understood, Hibernate event listeners have to be registered with a session and are not specific to concrete persistent class. That could be useful too, but often it is more practical to have events associated with specific persistent class.
  114. Lifecycle[ Go to top ]

    I think you'll be happy to know that the Hibernate 3.0 event architecture offers much a more sophisticated event/callback model than Hibernate 2.1. Let us know if you see any missing functionality there, we are very openminded about improvements in this area.Cheers.
    Thanks for the information. I have checked the Hibernate 3.0 API for event support and I think it is a great innovation by comparison with Hibernate version 2.However, I couldn't notice from the documentation, if it is possible for a persistent class interested in certain event triggered on its instances to simply just implement a suitable event interface (without need of any configuration). As much as I have understood, Hibernate event listeners have to be registered with a session and are not specific to concrete persistent class. That could be useful too, but often it is more practical to have events associated with specific persistent class.

    Certainly, it is very trivial to implement your application-specific event listener interfaces and do "if (object instanceof MyInterface) ..." in the Hibernate event listener.

    This has the huge advantage of *not* making your object model dependent upon Hibernate-specific interfaces.
  115. At least it didn't say that you weren't POJO-based! (In one of their presentations they claimed that TopLink was not POJO-based. Kind of like saying Newton was not a mathematician...)

    That kind of advertising is not appropriate. As mentioned, people should just try products out for themselves and see what works for them. If someone believes in their product they will want people to see it and discern the truth, not swallow stuff on glossies or PPT slides.

    Just one correction to the blog, though. TopLink does support recoverability in the face of runtime exceptions, we just don't think that it is a good idea in the middle of a database transaction, e.g. on UnitOfWork commits (which is why I am arguing that EJB 3.0 should not allow it).
    Gavin concludes:
    Hibernate can boast tens of thousands of satisfied users; why should they start paying for a closed source solution to a problem which is now very effectively solved by free software?

    Well, I can think of some reasons...but we can discuss those offline :-)

    -Mike
  116. Hibernate responds to Versant attacks[ Go to top ]

    Just one correction to the blog, though. TopLink does support recoverability in the face of runtime exceptions, we just don't think that it is a good idea in the middle of a database transaction, e.g. on UnitOfWork commits (which is why I am arguing that EJB 3.0 should not allow it).

    OK, but I think that's what I mean. I think we are the same on this. But let's discuss it elsewhere. Again, I'm very, very openminded on this one.
    Gavin concludes: Hibernate can boast tens of thousands of satisfied users; why should they start paying for a closed source solution to a problem which is now very effectively solved by free software?
    Well, I can think of some reasons...but we can discuss those offline :-)-Mike
    LOL
  117. deafening[ Go to top ]

    Versant's silence here is deafening.
  118. What people don't know is that Versant is not only spamming randomly all the earth.
    They attack (there is no other word) hibernate users, here is the kind of mails (translating from french, sorry) big society using hibernate are receiving:
    "Dear XXX,
    we know you are actually using Hibernate.
    We'll be in XXX, we'll be proud to present you VOA JDO, our solution.
    Here is a document about hibernate (the document full of lies).

    XXXX
    Marketing
    Versant France
    XXXX
    75015 Paris / France
    www.versant.com"

    They really start their mail with "we know you're using Hibernate", i just cannot understand people thinking like this.

    I'd really like someone from Versant to explain the community why they're acting like this. Generally vendors begin talking about how THEIR product is good.

    PS: i have their mail in my mailbox... if they want to discuss...

    Anthony
  119. What people don't know is that Versant is not only spamming randomly all the earth. They attack (there is no other word) hibernate users, here is the kind of mails (translating from french, sorry) big society using hibernate are receiving:"Dear XXX,we know you are actually using Hibernate.We'll be in XXX, we'll be proud to present you VOA JDO, our solution.Here is a document about hibernate (the document full of lies).XXXXMarketingVersant France XXXX75015 Paris / Francewww.versant.com"They really start their mail with "we know you're using Hibernate", i just cannot understand people thinking like this.I'd really like someone from Versant to explain the community why they're acting like this. Generally vendors begin talking about how THEIR product is good.PS: i have their mail in my mailbox... if they want to discuss...Anthony

    You can try to install some anti spam program, I never recieve this stuff from Versant. Yahoo has good software to protect you from this garbage too.
  120. Anthony,
    As the sales manager for Versant France, I think I should be aware in case such a marketing campaign was held in France by Versant France.
    So please forward me the mail you received. I am very interested to know what, why, who and how ?.
    Here is my email address : "bellando at versant.fr"
    Thanks in advance.
    Jean-Claude
  121. Anthony,As the sales manager for Versant France, I think I should be aware in case such a marketing campaign was held in France by Versant France.So please forward me the mail you received. I am very interested to know what, why, who and how ?.Here is my email address : "bellando at versant.fr"Thanks in advance.Jean-Claude

    no problem, let's continue by mail.

    Anthony
  122. I have seen the same kind of FUD comming from the other site on tss and hibernate forums for a long time.. especially from christian bauer... its about time they get some back ;)

    [quote]
    More importantly, the tools available to the developer using Versant Open Access - JDO and/or most
    other JDO vendors, are several orders of magnitude better than what's available with Hibernate
    [/quote]

    so true.. atleast when it was called jdogenie it had the best tool of all the jdo implementations and hibernate dosn't even come close... and i would never touch anything based on eclipse... either make it standalone or mape plugins for everything .. intellij, eclipse, jbuilder etc.


    apart from that both jdo and hibernate does the job... but i found jdo easier to learn since the community/vendors offer better support... even if your not a paying customer.
  123. Hibernate responds to Versant attacks[ Go to top ]

    I have seen the same kind of FUD comming from the other site on tss and hibernate forums for a long time

    I'm afraid I can't recall any case where anyone on the Hibernate team has attacked another competing ORM product. (Three years is a long time, I could be forgetting something, but its simply not our style and I can't think of a case where this happened.)

    Or are you referring to the criticisms we have made of the JDO specification? I think that is well within the bounds of reasonable discourse, don't you? I have tried not to stray into the realm of FUD, and quickly posted a public correction in the one case where I made a mistake.

    Do you think the Java community should not tolerate technical criticism of JCP standards? Certainly, the EJB3 standard has been the subject of plenty of criticism (some technical, most non-technical), and I have never been upset about the existence of criticism per se (some of the *personal* attacks have gone too far, however). Indeed, I think the JSR-220 group has done a good job of responding to critics by changing the spec, and the way the spec will be delivered.

    (I do recall that Christian is sometimes outspoken in his criticism of OODBMS technology in the abstract, could that be what you are referring to?)
    [quote]
    More importantly, the tools available to the developer using Versant Open Access - JDO and/or most
    other JDO vendors, are several orders of magnitude better than what's available with Hibernate
    [/quote]

    so true

    In my response I explicitly acknowledge that "Hibernate's tools could be improved", and explain some of our strategy for this. It's a reasonable criticism, and one we took to heart quite a few months ago. I think you'll be suprised at the speed with we get this stuff sorted out. :-)

    But, and I want to make this very clear, our tools will absolutely NOT look like the clunky visual mapping tools we have seen in some other products. We are adopting a completely different approach here, all about integrating with the developer's normal coding work process.
    i would never touch anything based on eclipse... either make it standalone or mape plugins for everything .. intellij, eclipse, jbuilder etc

    From the point of view of a non-eclipse user, what is the difference between building it in eclipse and making it standalone? You do realize that Eclipse isn't just an IDE, right? It is a platform for creating GUI applications. We plan to deliver a "lightweight" eclipse package with just Hibernate plugins for people using other IDEs.
  124. Hibernate responds to Versant attacks[ Go to top ]

    Or are you referring to the criticisms we have made of the JDO specification? I think that is well within the bounds of reasonable discourse, don't you? I have tried not to stray into the realm of FUD, and quickly posted a public correction in the one case where I made a mistake.

    Your right i haven't seen any attacks on a specific vendor but in my opinion when your going after the specification you should atleast know what your talking about.. i have seen developers from versant, kodo etc correcting false information from people at your company several times only to see the same false information show up again in another wrapping from the same people.. it was usaly done by refering to "problems" in jdo 1 when the discussion was on jdo 2.. honest mistake some would call it .. if it was only a few times.
    From the point of view of a non-eclipse user, what is the difference between building it in eclipse and making it standalone? You do realize that Eclipse isn't just an IDE, right? It is a platform for creating GUI applications. We plan to deliver a "lightweight" eclipse package with just Hibernate plugins for people using other IDEs.

    As long as it dosen't depend on the bloated eclipse i welcome it.
  125. why clunky?[ Go to top ]

    But, and I want to make this very clear, our tools will absolutely NOT look like the clunky visual mapping tools we have seen in some other products. We are adopting a completely different approach here, all about integrating with the developer's normal coding work process.

    I am really curious how much less clunky your tool will be on top of Eclipse. I ve never seen a standalone eclipse based tool that is in any way non-clunky. I prefer specialized standalone clients as with Kodo, even though i must admit that visual mapping in general is not the ultimate way of doing mapping. But also XDoclet is a subopitmal choice as it doesnt support all mapping scenarious. In my oppinion there should be a code based mapping tool (basically an XML editor) with some advanced features like autocomplete on DB-field names or DB table names. Also nice would be a automatic generation of standard field definitions as one would do with getter/setter within POJOs. So basically a coder-centric tool without all the bells and whistles of UML style visual mapping which is too far away from my coding environment.

    As a side note: If you look at your post, you are doing basically the same thing, only that you dont mention a concrete product but say "not as clunky as some products". Why not just say that your tool will be quite nice and people should try it when its ready.

    Marc Logemann
    http://www.logemann.org
  126. How sad is your software[ Go to top ]

    if your primary marketing effort is ripping into an opensource project that devs around the world have emphatically accepted?

    To me, this smacks of desperation.
  127. Reaping What You Sow[ Go to top ]

    It find it the ultimate irony that convicted FUD-masters Hibernate/JBoss are suddenly all high and mighty in denouncing the questionable marketing tactics of other vendors. All of a sudden, dishonest marketing is a evil thing, eh?

    One has to wonder how many of the chorus of "yeah, Hibernate rules!" responses on this thread are legitimate, and how many are just the same old astroturfing. Personally, I'll go with a standard solution from an honest vendor any day, commercial or otherwise. Fool me once, shame on you...
  128. Reaping What You Sow[ Go to top ]

    It find it the ultimate irony that convicted FUD-masters Hibernate/JBoss are suddenly all high and mighty in denouncing the questionable marketing tactics of other vendors. All of a sudden, dishonest marketing is a evil thing, eh?One has to wonder how many of the chorus of "yeah, Hibernate rules!" responses on this thread are legitimate, and how many are just the same old astroturfing. Personally, I'll go with a standard solution from an honest vendor any day, commercial or otherwise. Fool me once, shame on you...

    Prove in some way that the hibernate team was involved in that astroturfing practice or wash your mouth and shut up.
  129. Reaping What You Sow[ Go to top ]

    It find it the ultimate irony that convicted FUD-masters Hibernate/JBoss are suddenly all high and mighty in denouncing the questionable marketing tactics of other vendors. All of a sudden, dishonest marketing is a evil thing, eh? One has to wonder how many of the chorus of "yeah, Hibernate rules!" responses on this thread are legitimate, and how many are just the same old astroturfing.

    Do you have any evidence of myself or any other member of the Hibernate team *ever* doing anything of the sort?

    Can you point to any of the posters in this thread who appears at all likely to be a member of the Hibernate team or an employee of JBoss Inc?

    Didn't think so.

    Truly ironic is that this is the first comment "Karr Longstur" has ever posted to TSS. Yet he/she knows lots of ancient TSS history.

    Who are *you*, really?

    What is your motivation for smearing me and my team with spurious allegations of astroturfing?
  130. Reaping What You Sow[ Go to top ]

    It find it the ultimate irony that convicted FUD-masters Hibernate/JBoss are suddenly all high and mighty in denouncing the questionable marketing tactics of other vendors. All of a sudden, dishonest marketing is a evil thing, eh?One has to wonder how many of the chorus of "yeah, Hibernate rules!" responses on this thread are legitimate, and how many are just the same old astroturfing. Personally, I'll go with a standard solution from an honest vendor any day, commercial or otherwise. Fool me once, shame on you...

    Well, I don't work for JBoss or Hibernate. I'm just a user who tried a JDO implementation, Toplink, and Hibernate and found Hibernate the most useful.

    We have since standardized on Hibernate as as persistence system and have only reaped benefits from doing so. We stand by the decision.

    As for the standard issue, so what? A being a standard doesn't always equate to best. We've seen examples time and time again, so the argument of standard, IMO, is weak at best and specious at worst.

    I'd rather use a well supported, well used, well understood non-standard solution than a standard that, well, isn't as.
  131. I would like to set the record straight. Versant never sent our technical comparison out as SPAM. This was a paper created in response to the many queries we received regarding the two technologies and how they compare. We offered public technical webinars some of which were advertised right here on TSS. Anyone was welcome to join and provide feedback or ask questions and many did. Those who requested the paper summarizing the points received it.

    Further, we were not comparing our OODBMS, but our JDO implementation for relational databases. It is correct that this was written back in mid 2004 and comparing Hibernate 2.1 not 3.0. Clearly, both technologies have since evolved. For example, both being members of the JSR 220 expert group, we are both coming out with JSR 220 implementations in addition to our original API’s.

    I see some good technical discussions resulting from this which is healthy and what was the intended purpose of the paper. There are still many technical points that differ between the technologies and I would trust the developer community to make their own decisions not likely based on any one white paper or data sheet.

    Robert Greene
    V.P. Product Strategy
    Versant Corporation
  132. From whitepaper author[ Go to top ]

    I see some good technical discussions resulting from this which is healthy and what was the intended purpose of the paper.

    So, Robert, are you now prepared to publicly retract the many clearly false claims in the document, and email the retraction to all recipients of your original mass emailing?
  133. Here's a little Hibernate related advertising for anyone doubting how good it is:

    I'm currently on a project for the United States government -- this is a multi billion (yes, that's billion with a b) dollar endevour slated to last for ~5 years.

    A major piece of this project involves the modernization of the legacy system to one which is completely web based.

    Major technology utilized: Websphere, Struts, Oracle, Hibernate (amongst other components).

    Hibernate rocks -- period.
  134. Hibernate usage in the US Government[ Go to top ]

    Here's a little Hibernate related advertising for anyone doubting how good it is:I'm currently on a project for the United States government -- this is a multi billion (yes, that's billion with a b) dollar endevour slated to last for ~5 years.A major piece of this project involves the modernization of the legacy system to one which is completely web based.Major technology utilized: Websphere, Struts, Oracle, Hibernate (amongst other components).Hibernate rocks -- period.
    All good but the Struts piece. Built in legacy. Look at Slate/JSF/Tapestry. Although, I would say pretty much any new web app is instant legacy, sadly.
  135. I would like to set the record straight. Versant never sent our technical comparison out as SPAM. This was a paper created in response to the many queries we received regarding the two technologies and how they compare.
    that's false, again i can forward the last email i've received from your marketing guys. My company is using Hibernate and had never asked for your opinion or advices, we don't care since we're VERY happy with hibernate.
    We offered public technical webinars some of which were advertised right here on TSS.
    But why are you focusing on Hibernate? why? maybe because it's open source and because it doesn't have a marketing team to respond to your attack? That's brave!
    I see some good technical discussions resulting from this which is healthy and what was the intended purpose of the paper.
    False, you know your paper has been sent for marketing purpose, nothing technical.
    There are still many technical points that differ between the technologies and I would trust the developer community to make their own decisions not likely based on any one white paper or data sheet.
    Too easy, you're very hipocrite. You don't care about developpers, what Versant want is to deal with big societies, not with their developpers, that's different.

    For all people, Gavin made his response in the hibernate blog for the hibernate users, it was not intented to be published on TSS. This is not an EJB versus JDO topic. Please, please, 2004 has been full of personal attacks and too much FUD. Let's change it for 2005.
    Hope EVERYONE here is going to respect the great work every community is doing no matter if it is Hibernate community, JDO users, Toplink or IBatis, we are all happy with our tools, let's find a way to deal with two specs during some time, the best of both will have a long life...

    PEACE,
    Anthony
  136. It looks like the last try to sell JDO, are you going to drop it ?
  137. Wrong move[ Go to top ]

    I would like to set the record straight. Versant never sent our technical comparison out as SPAM. This was a paper created in response to the many queries we received regarding the two technologies and how they compare. We offered public technical webinars some of which were advertised right here on TSS. Anyone was welcome to join and provide feedback or ask questions and many did. Those who requested the paper summarizing the points received it.Further, we were not comparing our OODBMS, but our JDO implementation for relational databases. It is correct that this was written back in mid 2004 and comparing Hibernate 2.1 not 3.0. Clearly, both technologies have since evolved. For example, both being members of the JSR 220 expert group, we are both coming out with JSR 220 implementations in addition to our original API’s. I see some good technical discussions resulting from this which is healthy and what was the intended purpose of the paper. There are still many technical points that differ between the technologies and I would trust the developer community to make their own decisions not likely based on any one white paper or data sheet.Robert GreeneV.P. Product StrategyVersant Corporation


    I have received your SPAM.

    Contrarily to what your marketing folks were probably thinking, that did not make me want to try your product, to say the least.

    The best thing you could probably do right now is to rewrite that paper on Hibernate and correct its incredible amount of technical inaccuracies.

    One notable consequence of your unfortunate marketing strategy could be to hurt your own product, and damage all the good work of your own developers.

    What a shame.
  138. As a long-time JDO user that isn't experienced with Hibernate - I kind of find Gavin's point-by-point arguments about obscure functionality in his product even more of a reason to stick with open standards, rather than using a proprietary (i.e. single-vendor-API/configuration) like Hibernate (for those who think that being able to fork an open source product means there's no vendor lock-in, I'm with Johnny Schwartz on this one :)

    With an open standards compliant product, if I have too many problems with it, I can just replace it with a competitor's implementation of the same standard. I can't do that with Hibernate (at least not until EJB 3 is finalized).

    Personally though, the main reason I prefer to use and recommend products that implement open standards is not just having code portability, but also portability of skills. It takes a lot of time and energy to develop expertise with a technology - whether that's JDO or Hibernate. The difference is that with a standard in place, I've got a better chance of being able to reuse the skills I learn with one product on one project, once I go to a new project - even if the product is a different implementation of the same standard.
    Gavin King says "why should they start paying for a closed source solution to a problem which is now very effectively solved by free software?"

    Why use an open source ORM with a proprietary API, when there are some great free, open source JDO implementations that implement an open standards API - jdocentral.com Then if you like the technology but want additional support / documentation / performance / qualities of service / value-add extensions / etc, then you can swap in a commercial JDO implementation, without having to rewrite a single line of code. Is that so wrong?

    The JDO versus Hibernate argument seems kinda similar to the Java versus Microsoft technology debate. As Johnathan Schwartz says - "openness" is defined by the ease with which a customer can substitute one product for another. If you build your application with any product that has a vendor-specific API, then you're stuck with that vendor (isn't that why we're all developing in Java rather than using Windows APIs?).


    Dave Clark
    Senior WebSphere Architect
    Versant Corporation
  139. The difference is that with a standard in place, I've got a better chance of being able to reuse the skills I learn with one product on one project, once I go to a new project - even if the product is a different implementation of the same standard.

    Uh, go to Monster.com. Search for jobs...
    "JDO" = 36.
    "Hibernate" = 123.

    Monster.de:
    "JDO" = 5.
    "Hibernate" = 25.

    Monster.fr:
    "JDO" = 4.
    "Hibernate" = 27.

    Monster.uk:
    "JDO" = 1.
    "Hibernate" = 10.
    "Spring" = 12. :)

    Hotjobs.com
    "JDO" = 11.
    "Hibernate" = 57.

    What exactly was your point again? If I want portable Job skills, it seems like Hibernate is an order of magnitude over what people are looking for VS JDO.

     - Don
  140. The difference is that with a standard in place, I've got a better chance of being able to reuse the skills I learn with one product on one project, once I go to a new project - even if the product is a different implementation of the same standard.
    Uh, go to Monster.com. Search for jobs..."JDO" = 36."Hibernate" = 123.Monster.de:"JDO" = 5."Hibernate" = 25.Monster.fr:"JDO" = 4."Hibernate" = 27.Monster.uk:"JDO" = 1."Hibernate" = 10."Spring" = 12. :)Hotjobs.com"JDO" = 11."Hibernate" = 57.What exactly was your point again? If I want portable Job skills, it seems like Hibernate is an order of magnitude over what people are looking for VS JDO. - Don

    Actually, no. Order of magnitude is generally defined as a power of 10: these figures show JDO at anywhere between 10% and 29% of Hibernate use. That's actually more than I thought!

    In fact, these figures show a pretty healthy JDO job market. Hibernate is very successful (and deservedly so), thus even a moderate fraction of Hibernate use indicates pretty widespread uptake of JDO. JDO as a whole has far more POJO persistence market penetration than, for example, Apple has of the desktop market. Of course, Hibernate as a product is more successful than these figures indicate because it is a single organisation and JDO has multiple suppliers.

    Thanks for some interesting figures.
  141. With an open standards compliant product, if I have too many problems with it, I can just replace it with a competitor's implementation of the same standard. I can't do that with Hibernate (at least not until EJB 3 is finalized).

    I use a lot of "open standards compliant products", but I can assure you that even if I have dreamed of ditching WebSphere out of my enterprise it has never been so easy, and my idea about replacing it with WebLogic has soon to become a reality.

    In contrast, since I never had any significant problem with Hibernate in my 1,5 years experience (we based an e-commerce portal on it and are very happy we did), I can't really express an opinion about your sentence. What I'm sure about, is that being able to follow the code inside the library has been extremely beneficial to me, and every time I use a closed source product or library I constantly feel the need to take a look inside to be sure about how it works.
  142. my idea about replacing it with WebLogic has soon to become a reality.

    Uh, actually it was "won't become a reality soon". ;)
  143. Why use an open source ORM with a proprietary API, when there are some great free, open source JDO implementations that implement an open standards API -
    Because using 'proprietary' Hibernate protects me from buying vendors JDO 'extensions' of unknown quality and compatibility. JDO2 might change that but JDO1 was unusable without proprietary extensions.
  144. What do you think?

    Well, the response is clearly a usefull enumeration of what Hibernate "CAN" do, demonstrating that the guys who put up such a huge FUD spreading document thought wanted to to one single thing: To profit from the momentum JDO gain through the latest 'win' when it was passed the JCP vote as a result to Java community standing together for it.

    Such things demostrate how you can give a hand to an almost drowning man and he will eventually try to drag you into the pool in his way out. I am sorry to be a little bit biased about this and seem to associate Versant with the whole JDO thing (which is of course wrong) but what I am trying to say is that Versant seems to use the litle wave JDO caught when it passed the JCP vote in a completely wrong way.

    Otherwise the response is a good enumeration of some *strong* points of Hibernate, some of them that I didn't know about, so thanks for the response :-)

    (A *happy* Hibernate user and 'let JDO live' Java community voter)
  145. BLAH BLAH BLAH[ Go to top ]

    How is it that anything involving JDO generates such hot
    air ?

    It is obvious that the only people who give a toss about
    JDO are the vendors or other vested interests.

    How many people in these forums work for some corporate
    blogging ( propaganda ) effort ??

    History demonstrates that it has certainly happened before
    ( lets not name names ).

    Considering the drivel that gets talked in here I sometimes
    wonder ....

    How many people involved in any of these debates
    are actually implementing this stuff ?

    And how many have "some other" interest in the technology.

    For my 2 cents I'm going with Hibernate 3/ EJB 3, because
    they are

    a) The most pleasant development model.

    b) They seem to have a nice team behind them who are
    responsive to peoples needs rather than constantly
    pushing a "we know best" mentality.

    b) They are both proven technology ( i've written a large
    app in Hibernate and a small one with EJB 3 ( hibernate
    with annotations ) ) and they have worked as I expected
    in a predictable fashion.

    c) Application performance has not been greatly impacted by
    the overhead of their ORM implementation.

    d) They have a future, unlike JDO.

    e) Documentation , documentation , documentation

    Yes JDO, you are the weakest link ..... goodbye !!!

    Oh and say hello to Netscape 4 while your there.

    --b

    --
    ----------------------------------------------
    neo-Luddite, noun

       The evolutionary state that follows “cutting-edge early adopter.”
  146. BLAH BLAH BLAH[ Go to top ]

    please stop being agressive
    read it http://www.theserverside.com/news/thread.tss?thread_id=32547#161623

    change your mind, respect, respect and respect!

    i'm a hibernate team member and ask you to stop these kind of message, please respect everybody here.

    Thanks,
    Anthony
  147. BLAH BLAH BLAH[ Go to top ]

    They seem to have a nice team behind them who are responsive to peoples needs rather than constantly pushing a "we know best" mentality.

    Well, the Hibernate team is definitely responsive to peoples' needs, agreed. And they did a great job in building an ORM mapping approach that was driven by exactly those needs. Kudos to them for this achievement!

    But you obviously never had to discuss with Gavin and Christian about something that they got a strong opinion on: they often expose a rather arrogant "we know best"/"agree with us or go away" mentality.
    They are both proven technology ( i've written a large app in Hibernate and a small one with EJB 3 ( hibernate with annotations ) )

    The Hibernate core is certainly a proven technology. But please, EJB3 is not even in final draft yet, so how can you call it a "proven technology"? The Hibernate3 annotations preview is nice but alpha - a "proven technology"? I guess we got a very different understanding of the term.

    As a side note, the use of annotations for all sorts of metadata in EJB3 has to be considered experimental even in approach. Sure, people have used XDoclet over the past few years, but in general it's very debatable whether stuff like O/R mapping metadata belongs in Java source files.

    Juergen
  148. BLAH BLAH BLAH[ Go to top ]

    Sure, people have used XDoclet over the past few years, but in general it's very debatable whether stuff like O/R mapping metadata belongs in Java source files.Juergen

    Uhm, so we have many years of experience with the technique but its still unknown if this is a good or bad _option_? And, basically, nothing changes - you still can use external mapping files if you want to. Or annotations, but they no longer need the XDoclet hack. So, its debatable if an optional improvement should be made after we have tried it for years with some success? What part do you want to discuss? (See, I'm not telling you to go away.)
  149. BLAH BLAH BLAH[ Go to top ]

    Uhm, so we have many years of experience with the technique but its still unknown if this is a good or bad _option_? And, basically, nothing changes - you still can use external mapping files if you want to. Or annotations, but they no longer need the XDoclet hack. So, its debatable if an optional improvement should be made after we have tried it for years with some success? What part do you want to discuss?

    Well, I was mainly referring to the focus on source-level annotations as *primary* option for ORM metadata. Annotations aren't an "optional improvement" in the EJB3 world, they are the primary focus. I don't mind the option at all, by any means; but I don't understand why external mapping files are second-class citizens in the EJB3 world.

    So essentially, I consider the *strong focus* on annotations as experimental. It's undeniable that EJB3 has that focus: early EJB3 spec drafts didn't deal with separate mapping files at all, just with annotations. And examples usually show annotations only.

    I would expect to see external mapping files and annotations as equal primary options. After all, Hibernate has shown that XML mapping files can be concise and manageable, so why not consider that as *first-class* option for EJB3 too? But that doesn't seem to happen, with everyone in the EJB3 world being so annotation-happy.
    (See, I'm not telling you to go away.)

    Hmm, should I say thanks for behavior that one would always expect? Well, OK, in your case and with our background, and considering myself a polite person: thanks. Am I allowed to post on the Hibernate forums again now - even if I dare to challenge your views? ;-) (That was a rhetoric question.)

    Juergen
  150. BLAH BLAH BLAH[ Go to top ]

    So essentially, I consider the *strong focus* on annotations as experimental. It's undeniable that EJB3 has that focus: early EJB3 spec drafts didn't deal with separate mapping files at all, just with annotations. And examples usually show annotations only.

    I would expect to see external mapping files and annotations as equal primary options.

    I guess it makes examples easier to read (if you use bold font) - at least I find examples with annotations easier to understand if formatted properly. It's also a good idea to agree on the primary choice for metadata (or to have it named in the specification). Think about documentation, presentations, training material, etc. You can't show everything twice, much better if you have to explain the secondary option only once.

    From a technical perspective (that is, if we forget that the spec names one primary and the other secondary) I don't see anything that would make one method more capable than the other one. You can use annotations only. You can use logical annotations (at the model level) and physical (schema) declarations externalized in XML mappings. You can use only XML files for everything. There are no restrictions as far as I can see. What do we have to change?
  151. You can use logical annotations (at the model level) and physical (schema) declarations externalized in XML mappings.

    FTR, this isn't quite the way that things are going in the EJB3 team. Nothing's set in stone regarding this issue yet, but for the most part, the persistence metadata structure is not defined based on what is physical and what is logical.

    Also, a number of techniques have been thrown around regarding the granularity and nature of how XML metadata overrides / supplants / supplements annotation metadata, and it's by no means clear (to me, at least) exactly what model we'll end up with.

    Pre-emptive flame responses / disclaimers:

    - no, I'm not EJB3-bashing. An observant reader will know that I'm on the EJB3 team as well as the JDO2 team, and am alleged (by others than just myself) to be active within the EJB3 group.

    - no, I'm not taking a stance on any of the previous issues on this thread here.

    - no, I'm not representing the official JSR220 group here. My goal is simply to correct some inaccurate information early rather than letting it become common perception. (And am hopefully doing so in a way that doesn't get me in trouble with the JCP regarding private JSR information disclosure!)

    -Patrick

    --
    Patrick Linskey
    http://solarmetric.com
  152. FTR, this isn't quite the way that things are going in the EJB3 team. Nothing's set in stone regarding this issue yet, but for the most part, the persistence metadata structure is not defined based on what is physical and what is logical.

    Well, it looked like this to me when I was reading the EDR of the spec and in my documentation efforts I could also see this separation, though not for everything. I think it's a good approach and hope completing it will be considered in the EG.
    Also, a number of techniques have been thrown around regarding the granularity and nature of how XML metadata overrides / supplants / supplements annotation metadata, and it's by no means clear (to me, at least) exactly what model we'll end up with.

    As I read the notes in the EDR, it seems to be clear that there will be _some_ externalization mechanism for overriding annotations using XML. I'm sure the EG will figure out the best syntax for that when it is on the agenda. For now it is important to know that this is on the road map as a part of the specification, as it seems to be (to my surprise) a major concern many people have.
  153. FTR, this isn't quite the way that things are going in the EJB3 team. Nothing's set in stone regarding this issue yet, but for the most part, the persistence metadata structure is not defined based on what is physical and what is logical.
    Well, it looked like this to me when I was reading the EDR of the spec and in my documentation efforts I could also see this separation, though not for everything. I think it's a good approach and hope completing it will be considered in the EG.
    Also, a number of techniques have been thrown around regarding the granularity and nature of how XML metadata overrides / supplants / supplements annotation metadata, and it's by no means clear (to me, at least) exactly what model we'll end up with.
    As I read the notes in the EDR, it seems to be clear that there will be _some_ externalization mechanism for overriding annotations using XML. I'm sure the EG will figure out the best syntax for that when it is on the agenda. For now it is important to know that this is on the road map as a part of the specification, as it seems to be (to my surprise) a major concern many people have.

    Don't be suprised.

    How else are you going to easily have the same EJB source code run in different environments? Any enterprise app that I have worked on needs to progress through development, testing, and production environments. Deployment descriptors, among other property files need to be customized to each environment. Thus an annotation overriding mechanism is a necessity.
  154. For my 2 cents I'm going with Hibernate 3/ EJB 3...

    I guess in 2 years or so you might actually produce a running system that will be run in a big company. Big companies tend to not like to beta-test/bug fix and generaly choose proven, stable technology standards. EJB3, JDK1.5 & Hibernate3 (or JDO2 for that matter) do not fit this description in the least. EJB2.1, JDK1.4 & JDO 1.01 does.

    What do you do until then, play with betas? I'll stick with the accepted standards and (try to) develop quality, stable, long-lasting code for big compaines with deep pocket books, which is obviously not so exciting as the bleeding edge.
  155. You Looking for Work (in 2 Years)?[ Go to top ]

    I see no problems to "play with betas", but it is very silly to trust spam and products advocated by spammers.
  156. For my 2 cents I'm going with Hibernate 3/ EJB 3...
    I guess in 2 years or so you might actually produce a running system that will be run in a big company. Big companies tend to not like to beta-test/bug fix and generaly choose proven, stable technology standards. EJB3, JDK1.5 & Hibernate3 (or JDO2 for that matter) do not fit this description in the least. EJB2.1, JDK1.4 & JDO 1.01 does.What do you do until then, play with betas? I'll stick with the accepted standards and (try to) develop quality, stable, long-lasting code for big compaines with deep pocket books, which is obviously not so exciting as the bleeding edge.

    Yeah well I know one thing for sure and that's that nobody
    is going to be using JDO in 2 years time.

    Hell they might not even be starting any new projects in
    EJB unless they make it gets a lot better and quickly.

    Punish Versant, ignore JDO and forgive EJB
  157. Yeah well I know one thing for sure and that's that nobody is going to be using JDO in 2 years time.

    Amazing! So all on-going and planned projects that use JDO and suddenly going to cease, and all associated code will vanish into thin air. The 'vibrant JDO community' (as described by BEA) will, en masse, all drop what they are doing.

    I wish I had such a refined ability to predict the future.

    I don't know what the big deal is: Some people use JDO. More people use Hibernate. Both are good solutions. Choice is good. Get over it.
  158. Yeah well I know one thing for sure and that's that nobody is going to be using JDO in 2 years time.
    Amazing! So all on-going and planned projects that use JDO and suddenly going to cease, and all associated code will vanish into thin air. The 'vibrant JDO community' (as described by BEA) will, en masse, all drop what they are doing.I wish I had such a refined ability to predict the future. I don't know what the big deal is: Some people use JDO. More people use Hibernate. Both are good solutions. Choice is good. Get over it.

    http://www.jcp.org/en/jsr/results?id=2548

    BEA: No

        JDO is one of many different persistence solutions in server-side Java today. With J2EE 1.5 emphasis on simplification and ease of use, we don't see how having another release of JDO, whose market acceptance is essentially constrained to use with object databases, can be explained in conjunction to similar enhancements being made in the EJB3 expert group. We are also concerned about taking JDO into new areas such as disconnected data set support until we better understand how all of these solutions fit together. Unless the submitters can explain how all of this fits together, we believe the Java community would be better served with fewer apparently competing alternatives.
  159. I have to point out the amusing fact that Caldera systems ( ie SCO group )voted in favour of JDO 2.0 .

    But if you look at the list you can see that Oracle,IBM and
    BEA all voted against it.

    Perhaps the small JDO vendor lobby is right and they were wrong.

    Perhaps we should fragment more rather than simplifying
    and unifying the persistence API's.

    What do I know anyhow ?

    I don't know why Versant was bothered anyhow, from the
    front page of their site it is obvious that their focus
    is on tight integration with the .NET platform.
  160. http://www.jcp.org/en/jsr/results?id=2548BEA: No    JDO is one of many different persistence solutions in server-side Java today. With J2EE 1.5 emphasis on simplification and ease of use, we don't see how having another release of JDO, whose market acceptance is essentially constrained to use with object databases, can be explained in conjunction to similar enhancements being made in the EJB3 expert group. We are also concerned about taking JDO into new areas such as disconnected data set support until we better understand how all of these solutions fit together. Unless the submitters can explain how all of this fits together, we believe the Java community would be better served with fewer apparently competing alternatives.

    http://www.jcp.org/en/jsr/results?id=3078

    BEA: Yes

    "After further review, BEA has concluded that there is a vibrant JDO community which needs this specification, regardless of whether we are successful in achieving an overarching persistence strategy. As a result, I see no reason to hold this community hostage to a goal that may or may not be achieved."
  161. I wish I had such a refined ability to predict the future.

    http://java.sun.com/j2ee/persistence/faq.html

    Q: What will happen to other data persistence APIs once this new API is available?

    A: The new persistence API as defined by JSR 220 will be the standard Java persistence API going forward.
  162. and...[ Go to top ]

    all other software/implementation cease to funciton when jsr220 implementations make it to market?

    granted, the ejb3 implementations SHOULD capture a significant amount of market share for NEW projects, but i would not be so bold to predict the demise of all the other enterprise and persistence frameworks.

    monster.com USA search: COBOL=more than 1000 jobs - amazing that these jobs exist after Java killed it off, isn't it.

    there's something called sunk costs that the tekkie seems to forget in the overall business picture. systems we build now will be based on a platform that exists now and is expected to last 10-15 years. christ, we're just now (after 17 years) migrating our COBOL code, and i predict the board of directors won't be wanting to pour money into the next silver bullet (ejb3) when it comes out - specially when we have running and highly functional systems runing on the ejb2.1 spec with some ORM solution.
  163. and...[ Go to top ]

    but i would not be so bold to predict the demise of all the other enterprise and persistence frameworks.monster.com USA search: COBOL=more than 1000 jobs - amazing that these jobs exist after Java killed it off, isn't it

    a) Those jobs are in India, paying $ 250 per month.

    b) COBOL is a language, not an API that never gained widespread
    market acceptance.
  164. and... STOP PLEASE[ Go to top ]

    b) COBOL is a language, not an API that never gained widespreadmarket acceptance.

    Thanks you for your support Bryan, really but wasn't the topic related to misinformations from Versant about hibernate?

    Please focus on the subject ;)

    This is not a place for war, i hope so :(
  165. and... STOP PLEASE[ Go to top ]

    b) COBOL is a language, not an API that never gained widespreadmarket acceptance.
    Thanks you for your support Bryan, really but wasn't the topic related to misinformations from Versant about hibernate?Please focus on the subject ;)This is not a place for war, i hope so :(

    no , this is a place for correcting people when they are
    wrong. It's called a debate, perhaps a heated debate, it's
    kinda like the democratic process* .

    Now when someones response to me is to talk rubbish by comparing a not particularly popular API to a masively
    used language I feel obliged to correct them.

    Simple as that..

    *( where applicable).
  166. I wish I had such a refined ability to predict the future.
    http://java.sun.com/j2ee/persistence/faq.htmlQ: What will happen to other data persistence APIs once this new API is available?A: The new persistence API as defined by JSR 220 will be the standard Java persistence API going forward.

    That is not a direct answer to the question.

    The question was 'what will happen to the other data persistence APIs'.

    I don't know the answer! I have seen this kind of situation before many times.

    Here is my guess:

    Some developers will put in every effort to migrate to the new API simply because it has the label 'standard' on it.

    Others will stick with what they are using because they have invested years of time and lots of money in existing code, and after all, JDO 2.0 will remain a JSR no matter what.

    Others will make a decision based on which API is best for their project. They may find JDO 2.0 easier, or EJB 3.0 easier. Correct me if I am wrong, but as I understand it JDO is datastore agnostic, whereas EJB 3.0 POJO is relational. In that case, there will always be situations where JDO will work where EJB 3.0 won't (perhaps on mobile devices, for example).

    There seems to be this strange belief that JDO will 'vanish' as soon as EJB 3.0 POJO persistence appears, as if the JSR will be erased off the list on the JCP site.

    If EJB 3.0 is good enough, people will use it. Trying to force them off of JDO is not a good way to encourage this.

    After all, there have been many APIs labelled as 'standards', but that has not encouraged their universal use: consider Swing!
  167. BLAH BLAH BLAH[ Go to top ]

    How is it that anything involving JDO generates such hot air ? It is obvious that the only people who give a toss aboutJDO are the vendors or other vested interests.How many people in these forums work for some corporateblogging ( propaganda ) effort ?? History demonstrates that it has certainly happened before ( lets not name names ).Considering the drivel that gets talked in here I sometimeswonder .... How many people involved in any of these debatesare actually implementing this stuff ? And how many have "some other" interest in the technology.For my 2 cents I'm going with Hibernate 3/ EJB 3, because they are a) The most pleasant development model.b) They seem to have a nice team behind them who are responsive to peoples needs rather than constantly pushing a "we know best" mentality.b) They are both proven technology ( i've written a largeapp in Hibernate and a small one with EJB 3 ( hibernate with annotations ) ) and they have worked as I expectedin a predictable fashion.c) Application performance has not been greatly impacted bythe overhead of their ORM implementation.d) They have a future, unlike JDO.e) Documentation , documentation , documentation Yes JDO, you are the weakest link ..... goodbye !!! Oh and say hello to Netscape 4 while your there.--b-- ----------------------------------------------neo-Luddite, noun   The evolutionary state that follows “cutting-edge early adopter.”

    The above are the rants of a Hibernate fan boy.

    JDO is an exceptional persistence spec. If you had used it you would know this. Either way, please put away your agressive tone. It is not appropriate on a technical forum.

    - Tony Vai
    extremely happy JDO user.
  168. None of both[ Go to top ]

    Both don't live up to reality of enterprice computing and thus are of marginal importance. Let them beat their heads .... it's fun to read and at the moment i'd say it's 1:0 for hibernate....

    But back to real life:
    1. we live with large relational databases
    2. which we actually want to use an not waste with some generic o/r mapping and dynamically created sql.
  169. None of both[ Go to top ]

    Both don't live up to reality of enterprice computing and thus are of marginal importance. Let them beat their heads .... it's fun to read and at the moment i'd say it's 1:0 for hibernate....But back to real life: 1. we live with large relational databases2. which we actually want to use an not waste with some generic o/r mapping and dynamically created sql.
    Enterprise computing is not equal to large databases. And there are those who have posted here and have used both with large databases. We don't want to waste our time with repeatable coding - when totally unnecessary.
  170. None of both[ Go to top ]

    Both don't live up to reality of enterprice computing and thus are of marginal importance. Let them beat their heads .... it's fun to read and at the moment i'd say it's 1:0 for hibernate....But back to real life: 1. we live with large relational databases2. which we actually want to use an not waste with some generic o/r mapping and dynamically created sql.
    Enterprise computing is not equal to large databases. And there are those who have posted here and have used both with large databases. We don't want to waste our time with repeatable coding - when totally unnecessary.
  171. None of both[ Go to top ]

    We don't want to waste our time with repeatable coding - when totally unnecessary.

    That's exactly the point! You want to code right! Not too specific and not too general. You don't what to repeat and do you don't want leave out.
    And that's where O/R Mappings fail ... more often then not. Cool = Easy for the developer != Good appliaction. More often then not i have seen RAD tools in many disguises - O/R is one - create legacy quicker then the development cycle.
  172. None of both[ Go to top ]

    We don't want to waste our time with repeatable coding - when totally unnecessary.
    That's exactly the point! You want to code right! Not too specific and not too general. You don't what to repeat and do you don't want leave out. And that's where O/R Mappings fail ... more often then not. Cool = Easy for the developer != Good appliaction. More often then not i have seen RAD tools in many disguises - O/R is one - create legacy quicker then the development cycle.

    ORMs are not RAD tools. If that is true then Java is RAD tool because it lets us not have to code in C or Assembly.

    I've not had Hibernate fail yet. But I have had plenty of hand coded SQL and transforming of db records to Objects "fail" or at least cause me great grief. Is it perfect for everything? No. This has been beat to death in other threads. Lets agree to disagree.

    It is true that Cool and easy is not always good for applications (for example Web Applications - ok, they really are not that easy).
  173. Sheer hypocrisy![ Go to top ]

    Gavin, please don't play the virgin maid....

    JBoss is certainly known, for confusing agressive marketing with constructive discussion and not always in the most transparent way, so plse.....

    And also: don't take yourself that important:

    There's a rationale for JDO and there's one for EJB 3.0 aka Hibernate 3.0.
    And there's also a very good rationale for none of both, it all depends very much on the requirements of the application.

    I really thought open source was about sharing, embracing, respect and individual choice.
  174. I liked the way Gavin concluded his blog response...

    "Very few of the interesting questions in ORM are even addressed in this document."

    I agree. The writer seems to address the esoteric instead of the practical. It seems to be a sad flailing in a vain desperate attempt to win some market share.

    "What facilities does Versant have for dealing with complex legacy data?"

    I've been amazed with Hiberates ability to map to some darn whacky legacy schemas. (One sticks out in my head. It was crazy. I was truly amazed that Hibernate could do the mappings successfully. I initially told the client no way. But, it only took me a few hours to figure it all out.)

    "For allowing full overriding of any generated SQL? For calling database-specific functionality from the query language?"

    This is a very nice feature that you do not see with many other commercial solutions.

    "For handling dynamic queries on search screens?"

    The Criteria API and the QBE support is way cool. You can support dynamic queries with some really terse code.

    "For efficient association fetching?"

    The breadth of the options is very nice. I can overide the fetching on a query by query basis (use case by use case) to fine tune my query to get just the object I need for the current use case in an effecient manner.

    The issues with the paper (besides the reported half-truths) is that it seemed to focus on the esoteric instead of important ORM issues.

    I am a big fan of Hibernate 2.x. I look forward to using Hiberante 3.

    Thanks Gavin. You are an inspiration.

    This is my understanding of the legend of Hibernate and Gavin....

    Gavin King took a look at EJB 2.x CMP CMR and thought it was insane and then he created Hibernate. There were other vendors of proprietary solutions, but they had no need to go to the table to negotiate a specification. Hibernate was good enough to force them to the table.

    EJB CMP CMR 2.x and JDO 1.x initial specifications stunk because they did not have a standard mapping to the database (and for other reasons). How can you have a specification on OR mapping without the darn mappings? Grrrr....

    The failure was not because of the JCP process but because of the profit motivated vendors, which is understandable (I actually prefer making a profit to a loss :o) ).

    Hibernate forced them to the table by providing the de facto universal standard.

    JDO2 and EJB3 exist in their current state because Hibernate forced them to exists IMHO.

    just my 2 cents....
  175. EJB CMP CMR 2.x and JDO 1.x initial specifications stunk because they did not have a standard mapping to the database (and for other reasons). How can you have a specification on OR mapping without the darn mappings? Grrrr....

    Well, there should be little objection to JDO 2.0 then, which addresses many of these issues.
    Hibernate forced them to the table by providing the de facto universal standard.

    ... for relational databases. Not all persistence is to relational stores. JDO is datastore-neutral. I find that incredibly useful. I don't want a new intended standard for persistence that does LESS than the API I am now using.
    JDO2 and EJB3 exist in their current state because Hibernate forced them to exists IMHO.just my 2 cents....

    Oh, I think that is questionable, especially regarding JDO 2 - I have never used Hibernate, but as a JDO 1.0 user I was well aware of the failings of that spec! I did not need to know Hibernate to realise what they were. After all, a lot of JDO 2.0 is simply standardising what was left as vendor extensions in JDO 1.0. I'm sure there was some influence, but I think 'forced' is far too strong. Regarding EJB3 - many developers where happily using JDO 1.0 (with all it's flaws) as an effective POJO persistence method under J2EE and in app servers.

    Something that worries me about all this is that I had obviously been misunderstanding what JSRs were for. I had thought the idea was to innovate and set up specifications that are intended to be useful long-term. It seems to me that with persistence what we are getting is a 'follow the crowd' attitude: pick what happens to be currently popular and declare that the 'standard'.

    This would be fine if there was not already an existing user base for an existing standard!

    So what happens, hypothetically, years in the future if something better than Hibernate appears and is wildly successful? Do we suddenly declare that the new 'official standard' for persistence?

    Developers like me are after long-term support for JSRs. Lack of such long-term commitment is one of the reasons I don't use Microsoft tools and languages.

    The whole idea of a 'unified' persistence spec now seems to me to be flawed. JDO and EJB 3.0 will have overlapping capabilities but will also address different types of persistence - EJB 3.0 will be tuned for relational stores and app servers, JDO will remain general-purpose: rather like J2EE and J2SE. Why not just leave it like that, and let developers choose what is best for a task? Labelling EJB 3.0 the 'standard' makes as much sense to me as calling J2EE the 'standard' Java.
  176. Well, there should be little objection to JDO 2.0 then, which addresses many of these issues.
    Hibernate forced them to the table by providing the de facto universal standard.
    ... for relational databases. Not all persistence is to relational stores. JDO is datastore-neutral. I find that incredibly useful.

    Well, let me say. When I first started reading about persistence solutions and came across JDO and Hibernate, I noticed that Hibernate directly addressed this issue. It was basically, "How often to you find yourselves needing to write to a text file, an OODBMS, or RDBMS? We decided to optimized the experience for the task we feel most developers do."

    I agreed with that philosophy. For my work, for the developers I know, we all use relational databases. None of had to worry about an application that some day, had to switch to some other form of persistence.

    Which is not to say that feature isn't useful, just not for me. Ever. It has never come up. In ten years.

    So, that wasn't a feature of JDO that was compelling...to me.

    I've found Hibernate support reasonable. Not perfect, but I've found the answers. And it has proven itself across several projects at my current position, and has definitely saved us time and effort while improving the quality of our work.

    I have no reserverations about recommending it as a solution.
  177. Well, let me say. When I first started reading about persistence solutions and came across JDO and Hibernate, I noticed that Hibernate directly addressed this issue. It was basically, "How often to you find yourselves needing to write to a text file, an OODBMS, or RDBMS? We decided to optimized the experience for the task we feel most developers do."I agreed with that philosophy.

    Absolutely. It is a great way to develop a product that is highly tuned for use with relational systems, but a bad way to define a general purpose standard.

    One of the key aspects of Java is its versatility and flexibility. J2EE, J2SE, J2ME etc. Java works almost everywhere from multi-processor enterprise servers, PCs, mobile phones and embedded applications. That is one of the strengths of Java.

    In short, Java isn't just J2EE, and persistence isn't just relational.

    Although my option is unimportant:

    I support a specification for POJO persistence to relational stores. If Hibernate is a good basis for that, fine.

    What I object to is that such a specification should be the only supported specification for persistence.

    Java is more than J2EE; persistence is more than relational stores; choice is good. Why should Java be versatile and flexible in all ways BUT persistence?

    By the way, I also recommend Hibernate to people. It just doesn't suit what I want to do.
  178. Well, let me say. When I first started reading about persistence solutions and came across JDO and Hibernate, I noticed that Hibernate directly addressed this issue. It was basically, "How often to you find yourselves needing to write to a text file, an OODBMS, or RDBMS? We decided to optimized the experience for the task we feel most developers do."I agreed with that philosophy.
    Absolutely. It is a great way to develop a product that is highly tuned for use with relational systems, but a bad way to define a general purpose standard.One of the key aspects of Java is its versatility and flexibility. J2EE, J2SE, J2ME etc. Java works almost everywhere from multi-processor enterprise servers, PCs, mobile phones and embedded applications. That is one of the strengths of Java. In short, Java isn't just J2EE, and persistence isn't just relational.Although my option is unimportant:I support a specification for POJO persistence to relational stores. If Hibernate is a good basis for that, fine.What I object to is that such a specification should be the only supported specification for persistence. Java is more than J2EE; persistence is more than relational stores; choice is good. Why should Java be versatile and flexible in all ways BUT persistence?By the way, I also recommend Hibernate to people. It just doesn't suit what I want to do.

    Again Steve. Nicely put!
  179. In short, Java isn't just J2EE, and persistence isn't just relational.

    This is mostly academic. In the real world most non-trivial applications are in fact J2EE, and the persistence is relational 95% of the time or more.

    Portability between different persistence models is not an article of faith or an automatic goal of J2EE applications, but a matter of business requirements.

    I never saw once such business goal stated in any company I worked for in 10 years. Which does not mean that the need to accomodate different kind of databases does not exist, only that it seems pretty marginal to me.

    I'm afraid I have to disagree with you on this one too, as I don't find the JDO feature of being able to operate also with non-relational databases 'incredibly useful' (your quote).
  180. In short, Java isn't just J2EE, and persistence isn't just relational.
    This is mostly academic. In the real world most non-trivial applications are in fact J2EE, and the persistence is relational 95% of the time or more [..] Which does not mean that the need to accomodate different kind of databases does not exist, only that it seems pretty marginal to me.

    Precisely. 95% of all Java applications are J2EE. So let's abandon J2SE and J2ME? They are certainly marginal by comparison.
    I'm afraid I have to disagree with you on this one too, as I don't find the JDO feature of being able to operate also with non-relational databases 'incredibly useful' (your quote).

    You don't. I do. That is entirely the point. I want to have the freedom to disagree! Should your requirements dictate what everyone else should be able to use?

    There is a frequent problem with this debate because people assume that their personal experience and requirements represents not only what almost everyone else uses, but what everyone else should use.

    If you don't want to use an API that allows for non-relational persistence, don't! Use EJB 3.0 when it comes out. That is the kind of freedom I am after. But I also want there to be long-term support for a JSR specification for the kind of persistence requirements I need.
  181. You don't. I do. That is entirely the point. I want to have the freedom to disagree! Should your requirements dictate what everyone else should be able to use?There is a frequent problem with this debate because people assume that their personal experience and requirements represents not only what almost everyone else uses, but what everyone else should use.If you don't want to use an API that allows for non-relational persistence, don't! Use EJB 3.0 when it comes out. That is the kind of freedom I am after. But I also want there to be long-term support for a JSR specification for the kind of persistence requirements I need.

    I do agree. It is all about choice. I enjoyed the fact that I had Toplink, Cocobase, various JDO implementations, and Hibernate.

    Worse case, bring in a Spring and be able to use them all!
  182. Business requirements are the key[ Go to top ]

    I want to have the freedom to disagree! Should your requirements dictate what everyone else should be able to use?There is a frequent problem with this debate because people assume that their personal experience and requirements represents not only what almost everyone else uses, but what everyone else should use.

    I am not trying to dictate anything. I merely pointed out that I never met the need for what you called an 'incredibly useful' feature. If I and most of the developers I know, and potentially many others on this thread never met the need for that particular feature, then it should not stated as incredibly useful.
    That is all I meant.

    If you don't want to use an API that allows for non-relational persistence, don't! Use EJB 3.0 when it comes out. That is the kind of freedom I am after.


    It is not about what I want, it is about what I need. If I don't need an API that allows for non-relational persistence, then I won't use it. If my business requirements state otherwise, then I will.
    But I also want there to be long-term support for a JSR specification for the kind of persistence requirements I need.

    Fine. I don't see a problem with that. Hibernate addresses the paradigm mismatch between Java which is OO, and relational databases that are not.
    If you need a persistence model that works with other types of databases, then obviously Hibernate is not the right tool for you.
  183. Fine. I don't see a problem with that. Hibernate addresses the paradigm mismatch between Java which is OO, and relational databases that are not.If you need a persistence model that works with other types of databases, then obviously Hibernate is not the right tool for you.
    Isn't JDO2 address the same issue as well as other types of databases? Doesn't that make JDO2 a right tool (or a right spec)?
  184. Isn't JDO2 address the same issue as well as other types of databases? Doesn't that make JDO2 a right tool (or a right spec)?

    Of course, It makes it an alternative.

    However, I already use Hibernate which fulfills the business requirements. I don't feel the compelling necessity to go to JDO to do basically the same thing, specially since its cute 'extra feature' is not needed?
  185. Fine. I don't see a problem with that. Hibernate addresses the paradigm mismatch between Java which is OO, and relational databases that are not.If you need a persistence model that works with other types of databases, then obviously Hibernate is not the right tool for you.
    Doesn't JDO2 address the same issue as well as other types of databases? Doesn't that make JDO2 a right tool (or a right spec)?
  186. Business requirements are the key[ Go to top ]

    I am not trying to dictate anything. I merely pointed out that I never met the need for what you called an 'incredibly useful' feature. If I and most of the developers I know, and potentially many others on this thread never met the need for that particular feature, then it should not stated as incredibly useful.That is all I meant.

    Fair enough. I did phrase it carefully: I said that 'I found it incredibly useful'. I did not generalise.
    It is not about what I want, it is about what I need. If I don't need an API that allows for non-relational persistence, then I won't use it. If my business requirements state otherwise, then I will.

    That is one of the advantages of JDO - it supports such a change in your business requirements... now that with JDO 2.0, JDO has become a decent and versatile tool for O/R systems (I was not that happy with JDO 1.0), I simply don't see the point in actively working to restrict your choices. If something provides both relational persistence AND non-relational persistice (of course you may need to choose the right JDO implementation for your choice of store), while preserving your codebase... well, that's just my view. If you are sure you are really only going to use relational stores, Hibernate is a fine product, as you obviously know.

    Thanks for the discussion.
  187. In short, Java isn't just J2EE, and persistence isn't just relational.
    Ok, I can repeat it again. There is no relational persistence. Persistence is a low level stuff and you do not need to care about it, RDBMS manages it. ORM is Object to Relation Mapping framework, it is not about persistence, it delegates this low level stuff for database. It is a good idea to use RDBMS as database management system, RDBMS is not designed as application state persistence system and it is not a persistent store.
  188. In short, Java isn't just J2EE, and persistence isn't just relational.
    Ok, I can repeat it again. There is no relational persistence. Persistence is a low level stuff and you do not need to care about it, RDBMS manages it. ORM is Object to Relation Mapping framework, it is not about persistence, it delegates this low level stuff for database. It is a good idea to use RDBMS as database management system, RDBMS is not designed as application state persistence system and it is not a persistent store.

    Ok, just for you:

    "Java isn't just J2EE, and not all storage and retrieval of information is to RDBMSes."
  189. Ok, just for you:"Java isn't just J2EE, and not all storage and retrieval of information is to RDBMSes."
    Why do you want to use Hibernate for ETL if you understand it yourself ? ETL is a missing feature in Hibernate, just use some tool designed to extract data from legacy persistent store, transform and load to RDBMS. There are many tools designed to solve network database or flat file problem or jus "cat data.txt | transform.awk | sql connection.cfg ".
  190. Ok, just for you:"Java isn't just J2EE, and not all storage and retrieval of information is to RDBMSes."
    Why do you want to use Hibernate for ETL if you understand it yourself ? ETL is a missing feature in Hibernate, just use some tool designed to extract data from legacy persistent store, transform and load to RDBMS. There are many tools designed to solve network database or flat file problem or jus "cat data.txt | transform.awk | sql connection.cfg ".

    Because I believe strongly in the DRY (Don't Repeat Yourself) principle. I like single points of change. I am dealing with a large object model, and that is the place where I want to make changes. I am also running on at least three databases - a development database, a testing database and a final deployment database. Data loading has to occur into each of these databases. These databases are different. If I used scripts the way you indicate I would have to have to duplicate the aspects of the object model in each of the scripts for each of the databases, and co-ordinate changes in these scripts every time I changed the object model, and I would have to test each of these scripts. (The data loading process is not just loading - it involves building relationships between the objects. This means that the SQL in each script would have to contain specific information about the structure of the objects).

    This would be a maintenance and testing nightmare.

    With ORM I make changes in just one place: the object model. The ORM tool I am using can easily update the schemas in the different databases based on these changes, and I can switch between databases just by changing a single configuration file.

    This may not be the fastest way to run the data loading (although I did perform some benchmarking, and found that, in this case, doing the loading and processing via an ORM was not significantly slower than using SQL directly (pgSQL on one of the databases)), but it was far simpler to set up, and has been easy to maintain and test.
  191. DRY![ Go to top ]

    Preach it Steve! Can I get a witness?

    BTW, just had FUN (not) conversation with a DBA about application pulling data (which he meant application code "pulling" from database). We were not on the same page cause same data IS loaded in the database and, in my view of things, that is what I thought he meant.
  192. DRY![ Go to top ]

    Preach it Steve! Can I get a witness?

    You may quote me any time! (assuming there is no copyright on TSS posts).
  193. DRY![ Go to top ]

    Preach it Steve! Can I get a witness?BTW, just had FUN (not) conversation with a DBA about application pulling data (which he meant application code "pulling" from database). We were not on the same page cause same data IS loaded in the database and, in my view of things, that is what I thought he meant.

    I'll be your witness! It's all about the Domain Object Model baby!!
  194. DRY![ Go to top ]

    I'll be your witness! It's all about the Domain Object Model baby!!

    Oh dear, is this irony? I never can tell.
  195. DRY![ Go to top ]

    I'll be your witness! It's all about the Domain Object Model baby!!
    Oh dear, is this irony? I never can tell.

    Definitely not irony Steve. I love your posts!

    I am also a happy JDO user who absolutely loves JDO's focus on the object model. No requirement to have an identity field in your business objects, JDOQL queries are in terms of the object model, etc.

    Loosing this focus is one of my biggest worries about JSR-220. From reading the draft spec it seems much more focused on the data store (relational only) then the object model. This is a huge step back in my opinion. Hopefully Craig, Patrick, and the boys can refocus this thing a little bit.
  196. DRY![ Go to top ]

    I am also a happy JDO user who absolutely loves JDO's focus on the object model. No requirement to have an identity field in your business objects, JDOQL queries are in terms of the object model, etc.
    Count me another and totally agree with you.
  197. DRY![ Go to top ]

    Definitely not irony Steve. I love your posts!

    Well, I'm English and we are not used to dealing with praise or enthusiasm :)
    I am also a happy JDO user who absolutely loves JDO's focus on the object model. No requirement to have an identity field in your business objects, JDOQL queries are in terms of the object model, etc. Loosing this focus is one of my biggest worries about JSR-220. From reading the draft spec it seems much more focused on the data store (relational only) then the object model. This is a huge step back in my opinion. Hopefully Craig, Patrick, and the boys can refocus this thing a little bit.

    I'm not that concerned now: the successful vote for JDO 2.0 has encouraged my belief that developers who want to use the JDO style of working are going to be supported long term whatever happens to EJB 3.0. That certainly seems to be the attitude of JDO vendors that I know about.

    I will follow the progress of EJB 3.0 with interest. I suspect that EJB 3.0 POJO persistence will retain its focus on the relational data store: It has to be somewhat different from JDO, because if it doesn't, it will be difficult to justify inventing a new API, as against extending the existing JDO spec. Of course, if it does not provide equivalent (or a superset of) features to JDO, then it can't be called a 'unified persistence' approach, and then there is no justification for deprecating JDO (Assuming that deprecating an existing JSR is even possible)! It's a paradoxical situation, or maybe I'm missing some key part of the plan.
  198. The last ETL stuff I have saw was ~100 GB of data per "session", including delta calculation and duplicate "hunting" (it was a data transformation from legacy network to relational model stuff ). I do not know it is "large" or "small", but I do not know an easy and object oreinted way to solve this problem.
  199. The last ETL stuff I have saw was ~100 GB of data per "session", including delta calculation and duplicate "hunting" (it was a data transformation from legacy network to relational model stuff ). I do not know it is "large" or "small", but I do not know an easy and object oreinted way to solve this problem.

    Well, I would not want to be the one trying to maintain changes to the data model if this data was represented in hundreds of tables was having to be run into several different vendors databases.

    I'm using a commercial JDO product to manage this kind of thing. It works fine. It is both object oriented and easy! I'm would imagine that Hibernate would work for this too.

    So now you do know.
  200. Well, there should be little objection to JDO 2.0 then, which addresses many of these issues.
    Hibernate forced them to the table by providing the de facto universal standard.
    ... for relational databases. Not all persistence is to relational stores. JDO is datastore-neutral. I find that incredibly useful.
    Well, let me say. When I first started reading about persistence solutions and came across JDO and Hibernate, I noticed that Hibernate directly addressed this issue. It was basically, "How often to you find yourselves needing to write to a text file, an OODBMS, or RDBMS? We decided to optimized the experience for the task we feel most developers do."I agreed with that philosophy. For my work, for the developers I know, we all use relational databases. None of had to worry about an application that some day, had to switch to some other form of persistence.Which is not to say that feature isn't useful, just not for me. Ever. It has never come up. In ten years.So, that wasn't a feature of JDO that was compelling...to me.I've found Hibernate support reasonable. Not perfect, but I've found the answers. And it has proven itself across several projects at my current position, and has definitely saved us time and effort while improving the quality of our work.I have no reserverations about recommending it as a solution.

    Funny thing is that, as you stated, Hibernate has been developed with a firm focus on just ORM and not generic object persistence.

    I have had extensive experience with JDO1.0.1 and worked with JDO implementations that have JDO2 preview features. I have also dabbled with Hibernate (though I have not used it on production applications). In my experience I really can't see how Hibernate has done a 'better' job at ORM than JDO2. I would say that the two are comparable. Thus, JDO2's ability to also target non-relational datastores is a nice value-add, that as far as I can tell, absolutely does not hinder its ability to do ORM well.

    Just my 2 cents.....
  201. Well, there should be little objection to JDO 2.0 then, which addresses many of these issues.
    Hibernate forced them to the table by providing the de facto universal standard.
    ... for relational databases. Not all persistence is to relational stores. JDO is datastore-neutral. I find that incredibly useful.
    Well, let me say. When I first started reading about persistence solutions and came across JDO and Hibernate, I noticed that Hibernate directly addressed this issue. It was basically, "How often to you find yourselves needing to write to a text file, an OODBMS, or RDBMS? We decided to optimized the experience for the task we feel most developers do."I agreed with that philosophy. For my work, for the developers I know, we all use relational databases. None of had to worry about an application that some day, had to switch to some other form of persistence.Which is not to say that feature isn't useful, just not for me. Ever. It has never come up. In ten years.So, that wasn't a feature of JDO that was compelling...to me.I've found Hibernate support reasonable. Not perfect, but I've found the answers. And it has proven itself across several projects at my current position, and has definitely saved us time and effort while improving the quality of our work.I have no reserverations about recommending it as a solution.
    Funny thing is that, as you stated, Hibernate has been developed with a firm focus on just ORM and not generic object persistence. I have had extensive experience with JDO1.0.1 and worked with JDO implementations that have JDO2 preview features. I have also dabbled with Hibernate (though I have not used it on production applications). In my experience I really can't see how Hibernate has done a 'better' job at ORM than JDO2. I would say that the two are comparable. Thus, JDO2's ability to also target non-relational datastores is a nice value-add, that as far as I can tell, absolutely does not hinder its ability to do ORM well.Just my 2 cents.....

    Well, to reconstruct my thoughts from late 2002. At the time, I was wide open to any solution and I tried trivial examples in Toplink, Cocobase, JDO, and Hibernate.

    We had a license for Toplink, for example, so the issue wasn't cost.

    Perhaps Hibernate just talked a better game. The sql-like language was compelling. It seemed to impose very little impact on our application design. The support forums were nice. Documentation reasonable. Free. I liked how they handled things like collections. The XML config files where straightforward.

    Which is not to say that JDO didn't fully do these things, or didn't catch up, but at the time, I didn't see a feature that I would pretty much never use as a feature.

    Beyond those trivial examples to get the "flavor", I haven't done enough with JDO to really say that it good, bad, or indifferent. I am certainly willing to concede that base on my experience with TSS, that if probably works quite well.

    But when I had to make a decision, Hibernate came across as the more appropriate choice.
  202. I agreed with that philosophy. For my work, for the developers I know, we all use relational databases. None of had to worry about an application that some day, had to switch to some other form of persistence.
    I wondered who had Rolf's crystal ball.
  203. I agreed with that philosophy. For my work, for the developers I know, we all use relational databases. None of had to worry about an application that some day, had to switch to some other form of persistence.
    I wondered who had Rolf's crystal ball.

    :-) Well, I don't need a crystal ball to know what I've been doing for the past decade. And I also know about projects for the coming year, so I'm feeling pretty confident about the type of work I tend to gravitate toward.

    I just no longer feel the need to try to anticipate every possible scenario when my personal experience allows me to filter out unnecessary decision.
  204. :-) Well, I don't need a crystal ball to know what I've been doing for the past decade. And I also know about projects for the coming year, so I'm feeling pretty confident about the type of work I tend to gravitate toward.I just no longer feel the need to try to anticipate every possible scenario when my personal experience allows me to filter out unnecessary decision.
    Sorry. I re-read and you did use the past tense. Boy do I feel like a Rolf. Of course anyone can predict the past. And you probably are right about the future too. There is no way to change if you can't.
  205. :-) Well, I don't need a crystal ball to know what I've been doing for the past decade. And I also know about projects for the coming year, so I'm feeling pretty confident about the type of work I tend to gravitate toward.I just no longer feel the need to try to anticipate every possible scenario when my personal experience allows me to filter out unnecessary decision.
    Sorry. I re-read and you did use the past tense. Boy do I feel like a Rolf. Of course anyone can predict the past. And you probably are right about the future too. There is no way to change if you can't.

    Again, it is less an issue of predicting and more an issue of the type of work we tend to do. If 99% of your projects are server-side, Java apps that use some form of Oracle, it doesn't take a psychic with a set of tarot cards to know what the next project will be.
  206. Again, it is less an issue of predicting and more an issue of the type of work we tend to do. If 99% of your projects are server-side, Java apps that use some form of Oracle, it doesn't take a psychic with a set of tarot cards to know what the next project will be.
    That's too bad. You are robbed of a lot of what is good about Java.
  207. Again, it is less an issue of predicting and more an issue of the type of work we tend to do. If 99% of your projects are server-side, Java apps that use some form of Oracle, it doesn't take a psychic with a set of tarot cards to know what the next project will be.
    That's too bad. You are robbed of a lot of what is good about Java.

    Please. I absolutely enjoy my work. IMO, server side is where the action is. I get to work with a variety of web frameworks, IOC containers, and persistence technologies. The entire J2EE stack is at my disposal and I get to deploy from anywhere from tens to thousands of users depending on the project. Pretty much the entire spectrum of Java is at my disposal and I get paid a wad to use this stuff.

    On top of that, I have the trust of my management to try any technology I see fit to get the job done.

    What exactly am I missing?
  208. What exactly am I missing?
    DB2, MySQL, HSQL, Firebird, etc?

    Sorry David, I was trying to offend you. When you said Oracle I wasn't limiting it to just the database. So why don't they trust you to not use Oracle or maybe some ODBMS? (Sorry, can't stop myself) That is ok, I am sort of in the same boat.
  209. What exactly am I missing?
    DB2, MySQL, HSQL, Firebird, etc?Sorry David, I was trying to offend you. When you said Oracle I wasn't limiting it to just the database. So why don't they trust you to not use Oracle or maybe some ODBMS? (Sorry, can't stop myself) That is ok, I am sort of in the same boat.
    OOOPS I meant NOT trying. I was posting late. Sorry David. Boy, I am a ROLF.
  210. What exactly am I missing?
    DB2, MySQL, HSQL, Firebird, etc?Sorry David, I was trying to offend you. When you said Oracle I wasn't limiting it to just the database. So why don't they trust you to not use Oracle or maybe some ODBMS? (Sorry, can't stop myself) That is ok, I am sort of in the same boat.
    OOOPS I meant NOT trying. I was posting late. Sorry David. Boy, I am a ROLF.

    :-) I understand. Hey TSS, when will we be able to edit posts?!?
  211. What exactly am I missing?
    DB2, MySQL, HSQL, Firebird, etc?Sorry David, I was trying to offend you. When you said Oracle I wasn't limiting it to just the database. So why don't they trust you to not use Oracle or maybe some ODBMS? (Sorry, can't stop myself) That is ok, I am sort of in the same boat.

    Don't worry about! Shouldn't have thin skin. We have had other DBs come up, but most of the time Oracle. <Shrug>

    The database is a customer choice. At my last job, it was DB2, but just about every job we do is Oracle database because that's what they have in house. Generally speaking, the specifics of the app(persistence layer, middle layer, presentation) they really haven't cared. We mention these things to assure the customer that their software will be easy to maintain and have a steady flow of talent available if we are out of the picture.

    We had to "port" one of the apps to SQL Server, but Hibernate made that pretty trivial.