Hibernate 3.5.1 Released: Supporting JSR 317 a.k.a. The JPA 2 Specification

Discussions

News: Hibernate 3.5.1 Released: Supporting JSR 317 a.k.a. The JPA 2 Specification

Bookmark and Share Get thread feed

  1. Hibernate 3.5.1 Released: Supporting JSR 317 a.k.a. The JPA 2 Specification (16 messages)

    Hibernate 3.5 Tutorials from TheServerSide.com:

    Hibernate 3.5 Tutorial Part I: Getting Started with Hibernate & JPA 2.0
    Hibernate 3.5 Tutorial Part II: CRUD Operations with Hibernate & JPA 2.0
    ____________

    Hibernate 3.5    , with support for JPA2, went GA on March 31st.

    Of course, you never go with the first release of a product, because you know a
    new updated will be right around the corner. Well, 15 days later, Hibernate 3.5
    incremented their release number by a fraction. What does that mean? Well, it
    means it's time to jump into Hibernate 3.5.1.

    From JBoss' own discussion of Hibernate 3.5, here's what's in the latest release:

    ***JSR 317 (JPA2) support.
    ***Integration of hibernate-annotations,
    hibernate-entitymanager and hibernate-envers into the core project.
    ***Added Infinispan as a standard second-level cache.
    ***Improvements to the new second-level caching SPI introduced
    in 3.3 based on feedback from implementers including Ehcache, Inifinispan and
    JBoss Cache.
    ***Far better read only / immutable support.
    ***Support for JDBC 4 such that Hibernate can be used in JDK
    1.6 JVMs and make use of JDBC4-compliant drivers.'
    ***Support for column-level read/write fragments (HBM only for
    now)
    ***Initial support for fetch profiles

    Hibernate 3.5.1-Final Released

    Oh, and never missing an opportunity for self-promotion, if you're interested in learning Hibernate, pick up a copy of my book "Hibernate Made Easy." Of course, that edition covers the 3.4 version of Hibernate. Looks like I'm going to be spending some time doing some 3.5 updates.


    Happy Hibernating!

    ***********************

    Learn Hibernate 3.5 Today!

    Hibernate 3.5 Tutorial Part I: Getting Started with Hibernate & JPA 2.0
    Hibernate 3.5 Tutorial Part II: CRUD Operations with Hibernate & JPA 2.0

    Reply to this

    Threaded Messages (16)

  2. Hibernate 3.5.1 Released: Supporting JSR 317 a.k.a. The JPA 2 Specification[ Go to top ]

    Maybe you can start fixing bugs in your bugtracker?

    Seriously, a lot of stuff sits there for YEARS without getting ANY attention. Like trivial things for "nulls first/last" clause in "order by".

    And some parts of Hiberanate never really worked at all. For example, bytecode-instrumented lazy loading was never properly tested.
    Reply to this Reply to original

  3. Things are changing at Hibernate[ Go to top ]

    There's no doubt that there have been areas for improvement in earlier versions of Hibernate. At the same time, since joining JBoss, there has been an overwhelmingly positive impact on code control and quality. I'm actually excited about this release.
    Reply to this Reply to original

  4. Things are changing at Hibernate[ Go to top ]

    There's no doubt that there have been areas for improvement in earlier versions of Hibernate. At the same time, since joining JBoss, there has been an overwhelmingly positive impact on code control and quality.
    Funny, I haven't noticed them. If anything, Hibernate development has stagnated since its acquisition by JBoss.

    Number of opened issues is consistently greater than the number of closed issues. And a lot of open issues are quite serious:

    http://opensource.atlassian.com/projects/hibernate/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+HHH+AND+status+in+%28Open%2C+%22In+Progress%22%2C+Reopened%29

    And on top of this, Hibernate is dog-slow. I got tired with all of this and just ditched Hibernate.
    Reply to this Reply to original

  5. Things are changing at Hibernate[ Go to top ]

    I got tired with all of this and just ditched Hibernate.

    Replaced with ...?
    Reply to this Reply to original

  6. Things are changing at Hibernate[ Go to top ]

    I got tired with all of this and just ditched Hibernate.
    Replaced with ...?
    My own simple ORM. It has no complex inheritance mapping (only discriminator-based inheritance), no support for weird mappings, certainly no mapping to XML, etc.

    But it's uber-fast (faster than everything I tested) and I'm planning to make it as fast as hand-written response mapping code, by compiling response mappers to Java bytecode.

    Oh, and I use QueryDSL as a query language.

    I'll release it under LGPL once I clean it up a bit.
    Reply to this Reply to original

  7. Not yet another homegrown ORM[ Go to top ]

    I got tired with all of this and just ditched Hibernate.
    Replaced with ...?
    My own simple ORM. [...]

    I'll release it under LGPL once I clean it up a bit.

    Now where did I heard this before... do us all a favor and don't... just don't...

    If you do feel the unstoppable urge, at least check those other 20+ home grown ORMs that were released the last half year alone. A couple of them posted about it at TSS as well. They were all super light weight, super fast, super simple, way better than everything else, etc. And then we never heard about them again...

    Hibernate is chockfull of bugs, but if you're not hitting any of those bugs than it actually works pretty well. JPA is a solid API as well and EclipseLink/TopLink is a pretty good alternative. I don't think the world needs yet another homegrown ORM, but it's your call... 

    Reply to this Reply to original

  8. Not yet another homegrown ORM[ Go to top ]

    Hibernate is chockfull of bugs, but if you're not hitting any of those bugs than it actually works pretty well. JPA is a solid API as well and EclipseLink/TopLink is a pretty good alternative. I don't think the world needs yet another homegrown ORM, but it's your call... 
    So, your argument is that Hibernate is fine because it's Hibernate? Funny.

    I think, that argument should have been applied to EJB2 long ago ('Hibernate' and 'Spring' who needs another frameworks when we have EJB?!), so that Java would have been safely dead and buried years ago. That would have saved us a lot of grief.

    Proliferation of ORM frameworks is a sign that people are NOT satisfied with the status quo. And hopefully, it will lead to development of new approaches to data management. Who knows? Maybe we'll even finally get something close to LINQ.

    PS: your post reminds me of 2003. Ah...
    "Spring Framework Celebrates 50th User" 
    Reply to this Reply to original

  9. Not yet another homegrown ORM[ Go to top ]



    >So, your argument is that Hibernate is fine because it's Hibernate? Funny.

    No, that's not really it. It's about finding a balance between new innovation and fragmenting the market. Indeed, maybe your ORM solution will take the world by storm and will be the next major revolution. But I somehow doubt it. I've seen so many posts about revolutionary new ORM solutions that I just grew weary of them.

    Do your self a favor, and just count all these other ones. There's usually a post about how much better they are, and how much the author believes in it, etc and then like I said earlier... nothing... no updates, no new releases, no nothing. All those half-baked projects just bit rot somewhere on SF.

    If you're REALLY prepared to devote a significant amount of time in your ORM solution, by all means go ahead. But be prepared to really devote LOTS of time to it. Don't throw us a free bone and see what happens, since basically nothing will happen automatically.

    As soon as real users start using your product, they will have issues with it. YOU know the product in and out, since you developed it. If you run into an issue when using it personally, you patch the source right away. When you miss a feature, you immediately add it. External users don't do that. They just don't. This means that YOU have to provide a very coherent API and documentation that goes far beyond those sparse Javadoc comments. You have to be willing to answer support question in some forum, fix bugs that people have for situations you don't have a personal stake in, etc. All too soon, it's not really that 'simple' anymore.

    In practice, few developers, especially lone developers, are able to cope with that. A small minority succeeds, but the overwhelming amount of attempts just bit rot.

    >I think, that argument should have been applied to EJB2 long ago ('Hibernate' and 'Spring' who needs another frameworks when we have EJB?!)

    Of course, I know where you're coming from. Spring has a lot of funding btw and was quickly able to attract other developers. Will you?

    Nevertheless, as said, I do agree that the fact that there is something else already doesn't mean someone else shouldn't try to do it better. Linux was created even though Solaris, AIX, Windows, etc already existed. Spring and Hibernate were created even though EJB2 already existed. Ironically, EJB3 and CDI were created even though Spring already existed, and now Springsource as well as Spring zealots are using that exact argument: "Why was EJB3 and CDI created if Spring "the original source of everything innovative in IT" (according to them), is already working?" (if you listen to the tech cast reported here: https://www.theserverside.com/news/thread.tss?thread_id=59955, they REALLY actually say that!).

    (p.s. the quoting in the compose window here pretty much sucks, can't remove it once added and can't remove the previous levels of comments)
    Reply to this Reply to original

  10. quoting in the compose window[ Go to top ]

    I just sat in a call where the developers demonstrated a solution to that little problem, and it will be fixed after testing and then when the next update goes to prod, which usually takes a week or two.
    Reply to this Reply to original

  11. Not yet another homegrown ORM[ Go to top ]

    My ORM was created because of a real need - Hibernate was not fast enough for our desktop GUI application (for which we've developed our own stand-alone GUI framework, but that's another story :) ). So it's not really motivated just by desire just to create yet another ORM. Also, I try to limit reinventing the wheel so I'm using a subset of JPA annotations to describe classes (and will probably implement a subset of JPA interfaces).

    Also, there's not that much ORMs for Java, actually. Or rather there are quite a lot of projects, but most of them are either pointless or dead.
    Reply to this Reply to original

  12. Not yet another homegrown ORM[ Go to top ]

    Also, there's not that much ORMs for Java, actually. Or rather there are quite a lot of projects, but most of them are either pointless or dead.

    *lol* which brings me back to my point ;)
    Reply to this Reply to original

  13. Fix the bugs[ Go to top ]

    Maybe you can start fixing bugs in your bugtracker?

    Seriously, a lot of stuff sits there for YEARS without getting ANY attention. Like trivial things for "nulls first/last" clause in "order by".

    Although I like Hibernate a lot, have been using it for quite some time and respect Gaving King a lot, I too am baffled by the huge amounts of large bugs that have been open for YEARS. 

    Every time I encounter a bug in Hibernate, someone has already opened a JIRA issue for it years ago. What's up with that?

    These bugs also concern JPA things that are in the specs. Doesn't the TCK test for that? I'm thinking about using a discriminator column for the joined strategy (maybe uncommon, but legal according to the JPA spec), the multiple bugs problem (nothing in the specs says an entity is not allowed to have these), or the @PostLoad in which you aren't allowed to access any collection. 
    Reply to this Reply to original

  14. TCK[ Go to top ]

    These bugs also concern JPA things that are in the specs. Doesn't the TCK test for that? 
    The thing is, you'll never find out what the JPA TCK actually tests for ... unless you sign an NDA to get your hands on it (JCP policy), and even then it is likely to take months to see it (SUN/Oracle bureaucracy). We requested it back in Feb and are still waiting, and we provide an implementation of it so you may have thought that it could get to us sooner.

    If the TCK was open then it would be available to users to contribute tests (or at least point out holes in its spec coverage) and it would become the definer for compliance, and would actually aid the implementations in knowing what exactly was required for that spec rather than having to have their own sets of tests that cover other things that the TCK doesn't cover.

    --Andy (DataNucleus)
    Reply to this Reply to original

  15. TCK[ Go to top ]

    These bugs also concern JPA things that are in the specs. Doesn't the TCK test for that? 
    The thing is, you'll never find out what the JPA TCK actually tests for ... 

    That is indeed a problem :(

    Perhaps they intend to prevent vendors from cheating and passing the test by implementing precisely what the TCK tests for? Of course the TCK coverage should actually be complete, but obviously it isn't. So to prevent vendors from cheating, Sun/Oracle decided to cheat.

    I'm not really sure which is worse. I find this whole situation highly confusing and a little disturbing to be honest...
    Reply to this Reply to original

  16. Hibernate 3.5.1 Released: Supporting JSR 317 a.k.a. The JPA 2 Specification[ Go to top ]

    Congrats to the Hibernate team. New releases with significant new features on a mature product like this are very hard. A lot of testing is needed...

    I'm not too thrilled about JPA 2 support, but the better support for read only or immutable beans sounds interesting. Any articles or docs on this?

    We use Hibernate for jBilling (it was not always the case, we started with the evil entity beans), and it is great.

    Cheers,

    E. Conde
    Lead Developer
    jBilling - Open Source Billing
    Reply to this Reply to original

  17. Hibernate wil be always cathing up....[ Go to top ]

    Products like Hibernate were born to correct an interface problem between two products / concepts - here Java and Relational Database. Or one can say between OO programming and Relational database. The new layers created, addresses the problems the original designers and devlopers encountered and updates are given to address the new problems. This never ends,,, one never gets a complete product.   Then changes in the base products (database and java) might invite other changes in Hibernate.  With all the Mapping one still depends on stored procedures just the same old way....


    In the long run these products become redundant or difficult to maintain! When we read that guys are making their own 'ORM' tools, we wonder whthere the technology is trying to reinvent the wheel or if the available wheelreally hopeless!!!
    Reply to this Reply to original