Link Details

That's funny. "I'll post the same comment I post every few years on this bug" :-)
Funnier still that people stick with this when there is ample choice on persistence solutions these days.

And funny still that in 5 years, no one in the community, all those who complained so much, stepped up to provide a patch. The point of open source is so that the code is open, and anyone can provide a patch. All I see in that jira are people complaining a lot, and not doing anything about it.

If it was a project that people would work on during their free time, your argument would be totally valid, but Hibernate's development is funded by RedHat. It is open-source per license, but it is also a vehicle for them to sell their stack/support/consulting/etc.

Also, don't forget that most patches for Hibernate aren't exactly trivial. You really need to invest a lot of time in getting to know the code, and then you're still not sure whether your patch is actually the correct solution.

So, basically the GP is right. We as Java programmers should supply patches too, but specifically in the case of Hibernate only a very select few of us will have the capabilities to actually do.

The madness of king Gavin! Good point, sjmenden, however, if it’s “not a bug” would a patch be accepted?
,

Yes most likely, there are other developers who work on Hibernate. For example Gail ultimately did the patch. Had there be a viable community patch submitted sooner, I would be willing to bet this jira would never have gone 5 years.

http://code.google.com/p/persist/

Well at least Gavin King does not call everyone idiots in this thread, I had expected that.

Then again, he probably had forgotten about the thread as he never reacted again.

It would be cool to see a reaction from Gavin about this thread. Does he still thinks it's not a bug?

Unfortunately that particular thread highlights my exact problem with Hibernate. It's a cool product and all, but there are so many of those tiny small issues open for many years and the reaction is always the same: "it's not a bug" or "provide a patch".

Same here, but what is your alternative choice?

That's our problem too. What's the alternative? I wanted to try out TopLink/EclipseLink, but some of my team members had already done so and told me it had some incredibly basic bugs too.

We mostly just try to workaround the bugs or omissions.

As another silly example. In Hibernate you can't define a pure scalar native query as a named query. It throws a not implemented exception and has been doing so for the last 5 years or so. It is however trivial to just create the query from a String and execute it. It's two lines of user code, so how hard can it be for Hibernate to fix this internally?

The stagnation is something that makes me sick about Hibernate, too. But I have not had the guts lately to switch to Django to finally get rid of it. I am using the Play Framework for productivity reasons and I love the Web Framework, but the thing that holds me back the most currently is Hibernate, because it is just so easy to break it.

Well, it doesn't really seem like true stagnation. New versions are coming out with new features etc, but they seem to have fallen into the trap of only wanting to work on the New & Exciting stuff, and thus fail to fix many of the tedious and basic bugs in the core ORM system.

They might be adding features, but who needs them? I have no use for that MetaModel-generator thing they probably just spent hours and hours of working on.

Why dont they fix the association management nonsense aka:

Order parentOrder = orderLineToRemove.getOrder();
parentOrder.removeOrderLine(orderLineToRemove);

Its 2010 and we still have to deal with this shit.

Indeed, very few people needs them, but obviously the developers like to work on it.

Being developers ourselves, we probably know how this goes. Do you stand in line to be part of that sexy new project your company is working on, or do you stand in line to fix that odd difficult to reproduce bug that this one customer keeps complaining about?

The natural tendency of most developers is to avoid that last thing. Luckily for the customers, most companies have something called a bos who simply orders the programmers to get a good amount of bugs fixed.

The Hibernate project seems to be missing such a boss...

Yeah either that, or and that is in my mind what is reall going on: There is not interest in fixing them. Can you sell consultant hours around a perfeclty working, well documented framework that even idiots can use to get their problems done? Hell no. You gotta have the JEE-label, books out and just enough bugs in them so people wont figure it out themselves and require you to get things done.

p.s. about the example, I hate to say it (as I detest EJB2), but that is the one single thing EJB2's evil entity beans did manage to do right :P

Yeah... one should dig through those old containers to find the relevant CMP code and fork hibernate and strap it onto it.

Pay no attention to the relational database behind the leaky abstraction! (With apologies to Wizard of Oz)
,

I think you guys are way over exaggerating the 'unwillingness' of Hibernate devs to fix old bugs. Here is reality, there are a limited number of core devs + practically an unlimited number of bugs + the push for future releases (JP2/EE6 anyone?). The math just doesn't work out. There are priorities the devs must work on, and one of those priorities probably isn't going to be an old bug that isn't critical in an old release. So again, Hibernate is an open source project. If you desperately want some behaviour/bug/feature request patch, code it and submit the patch!

I do sympathize with the uphill battle that a seemingly unlimited amount of bugs can be.

In my own software product we unfortunately also have tons of bugs, some of them take mere minutes to fix and have been open for a shameful long time. But just because it is 'mere minutes' to fix didn't mean we could have fixed it right away, since 1000 x 'mere minutes' equals a lot of working days, so you have to make choices.

Nevertheless, for the customers/users it's not really an excuse. Apparently the product has gotten too big and too complex to be maintained by such a limited amount of core developers. I know this is true in the case of our product, but I guess it's true for Hibernate too.

I'm not sure how much revenue Hibernate generates for Red Hat and how critical Hiberate/JPA is to them, but I can't escape the feeling that there is some unbalance in the importance of Hibernate vs the resources Red Hat allocates to it.

>So again, Hibernate is an open source project. If you desperately want some behaviour/bug/feature request patch, code it and submit the patch!

I'm very much looking into this really, up to the point where I've done extended debugging (costing me lots of hours) so I could at least point to the exact location in the code and the exact condition under which something fails. I added that to JIRA issues as a first step to develop a patch. Unfortunately, there simply has been no reply whatsoever.

If you're not elbow deep in the Hibernate code, it's extremely difficult to know you're even on the right track. If I don't even get any feedback after an analysis of the source code, I have very little confidence I get feedback for an actual patch.

The 'official' Hibernate forum is a complete joke too. Before creating a new JIRA issue for what I think is a bug, I would like to discuss it on the forum first. So I post a topic where I describe a minimal case that points out the issue, but there simply is no response from any developer. I wonder whether Hibernate developers actually -know- they have an 'official forum'?

Setting up such a test case actually costs me a lot of time too. I have to create a new minimal project, set up a test DB, think of a minimal test case that only demonstrates the problem and nothing else. Then I test with various Hibernate versions and a couple of different databases and JVMs, just to rule out problems with the environment. This takes me at least a full day of my time, time I don't mind spending, but if I get *zero* response, then it's not actually encouraging me to spend more time, is it?

>> I'm not sure how much revenue Hibernate generates for Red Hat and how critical Hiberate/JPA >> is to them, but I can't escape the feeling that there is some unbalance in the importance of Hibernate vs the resources Red Hat allocates to it.

The persistence solution is a strategic asset. You can only sell products and consultant hours around it, if you have it (app-servers, sub-projects (hibernate search, ...), app-frameworks, etc). Solutions for messaging, persistence and runtime are key here. The rest of the portfolio rely on it.