Is Java EE 5 easier with EJB?

Spring 2 and Hibernate(Java) should be compared to Ruby, C#/Mono, Flex+Gears, even php5(lots of large sites in silicon valley are LAMP), Lazarus, etc.
Compare readability, elegance, etc.

[Anotation] //like a macro?
Map <Map><String,Object> m = new HashMap.... // wtf?

XML, Hibrenate caching/treading intermittent issues for anything a big larger, Spring's aspects....
Java(Spring+Hibrenate) has gotten less readable relative to alternatives.

Java is lots of XML mapping, and harder to read. Anotations and Typing was added to base lang to make EJB product a bit less painful, but in the process Java got a bit worse. Where are days of KISS Struts and JDBC/iBatis.

(Groovy, T5, iBatis, Mina type projects are exceptions).

.V
ps: My Favorite now is D (wxD).

I'm curious if approaches like Seam help to bring people back 'into the fold' as well.

I'm still not sure that I'd seriously consider EJB for my next Java project, although it might not in and of itself disqualify other approaches (e.g. Seam).

hi,

as an experiment about a year ago we finished implementing a non-trivial SOAP service layer plus web-frontend using Java EE 5 (Hibernate via JPA, EJB3 stateless session beans, JAX-WS 2.0, JSF; on JBoss). My experiences in a nutshell:
- if you fully submit yourself to Java EE 5 it is a very clean, very concise programming model.
- the interplay between EJBs, the transaction manager and the JPA persistence manager is precisely defined by the spec and works correctly without needing to configure anything. Thus it's IMHO much easier to get a transactionally correct application up-and-running than with vanilla Spring and Hibernate. Having said that, the latter is not a big deal either (but it needs to be done and can be (and often is) done wrongly.)
- the single most severe restriction IMHO is that you can use DI only for JavaEE-supported resources (in contrast to the much more general Spring approach to DI). So all DAOs/Repositories need to be session beans; everything that calls an EJB must be an EJB (or JSF managed bean) itself (if you want to rely on JavaEE 5 DI). There is no indirection similar to Spring's proxy factory beans. In short, JavaEE 5 defines what can be injected and into which objects it can be injected.
- the feature i missed most was decent AOP support (rather than EJB3 Interceptors) ala what you get with Spring and the AspectJ pointcut language. Furthermore, there is no painless way to use the latter with EJB3, so that i ended up making do with interceptors.
- it was quite painful to work around gaps in JBoss' only partially compliant implementation of Java EE 5 (such as JSF 1.1 (instead of JSF 1.2) managed beans not being able to have session bean references injected; full JAX-WS 2.0 annotations not being available on session beans). That's a non-issue with a fully Java EE 5 compliant container (or the very latest JBoss versions) of course.
- better to not talk about testing EJB3 enterprise beans outside the container (although the idea of the JBoss microcontainer sounds good...)

regards,
gerald

www.gerald-loeffler.net

- better to not talk about testing EJB3 enterprise beans outside the container (although the idea of the JBoss microcontainer sounds good...)

This is my main beef against EJB3 : the spec doesn't state that the EJB container should be embeddable in the application (I think only JBoss offers this feature at the moment). This is one of the main selling point of Spring and I don't see what stop EJB vendors from doing it.

As far as I understand, there are only two things which EJB supports and Spring does not support:
- transaction propagation over multiple app servers,
- clustering with session replication.
If you have any (political or non-political) reasons you must adopt them above, the only choice would be EJB.

Otherwise, Spring is better. (If you work in Japan, Seasar - yet another famous DI container - is also an alternative.)

As far as I understand, there are only two things which EJB supports and Spring does not support:
- transaction propagation over multiple app servers,
- clustering with session replication.
If you have any (political or non-political) reasons you must adopt them above, the only choice would be EJB.

Otherwise, Spring is better. (If you work in Japan, Seasar - yet another famous DI container - is also an alternative.)

Steven,

Nice advice. Thank you.

Actually, starting from Weblogic 8 you can have transaction propagation between different servers with Spring, no EJB required.

Session replication ofcourse is something you can get with Terracotta, GigaSpaces, ...

- the single most severe restriction IMHO is that you can use DI only for JavaEE-supported resources (in contrast to the much more general Spring approach to DI). So all DAOs/Repositories need to be session beans; everything that calls an EJB must be an EJB (or JSF managed bean) itself (if you want to rely on JavaEE 5 DI). There is no indirection similar to Spring's proxy factory beans. In short, JavaEE 5 defines what can be injected and into which objects it can be injected.