Java EE 6 (Dec 10, 2009)
Java EE 6 introduced the concept of profile, which represents a configuration of the platform suited to a particular class of applications. The Web Profile offers a complete stack, with technologies addressing presentation and state management (JavaServer Faces, JavaServer Pages), core web container functionality (Servlet), business logic (Enterprise JavaBeans Lite), transactions (Java Transaction API), persistence (Java Persistence API) and more.
| Technology | Version | JSR | Included in Web Profile |
|---|---|---|---|
| Web Services Technologies: | |||
| Java API for RESTful Web Services (JAX-RS) | 1.1 | JSR311 | |
| Web Services | 1.3 | JSR109 | |
| Java API for XML-Based Web Services (JAX-WS) | 2.2 | JSR224 | |
| Java Architecture for XML Binding (JAXB) | 2.2 | JSR222 | |
| Web Services Metadata for the Java Platform | 2.1 | JSR181 | |
| Java API for XML-based RPC (JAX-RPC) | 1.1 | JSR101 | |
| Java APIs for XML Messaging (JAXM) | 1.3 | JSR67 | |
| Java API for XML Registries (JAXR) | 1.0 | JSR93 | |
| Web Application Technologies: | |||
| Java Servlet | 3.0 | JSR315 | Y |
| JavaServer Faces (JSF) | 2.0 | JSR314 | Y |
| JavaServer Pages (JSP) | 2.2 | JSR245 | Y |
| Expression Language (EL) | 2.2 | JSR245 | Y |
| JavaServer Pages Standard Tag Library (JSTL) | 1.2 | JSR52 | Y |
| Debugging Support for Other Languages | 1.0 | JSR45 | Y |
| Enterprise Application Technologies: | |||
| Enterprise JavaBeans (EJB) | 3.1 | JSR318 | Y Lite |
| Java Persistence API (JPA) | 2.0 | JSR317 | Y |
| Contexts and Dependency Injection for Java | 1.0 | JSR299 | Y |
| Dependency Injection for Java | 1.0 | JSR330 | Y |
| Bean Validation | 1.0 | JSR303 | Y |
| Managed Beans | 1.0 | JSR316 | Y |
| Interceptors | 1.1 | JSR318 | Y |
| Java EE Connector Architecture | 1.6 | JSR322 | |
| Common Annotations for the Java Platform | 1.1 | JSR250 | Y |
| Java Message Service API (JMS) | 1.1 | JSR914 | |
| Java Transaction API (JTA) | 1.1 | JSR907 | Y |
| JavaMail API | 1.4 | JSR919 | |
| Management and Security Technologies: | |||
| Java Authentication Service Provider Interface for Containers (JASPIC) | 1.0 | JSR196 | |
| Java Authorization Service Provider Contract for Containers (JACC) | 1.4 | JSR115 | |
| Java EE Application Deployment | 1.2 | JSR88 | |
| J2EE Management | 1.1 | JSR77 | |
Java EE 6 was first going to be developed under JSR 313 but was canceled. Java EE 6 was developed under JSR 316 and released on December 10, 2009.
The development was plagued with controversy, although passed by 14 yes votes, 1 no vote (Apache), and 1 abstention (Borland), members aired concerns relating to the licensing terms applied by Sun Microsystems.
IBM's "yes" vote was caveated with:
- IBM’s vote is based on the technical merits of this JSR and is not a vote on the licensing terms. IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage. We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM’s preferred licensing model.
Intel's was caveated with:
- The Spec Lead has told us there are no “field of use restrictions” on implementations for this particular JSR. The Apache open letter about Java SE claimed that a confidential license for a required JCP test suite restricts how Independent Implementations of that JCP spec can be used. Licenses to test for JCP compatibility must not be used to limit or restrict competing, compatible implementations; licenses containing such limitations do not meet the requirements of the JSPA, the agreement under which the JCP operates. For every JCP ballot, we will ask the Spec Lead whether such restrictions exist in their license.
Red Hat commented
- The spec lead of the EE6 specification has confirmed that the EE6 TCK would contain no “field of use restrictions”, as originally raised by Apache with regard to another JSR (i.e. the SE TCK licensing). That is a good thing.
- However, in the absence of an explicit JSPA rule that would forbid such field-of-use restrictions, we will remain worried that a similar issue might resurface anytime, for any JSR.
- Consequently, in the future, for any submitted JSR (by SUNW or not), we will specifically expect the spec lead to provide clear information on that aspect and take the answer in account when casting our vote.
Apache voted NO with the following comment:
- The Apache Software Foundation’s vote is based on the point of view that this spec lead - Sun - is in violation of the JSPA
- and therefore shouldn’t be allowed to start another JSR until the above matter is resolved.
- This vote is not a comment on the technical merits of the JSR. If not for the issue of the spec lead, the ASF would have otherwise voted “yes”.
Read more about this topic: Java EE Version History