Now that Java EE 6 is here…do I still need those proprietary frameworks?

Last week a JBoss core developer, Lincoln Baxter, published a detailed and insightful report on his migration experience from the Spring Framework to the new Java EE 6 platform. In the post Lincoln explains in great detail how he set out to port applications to the new Java EE 6 architecture. As you may guess, the post prompted many comments and diverse viewpoints from across the community.

Perspective

It’s no secret that the Spring Framework cropped up as a lightweight alternative and abstraction to programming for Java EE because the perception was that Java EE had become cumbersome and overly complex. Developers wanted a lightweight framework that dealt with the limited and closed injectable resources in Java EE 5. Spring sought to satisfy this need with a simple framework that made configuring and integrating applications a lot easier, generating a lot of interest in the process.

Debate and Change

There has been a healthy amount of debate on the merits of Spring and alternatives in Java EE. Much of this discussion has been very constructive and led to calls for enhancements in the Java platform. Even at the most recent JavaOne, a panel discussion seemed to get pretty heated, while discussing this very topic. Through all of the back-and-forth, it seems to come down to a developer’s preference. Should developers adopt a proprietary framework or stick with standards based platform? Or dabble with both?

Although change hasn’t come as fast (does it ever?) as everybody would like, Java EE 6 has come to light with many improvements. The inclusion of JSR 299, Context and Dependency Injection (CDI) contributes to making Java EE 6 compelling and different today. JSR 299 reduces the complexity of Java and in many cases can make using Java EE 6 simpler and less time consuming than using proprietary frameworks. The specification led by Red Hat and Gavin King, on the core JBoss development team has helped make Java EE easier to use and extend in a standard way. This is just one example of the innovation coming from the JBoss Community from projects such as Seam, Hibernate, Drools and many others.

Open Choice

The JBoss and Red Hat philosophy is about choice – the freedom to choose the right development and deployment paradigm that our users are most comfortable with, and the belief that openness in development and community participation will produce greater innovation for yet more choice. Additionally, Red Hat is committed to standards, ensuring that our customers can avoid vendor lock-in.

While it is true that Java EE 6 and frameworks such as Spring are differing approaches to application development, JBoss is open to respecting and supporting the choice of development framework and language without compromising performance and agility.

Through the JBoss Open Choice strategy, Red Hat works to accommodate modern and legacy web applications. Whether developers are using Google Web Toolkit (GWT), Apache Struts™, RichFaces or JBoss Seam, or even proprietary frameworks such as Spring. Red Hat’s approach focuses on supporting those applications deployed on JBoss Enterprise Application Platform. Bottom line: whether a developer uses Spring Framework or Java EE 6 or a new framework, we work to have our customers covered.

To demonstrate the ease of use that CDI brings to Java EE 6, I am hosting a webinar entitled Java EE 6 and CDI – Moving away from the clutter of Spring and other frameworks. The featured speaker is Dan Allen who is a core member of the JBoss Seam team and an expert on dependency injection and all manner of Java technologies.

We hope that you will join us as we explore these advancements to Java EE on Thursday, October 14, 2010 at 12 noon EST. Please go to this link or www.jboss.com to register.