Spring and Java EE 6

Recorded at:

I mean, sure, you can (and should be) skeptical and critical about stuff that isn't finalized yet and I do get they have commercial agendas but still. There were two types of sentences

"Nervous laughter sentences" (EE 6 will be late and still suck) - 80%

"Enthusiastic giggle sentences" (how Spring works around the problem) - 20%

I think even a person who didn't speak English could have sorted those out ;-)

But well, the topic was Spring and EE 6 so I guess he did cover it from their point of view

While I do see an unmistakable marketing/self-promotion aspect to this talk, it is refreshing in some ways if you ignore some of the body language (which is subjective) - it looks at the competition between Java EE and Spring as something good for the community, it acknowledges that both camps influence each other in positive ways and that there is indeed a gradual convergence...

Cheers,
Reza
----------------------------------
Independent Consultant
Expert Group Member, EJB 3.1 and Java EE 6
Author EJB 3 in Action
Resin EJB 3.1 Lite Container Contributor

I'm a Seam developer for over 2 years now but I try to stay as objective and unbiased as possible. The only JSR that he seemed very enthusiastic about was Bean Validations and possibly JSF 2 but did not seem very enthusiastic about the clashing of responsibilities in the EGs for EJB 3.1 and JSR299 and the fact that 299 is constantly changing. If you think about it, do we really need possibly (or partially?) two component models in EE 6 (EJB 3.1 and 299)? I think that 299 (or JCDI) can be used in a SE or EE environment, which is what makes it all-encompassing and difficult to design/plan/deal with. It's analogous to a brake system that may be configured to be used in different types of vehicles (i.e. not just cars).



It seems very obvious that EE 6 and Spring 3 are basically converging in terms of functionalities and design and the advantage that the Spring stack has over the EE 6 stack is that most likely the Spring core design/dev team is not as disparate and possibly isolated as the EGs for EE 6.



EE 5/6 seems like a hydra whereas Spring is very well orchestrated in terms of planning and organization. At least that's what I have observed from a high level. If EE 5 was better planned and orchestrated *amongst* the EGs, then maybe there would have been no need for Seam in the first place.



In any event, I am looking forward to the RI for EE 6 in 2010 or whenever it may be released (and yes, I know Glassfish V3 is a preview of EE 6 but does it include 299)?



An interesting point he made was the fact that the JSF RI libraries are embedded in the EE 5/6 app server (I know JBoss is like that anyways) so how does one go about upgrading basically a single module like JSF 1.2 to JSF 2.0 libraries without upgrading/replacing the entire app server with the newer version? Modularization is critical and I think JBoss 5 has implemented and/or adopted some OSGi ideas in their design/implementation but I'm not familiar enough to comment on that.



Anyways, thanks to JHoller for his perspectives and feedback, it was all pretty interesting.

I haven't managed to listen to presentation (shame there is no transcript) yet. Arbi - GlassFish V3 final release is the Java EE 6 reference implementation. GlassFish V3 today includes CDI, and we are finalizing the integration at the moment.

I think there is a lot of FUD around how the JCP works. As someone working inside the JCP, I see a far greater sense of common goals and camaraderie there than I see on projects on my consulting assignments. As to Spring developers, I find the homogeneity of thought quite disturbing and unnatural, even somewhat Orwellian. I see the managed bean/CDI spec as very reasonable and a naturally complementary JSR to EJB 3.1. Moreover, unlike what the presentation claims, there is no particularly fractious disagreements in any of the JSRs beyond healthy debate about complex issues. There is certainly no great rift between the JSR 299 and EJB 3.1 EGs.