Updates from the Java EE and Spring Framework Panel Discussion at JavaOne. Panelist: 1) Richard Hightower – Developer, InfoQ 2) Bert Ertman – Fellow, Luminis 3)Gordon Dickens – Technical Architect, IT101, Inc. 4)Chris Beams – Senior Technical Staff, VMware 5) Arun Gupta – Technology Evangelist, Oracle . The bulk of audience are enterprise developers. Show of hands suggests that most are using JavaEE and Spring.
Chris Beams: Gives a quick overview of Spring and it’s support across vendors and technologies. Talks briefly of the Spring Architecture and various technologies.
Arun Gupta: Would like to highlight the light weight nature of JavaEE today. JavaEE is a standard. So there are pros & cons.It moves slower as it doesn’t want to disrupt innovation. Key point is JavaEE is a simple lightweight elegant solution. It is not exclusive but embracing of other technologies.
Bert Ertman: Both JavaEE and Spring are pretty much on par. Ideally you should pick a standard and add on anything extra you require.
Gordon Dickens: I typically go with Spring as I get an application rapidly off the ground and it gives me a many options. Spring builds over JavaEE.
Arun Gupta: I was most impressed with the RAD capability of Ruby On Rails and that’s the kind of RAD capability we have in JavaEE 6 today. In many cases, you an just drop jars and the server will figure things out. Spring innovates fast and I would encourage Spring to contribute back to the JCP, to the standard body.
Chris Beams: We were all inspired by Ruby on Rails. JavaEE is still not at in the same class of RAD as Rails. Spring Roo provides Rails like productivity. Grails is that kind of a RAD. Standards bodies move slowly. We like the way JavaEE 6 shaped up. JavaEE 6 now does provide a great POJO programming model. Spring came out in in 2004. It was 2011 by the time we got the major JavaEE servers on JavaEE 6. SpringSource does provide single source vendor support if you are running on Tomcat. Redeploys take a long time on Weblogic & Websphere.
Arun Gupta: JBoss Forge & Arquillian from RedHat is a great example of innovation in the JavaEE community. Standardization is important but innovation does continue even within that framework.
Chris Beams: JavaEE Strengths: Is a standard. Is getting better. In some cases just JavaEE might suffice but these are applications from a few years back, not using newer technologies like NoSQL.
Arun Gupta: Completing or Complimentary? – Spring (Web Application) requires JavaEE to run. CDI provides full dependency injection in JavaEE. Use the runtime first. If it’s not provided in the JavaEE runtime, then reach out and use third party libraries. Spring & JavaEE compete & complimentary. We have a love – hate relationship.
Bert Ertman: Why doesn’t VMWare work on standards, sit with other vendors and spend it’s $$ to get us all better tech. Why are they choosing to go their own way when there’s so much common ground?
Chris Beams: Q) Why doesn’t Spring not become a JavaEE vendor? Answer: We have conflicting solutions that were around many years before CDI. We do not see community demand for this. We have people working on JSRs. JSR 352. We are all for working with JavaEE where it makes sense, where we think it’s ready & suited to standardization.
Audience Q: Why didn’t Spring participate more in CDI spec JSR 299?
Chris: Yes, we could have done more. There are politics involved. I dont know why we didn’t do more. The different dependency injection (DI) frameworks (Spring, Guice…) had pretty different approaches to DI.
Sessions Abstract : In the age of Java EE 6 and Spring 3, enterprise Java developers have many architectural choices, including Java EE 6 and Spring, but which one is right for your project? Many of us have heard the debate and seen the flame wars—it’s a topic with passionate community members, and it’s a vibrant debate. If you are looking for some level-headed discussion, grounded in real experience, by developers who have tried both, then come join this discussion. InfoQ’s Java editors moderate the discussion, and they are joined by independent consultants and representatives from both Java EE and VMWare/SpringSource.