0

I have an EJB-based library that needs to be modified to be compatible with Tomcat application server (i.e. no JaveEE). I browsed a bit on Hibernate and got rather confused.

Apparently, there's the natural Hibernate branch that uses a .cfg file as base which is Java SE compliant and then there's a JPA-based Hibernate branch that conditionally depends on Java EE. One thing I also find annoying is that some interfaces are apparently not supported - CriteriaQuery for instance.

So I'd imagine, I would have to go the natural Hibernate branch to achieve the goal of ridding myself of Java EE (which is annoying given the differences). OTOH, there's also TomEE available that's Tomcat compliant and presumably let me keep most of my code unchanged

It's be nice if I can get some feedback. Thanks.

Some Newbie
  • 1,059
  • 3
  • 14
  • 33

3 Answers3

12

Some points:

  • Hibernate is a JPA implementation, one of three. Gavin King, creator of Hibernate, worked incredibly hard on JPA. Removing all JPA usage from an application is moving backwards, not forwards. You only lose portability for no gain.
  • You can use JPA in Tomcat with or without TomEE.

In terms of hating Java EE and wanting to move away from it, it really becomes an impossible task. All these technologies are part of Java EE:

  • Servlets
  • JSP
  • JSF
  • JPA
  • EJB
  • CDI / @Inject
  • JAX-RS
  • JAX-WS
  • JMS
  • Bean Validation

To label some of them as JavaEE and some as not JavaEE is a form of denial. They're all created and released as part of JavaEE.

It's near impossible to untangle the mess some of the anti-JavaEE marketing has caused. The truly damaging thing is that it's also near impossible to find a "not JavaEE" application that doesn't use 3 or more JavaEE technologies.

To answer the "heavy" issue and the "too much" issue, in 2010 the Web Profile was created so that smaller runtimes could be created without sacrificing portability. It includes:

  • Servlets
  • JSP
  • JSF
  • JPA
  • EJB (lite)
  • CDI / @Inject
  • Bean Validation

There are no distributed transactions and no heavy stuff. If you stack Tomcat, Hibernate and Spring, you'll be including:

  • Servlets
  • JSP
  • JPA
  • @Inject
  • Bean Validation

Those APIs will be there whether or not you chose to use them.

There's just so little value in using the implementations themselves but not using the standard APIs. It's a false victory. You'll still be using the same runtime code, you'll just have no portability.

David Blevins
  • 19,178
  • 3
  • 53
  • 68
  • Thanks for clarifying the 'Web Profile' stack, David. Personally I like using direct APIs -- extra layer of APIs on top of Hibernate, adds complexity with zero benefit. Architecturally I don't need portability off Hibernate, I will never need it, and pretending I do is incorrect. – Thomas W Oct 06 '12 at 04:13
  • Hibernate & Spring really invented the good style, of Java APIs for this. There's no 'anti-JavaEE marketing' -- just peoples' accurate impressions of how intrusive, heavy & obtuse the original J2EE architecture was. – Thomas W Oct 06 '12 at 04:15
  • 1
    People also accurately said Java was slow. Things change. – David Blevins Oct 06 '12 at 17:03
2

well spring framework or JavaEE are today close enough to choose depending on what you prefer (personnally that's Java EE but well do you prefer a BMW or a Mercedes? :p)

That's said JPA specification is not the best one and you easily use specific behavior link to hibernate/openjpa/eclipselink even hidden behind javax.persistence package

That's said it eases a lot the Java development once learnt

So my advice: go with TomEE and if you find something really blocking rewrite what you don't want but IMO you'll loose time

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
rmannibucau
  • 21
  • 1
0

I don't know about TomEE -- I expect if you just wanted to deploy into a different J2EE container, you'd do that already & not be needing to modify the code.

That said, the implication is that you want to move away from EE.

Unless you have or will need 'distributed transactions' or messaging support (eg, to/from IBM mainframes) my opinion is that J2EE is largely a failed architecture.

Tomcat, Spring & Hibernate pretty much on it's own (not using the JPA wrappers or API, which are mostly just an extra rip-off layer copying from Hibernate's original success) are what I recommend.

If you go annotations for HB config, you can use/combine the JPA ones (sometimes they have clearer syntax) while using the Hibernate API in code.

Cheers, hope this helps.

Thomas W
  • 13,940
  • 4
  • 58
  • 76
  • 1
    Can you tell me why EE is a failed architecture - I am genuinely curious to know your opinion. Also, I am quite confused about what to use and what not to use in Hibernate since it appears to have 2 systems. If I want to stay off EE, then what aspects of JPA can I use? Persistence.xml? Annotations? I am not sure about the pros here, but I feel Hibernate is a mess. Not to mention its lack of handling for generics. But anyhow, I am well into my progress of converting to a Hibernate framework. – Some Newbie Oct 02 '12 at 16:08
  • 2
    I don't think Gavin, creator of Hibernate, would describe the incredibly hard work he put into JPA as a "rip-off layer." – David Blevins Oct 05 '12 at 19:46
  • Thanks @SomeNewbie. J2EE's complicated, heavy & intrusive -- most people nowadays favour clean, light & non-intrusive solutions such as Spring & Hibernate. Applications can already be 'distributed' at the database connection -- running multiple Tomcat fronts, back to the database server. J2EE's idea of 'third tier' business logic connected by RMI, has found only limited practical benefit. – Thomas W Oct 06 '12 at 04:04
  • JPA's all usable, but really it's derived from the original Hibernate API. If you want to use Hibernate, for most purposes you may as well skip the extra layer & use Hibernate's API directly. – Thomas W Oct 06 '12 at 04:08
  • @DavidBlevins -- I guess I'm jaded by Sun ripping off Log4J's success, to make an almost-exact but incompatible copy. (Which seems to have failed in the marketplace.) I'd regarded JPA as a similar rip-off. Did Gavin want to participate, or did he just feel he 'had to' since Sun wanted to invent a standard in competition with his success? – Thomas W Oct 06 '12 at 04:10
  • 2
    @ThomasW Gavin was an excited and dominating force on JPA. He contributed even more in Java EE 6 as the CDI spec lead and a strong voice for the creation of the Web Profile. – David Blevins Oct 06 '12 at 16:58
  • 1
    @ThomasW - What's the story on Sun ripping off of Log4j's success? Also, I don't think JPA is a rip-off. There are things I like about JPA that is not part of native Hibernate. For instance, making CriteriaQuery in JPA allows an enforced compile-time type checking whereas this is not supported in the Criteria of Hibernate. Furthermore, the Session-Criteria framework does not support generics. – Some Newbie Oct 06 '12 at 23:45
  • 2
    @ThomasW I believe Gavin once explained that JPA among others gave him the opportunity to correct some things in Hibernate that because of compatibility were hard to do in Hibernate itself. It's a similar story with Joda Time and JSR 310. The Joda Time author (Stephen Colebourne) is also the spec lead of JSR 310. – Arjan Tijms Oct 07 '12 at 15:28