• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Hibernate, JDO 2.0 and EJB 3.0

 
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

I am just undertaking a large J2EE application and could real do with some advice.

We started the project using EJB but today got told that we are changing to use Hibernate as apparently "we may as well use Hibernate now instead of changing the application when EJB 3.0 comes out".

I know that there are a number of threads on this forum that compare Hibernate vs JDO vs EJB however I am interested in the future of Hibernate.

I am a fan of herbinate but am against using it in a large scale application as the only persistence mechanism at this time.

My main objections are:

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?

Even if Hibernate did become the main persistence mechanism for EJB 3.0 what are the chances of the EJB 3.0 actually maintaining compatibility with the current hibernate. What I see being some likely is that EJB 3.0 will take small bits from a number of projects including hibernate. So even when EJB 3.0 is released any project that has today chosen to use hibernate will still have to make changes in order to support EJB 3.0.

My understanding is that the hibenate team have not yet decide if they are going to implement JDO 2.Althought hibernate has been well managed so far I fear that this may cause hibernate to lose it focus.

Although hibernate has been around a while and release 2.0 is out. What are the chances of the hibernate team maintaining backward compatibility between the current release of and the future releases. Lets face it hibernate is going to change dramatically in the future depending on if they focused on EJB 3.0 or the JD0 2.0 spec.

How many large scale application have real drop the current EJBs for hibernate with the hope to develop a more future proof application?

If I was developing an application that had a short life span I would actually use hibernate. As I see hibernate having a lot of advantage over the current EJB spec. This would main I would not need to be concerned about the changes in EJB 3.0 as EJB 3.0 will not be released until 2005. However as I am developing an application that is likely to be about for many years this decision is become much harder.


Thanks

Chris.
 
Ranch Hand
Posts: 214
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Your team is writing an application to an unfinished specification. They don't call it the "bleeding edge" for nothing.
 
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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 ]
 
Chris Harris
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Paul,

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.



After reading the early draft release of the EJB 3.0 spec, I totaly agree with you comment.

Chris.
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The EJB 3.0 specification will probably incorporate some of the great features of Hibernate, as Gavin is on the JSR Expert group, however, it is a group of people all with great ideas, so I think the specification will be a best practices specification with some of the new features of Tiger and future releases of Java.

I was at a session last night that tested the usability, ease of finding resources, finding experts and documentation ease. A little bit on query performance, but the tests were run out of the box, meaning they did not tweak the configuration to speed up queries. The final results was basically that with all the variables Hibernate clearly won. Now, you can obviously have some arguments to the complete validity of their tests, but in general it appears using Hibernate is a great choice.

Mark
 
Ranch Hand
Posts: 538
Hibernate Eclipse IDE Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

I would like to warn about one fact : whatever java related persistence system you choose, you should think "JDO compatible ?" as first criteria.
I refuse by advance to argue anything, because Hibernate is great and popular too, but here are the facts that make me think so :

_ JDO already IS a standard totally agreed and supported by Sun.
_ JDO can perfectly be integrated into EJB, and Hibernate greatly wonders about becoming JDO compatible. In fact JDO can replace native EJB persistance for greater simplicity and better performances but it without any conflit, it can simply enhance EJB one this single point without denagating the others (security, pools, scalability, ...).
_ All EJB 3.0 goals are already JDO compatible.
_ JDO is not simply a persistance model but an EAI .

I REALLY STRONGLY suggest that you meet some people who were present at Java-One convention last mounth, because all strategical market deciders are in favor of JDO for many reasons, apart very few actors. According to some opinions reported to me, JDO seems about to overwhelm all Java related persistance field simply because market wants it.

But of course, if you prefer to rely on Hibernate anyway it looks like a sensible choice too, although no standard at all. Simply check you can use XDoclet annotation types because EJB 3.0 will use such thing.

Best regards.
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Eric Lemaitre:
All EJB 3.0 goals are already JDO compatible.


Maybe, but not the other way around. At JavaOne I attended a Q&A with Craig Russell, the lead architect of JDO. There is no guarantee that JDO & EJB 3.0 will converge on a common spec and though there seems to be some communication between the groups, JDO & EJB 3 are on two separate tracks.

I would side with the previous post that when the EJB 3 spec is finalized, it may more closely resemble Hibernate than JDO. However, This does not mean that either Hibernate or EJB 3 are now or will be more appropriate than JDO. For instance, JDO (unlike Hibernate) uses bytecode enhancement to optimize load strategies, and Craig Russell mentioned was that bytecode enhancement was one of the things the EJB 3 folks balked at. If your application deals with large object trees, this may be an important consideration.

Still, I think the main issue has less to do with differences, and more to do with similarities; it looks like EJB 3 will finally get it right by adopting POJO-oriented persistence which means that most of your business code can remain untouched, regardless of which technology you finally settle on.
[ July 05, 2004: Message edited by: Cliff Resnick ]
 
Eric Lemaitre
Ranch Hand
Posts: 538
Hibernate Eclipse IDE Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Cliff !

You are totally right to me, but my dear friend... this is not the point at all : EJB is a framework with many excellent features including persistance among them, while JDO is about persistance only and nothing else. You can take JDO into J2ME with tiny footprint, while you simply cannot make any J2EE embedded, it is far too big. So JDO is a persitance solution only while J2EE is a framework including persistance features which are totally JDO compatible. So according to me you miss the point, J2EE can exist with JDO but JDO can exist without J2EE. So adopting EJB-3 will ALLWAYS allow you to use JDO along ANYWAY, this is why I said in short "JDO anyway".

Using bytecode enhancement is no issue, it is even not JDO mandatory, and as anyway it is perfectly implementable as an AOP feature so through EJB-3's annotation feature, this is simply not a point to consider, some JDO implementations simply don't use bytecode enhancement at all.

With POJO-oriented persistence argument leaving "most" of your business code can remain untouched (what is "most" signification in this case, which parts should be touched and why), I still don't understand what your "value added"
argument is about. This is about the same argument than above, your business code can remain untouched while you develop, then it can be processed at deployment for implementing JDO. I don't remember the benchmarks, but I believe I remember performance record held by LIDO's JDO implementation is about 700 (yes, seven hundred) times faster than standard Java for some particulary favourable process. If you leave your business code untouched and rely on EJB enhanced features (pools, caches, container managed concurency, ...) you will get performance improvements but NEVER that much. So if you can develop your business code as usual and process it unintrusively at deployment by either AOP annotation or some JDO transparent processing, WHAT is the issue ?

In all EJB-3 will fit JDO, but Hibernate perhaps won't ever fit neither JDO nor EJB-3 and won't ever become a standard (it's JDO already, Sun & JCP approved).

Best regards.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic