[REF] Java EE Version History

simply copied from :

http://en.wikipedia.org/wiki/Java_EE_version_history

 

Java EE version history

From Wikipedia, the free encyclopedia

Jump to:  navigation,  search

The Java Platform, Enterprise Edition or Java EE (formerly known as Java 2 Platform, Enterprise Edition or J2EE) has undergone several changes since 1.0 as well as numerous additions of new specifications.

[edit] JPE (May 1998)

Announcement of the JPE (Java Professional Edition) project at Sun.

[edit] J2EE 1.2 (December 12, 1999)

List of J2EE 1.2 specifications  download page.

Technology	Version
JDBC Standard Extension API	2.0
Java Naming and Directory Interface Specification (JNDI)	1.2
RMI-IIOP	1.0
Java Servlet	2.2
JavaServer Pages (JSP)	1.1
Enterprise JavaBeans (EJB)	1.1
Java Message Service API (JMS)	1.0
Java Transaction API (JTA)	1.0
JavaMail API	1.1
JavaBeans Activation Framework (JAF)	1.0

[edit] J2EE 1.3 (September 24, 2001)

List of J2EE 1.3 specifications developed under  JSR 58

Technology	Version
JDBC Extension	2.0
Java API for XML Processing (JAXP)	1.1
Java Servlet	2.3
JavaServer Pages (JSP)	1.2
Enterprise JavaBeans EJB)	2.0
J2EE Connector Architecture	1.0
Java Message Service API (JMS)	1.0
Java Transaction API (JTA)	1.0
JavaMail API	1.2
JavaBeans Activation Framework (JAF)	1.0
Java Authentication and Authorization Service (JAAS)	1.0

[edit] J2EE 1.4 (November 11, 2003)

List of J2EE 1.4 specifications developed under  JSR 151

Technology	Version
Web Services Technologies:
Web Services for J2EE 1.1	1.0
Java API for XML Processing (JAXP)	1.2
Java API for XML-based RPC (JAX-RPC)	1.1
Java API for XML Registries (JAXR)	1.0
Web Application Technologies:
Java Servlet	2.4
JavaServer Pages (JSP)	2.0
Enterprise Application Technologies:
Enterprise JavaBeans (EJB)	2.1
J2EE Connector Architecture	1.5
Java Message Service API (JMS)	1.1
Java Transaction API (JTA)	1.0
JavaMail API	1.3
JavaBeans Activation Framework (JAF)	1.0
Management and Security Technologies:
Java Authorization Service Provider Contract for Containers (JACC)	1.0
Java Management Extensions (JMX)	1.2
Enterprise Edition Management API	1.0
Enterprise Edition Deployment API	1.1

[edit] Java EE 5 (May 11, 2006)

List of JEE 5 specifications developed under  JSR244

Technology	Version	JSR
Web Services Technologies:
Web Services	1.2	JSR109
Java API for XML-Based Web Services (JAX-WS)	2.0	JSR224
Java Architecture for XML Binding (JAXB)	2.0	JSR222
Web Service Metadata for the Java Platform	2.0	JSR181
Java API for XML-Based RPC (JAX-RPC)	1.1	JSR101
Java API for XML Registries (JAXR)	1.0	JSR93
SOAP with Attachments API for Java (SAAJ)	1.3	JSR67
Streaming API for XML (StAX)	1.0	JSR173
Web Application Technologies:
Java Servlet	2.5	JSR154
JavaServer Faces (JSF)	1.2	JSR252
JavaServer Pages (JSP)	2.1	JSR245
JavaServer Pages Standard Tag Library (JSTL)	1.2	JSR52
Debugging Support for Other Languages	1.0	JSR45
Enterprise Application Technologies:
Enterprise JavaBeans (EJB)	3.0	JSR220
Java Persistence API (JPA)	1.0	JSR220
Jave EE Connector Architecture	1.5	JSR112
Common Annotations for the Java Platform	1.0	JSR250
Java Message Service API (JMS)	1.1	JSR914
Java Transaction API (JTA)	1.1	JSR907
JavaMail API	1.4	JSR919
JavaBeans Activation Framework (JAF)	1.1	JSR925
Management and Security Technologies:
Java Authorization Service Provider Contract for Containers (JACC)	1.1	JSR115
J2EE Application Deployment	1.2	JSR88
J2EE Management	1.1	JSR77

[edit] 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 funtionality (Servlet), business logic (Enterprise JavaBeans Lite), transactions (Java Transaction API), persistence (Java Persistence API) and more.

List of JEE 6 specifications developed under  JSR 316

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
JavaServer Faces (JSF)	2.0	JSR314
JavaServer Pages (JSP)	2.2	JSR245
Expression Language (EL)	2.2	JSR245
JavaServer Pages Standard Tag Library (JSTL)	1.2	JSR52
Debugging Support for Other Languages	1.0	JSR45
Enterprise Application Technologies:
Enterprise JavaBeans (EJB)	3.1	JSR318	Lite
Java Persistence API (JPA)	2.0	JSR317
Contexts and Dependency Injection for Java	1.0	JSR299
Dependency Injection for Java	1.0	JSR330
Bean Validation	1.0	JSR303
Managed Beans	1.0	JSR316
Interceptors	1.1	JSR318
Java EE Connector Architecture	1.6	JSR322
Common Annotations for the Java Platform	1.1	JSR250
Java Message Service API (JMS)	1.1	JSR914
Java Transaction API (JTA)	1.1	JSR907
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.^[1]

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^[2] 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 ^[2]

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”.