Java EE 5 vs Java EE 6


This post visualizes changes between Java EE Standards 5 and 6. The comparison of standards is listed in four sections Web-Services, Web-Container, Enterprise Application technologies and Maintenance. Hope this helps someone.

Web Service related changes

JAVA EE 5 (JSR-244) JAVA EE 6 (JSR-316)
JAX-RPC 1.1 JSR 101 JAX-RPC 1.1
Enterprise Web Services 1.2 JSR 109 Enterprise Web Services 1.3 (new version)
Web Service Metadata 1.0 JSR 181 Web Service Metadata 1.0
Streaming API for XML 1.0 JSR 173 Streaming API for XML 1.0
JAX-WS 2.0  JSR 224 JAX-WS 2.2 (new version)
JAXB 2.0 JSR 222 JAXB 2.2 (new version)
SOAP with Attachments API for Java (SAAJ)JSR 67 Java APIs for XML Messaging 1.3 (new version)spec
new! JAX-RS 1.1 JSR 311
new! Java API for XML Registries (JAXR 1.0)JSR 93

The new redesigned Java API for XML Web Services (JAX-WS) is the base or a middle part of a newly Java EE 6 Web service stack.  The new stack  includes JAX-WS 2.0, JAXB 2.0, and SAAJ 1.3. and is also called “integrated stack”.  JAX-WS was designed to take place of JAX-RPC. Due this also JSR-109 was updated because it describes run time architecture of JEE Web Services Stack. JAXB which provides an easy way to bind an XML schema to java and vice verse, was updated to.

The SOAP with Attachments API for Java (SAAJ) (also known as Java APIs for XML Messaging (JAXM)) provides a standard way to send XML documents over the Internet from the Java platform and was updated slightly containing now other consolidated standard.

New are JAX-RS, which provides support for RESTful Web services and JAXR which enables pull-parsing API for reading and writing XML documents. Also available in Java SE.

Web Applications related changes

JAVA EE 5 JAVA EE 6
JSTL JSR 52 JSTL
JavaServer Faces 1.2 JSR 252 JavaServer Faces 2.0 (new version)
JavaServer Pages 2.1 JSR 245 JavaServer Pages 2.2 /EL 2.2 (new version)
Java Servlet 2.5 JSR 154 Java Servlet 3.0 JSR 315 (new version)
new! Debugging Support for Other Languages 1.0 JSR 45

In Java EE 6 we have updates of all technologies of the Web Container except JSTL. So e.g. Servlet 3.0 improves Servlet concept in pluggability and some ease of development. It’s also introduces Async Servlet, and long waited File Uploading!. Also now configuration can be done by annotations.

New a specification of Debugging Support for Other Languages 1.0
This describes standardized tools for correlating Java virtual machine byte code to source code of languages other than the Java programming language, so it would guarantee debugging possibility of everything what runs is JSR-45 certified container.

Enterprise Technologies changes

JAVA EE 5 JAVA EE 6
Common Annotations JSR 250 Common Annotations
JCA 1.5 JSR 112 JCA 1.6 JSR 322 (new version)
JavaMail 1.4 JavaMail 1.4
JMS 1.1 JSR 914 JMS 1.1
JTA 1.1 JSR 907 JTA 1.1
Enterprise JavaBeans 3.0 JSR 220 Enterprise JavaBeans 3.1 JSR 318
(new version)
JPA 1.0 JSR 220 (together with EJB 3.0) JPA 2.0 JSR 317 (new version)
new! Contexts and Dependency Injection for Java (Web Beans 1.0) JSR 299
new! Dependency Injection for Java 1.0 JSR 330
new! Bean Validation 1.0 JSR 303
new! Managed Beans 1.0 JSR-316

In Enterprise Application section we see some important changes and new specifications. Most famous and important is  JSR-299 Context and Dependency Injection (CDI) which is there to unify the JavaServer Faces-managed bean component model with the Enterprise JavaBeans component model to simplify the programming model and architecture of web-based applications. Look an Weld Framework as reference implementation to this.

The similar sounding Standard Dependency Injection for Java JSR-330 just define a standard and common known DI like in spring and other frameworks. Look at popular Guice DI-Framework from Google which implements JSR-330.

Bean Validation  introduces a very cool annotation based and architecture layer independent Java Bean validation.

There are also some interesting improvements in EJBs. Singleton is a new type and can be only one per container, it is also possible to use @Local Beans (Same VM) without interface. Also JPA 2.0 has advanced query possibilities and validation.

Management Technologies

JAVA EE 5 JAVA EE 6
J2EE Application Deployment 1.2 JSR 88 J2EE Application Deployment 1.2
JavaBeans Activation Framework (JAF) 1.1 JSR 925 JavaBeans Activation Framework (JAF) 1.1
J2EE Management 1.0  JSR 77 J2EE Management 1.1 (new version)
Java Authorization Contract for Containers 1.1 JSR 115 Java Authorization Contract for Containers 1.3(new version)
new! Java Authentication Service Provider Interface for Containers JSR 196
new! [JavaSE] JAXP 1.3 JSR 206
new! [JavaSE] JDBC 4.0 JSR 221
new! [JavaSE] JMX 2.0 JSR 255

Nothing special to mention here.

Difference between Struts and JSF


Struts is an Action framework and JSF is component framework.
Action Framework: Struts (both 1 and 2) are action frameworks. In essence they give you the ability to map URLs to activities and code on the back end. Here, the layout and workflow tends to be more page oriented. As a developer you tend to interact with the HTTP request cycle directly, though Struts 2 helps isolate at least the binding of the request data to the action implementation classes.
Action framework coders can have more control of the structure and presentation of URLs, since their systems are more intimately tied to them compared to a component framework.
Component Framework: In a component framework, artifacts that are rendered on the page are initially developed as individual components, much like in modern GUI “fat client” libraries. You have components, they have events, and your code is written to work with those events against the components. Most of the time, in mainstream development, your code is pretty much ignorant of the HTTP request cycle and processing.
JSF eliminated the need of Form Bean and DTO classes as it allows the use of same pojo class on all tiers of the application because of the Backing Bean.
In struts framework we can access the request and response objects directly, as in case of JSF we can access request and response objects indirectly.
Struts has a more sophisticated controller architecture than does JavaServer Faces technology. Struts is more sophisticated partly because the application developer can access the controller by creating an Action object that can integrate with the controller, whereas JavaServer Faces technology does not allow access to the controller.
In addition, the Struts controller can do things like access control on each Action based on user roles. This functionality is not provided by JavaServer Faces technology.
Struts frameworks is  better for “web sites”, site like this one, sites that focus on delivering content to the user. Where it’s mostly a “read only” experience for the end user who is likely to want to bookmark things, come back to arbitrarily deep pages, etc.
JSF framework is better for CRUD screens, back office applications, lots of forms and controls, etc. Here, the workflow is more controlled. You tend to not get to a “detail” screen with going through the “list” screen or “header” screen first, for example.
struts validate full beans (validator.xml) jsf has a pluggable validator-mechanism