Although according to some articles Herbinate is going to become the persistence mechanism within EJB 3.0, my understanding is this has not yet been decided and a final decision on this is not expected any time soon. Is there any news of this?
I think you've missunderstood here. There is no intention of incorporating Hibernate in an EJB spec. Sun could only do this if they open sourced their EJB, because of the licence Hibernate is written under. This is something they are apparently mulling over, but as with other Sun owned IP they seem to be in a permenant state of "mull" - so that's a whole other
thread. Because of this the answer to your second question ("what are the chances of the EJB 3.0 actually maintaining compatibility with the current hibernate") is almost none, since they are unrelated products.
Hibernate has however proved very popular, so much so that latest indication is that Sun will copy its architecture (uncreditied naturaly) for the next EJB release. So its incorrect to assume you could write a persistance layer using Hibernate and have it miraculously match the persistance layer for EJB3, though a lot of the concepts would be simmilar.
As for their intentions regarding JDO you'd have to ask Gavin et al. There is however no mention of it in their roadmap for Hibernate 3. JDO and Hibernate are comparable technologies - so I'd have to question why you'd want to include any aspect of JDB in HIbernate. It seems a little pointless.
How many large scale application have real drop the current EJBs for hibernate with the hope to develop a more future proof application?
I don't know. But I can say I've worked on a good few (and am aware of many more) projects who use Hibernate as an ORM layer because EJB2's ORM capabilities are so god awful. Future proofing is very hard. I can't say that Hibernate will be around in a few years. But then again I can't say
JBoss, or Apache HTTP Server, or
Tomcat, or MYSQL etc. will be. Its a problem with all open source products. And given Sun's continuing debts - who can say whether they will be there long term? The best way to future proof anything, as far as it is possible, is to develop an application in layers, writing to interfaces and well defined open specifications. In which case selecting an ORM layer should just be a case of picking the best
now rather than what might be good a few years from now, and writing your app in such a way that changing the ORM layer can be managed with the least amount of disruption.
[ July 01, 2004: Message edited by: Paul Sturrock ]