Find JSRs
Submit this Search

Ad Banner

JSRs: Java Specification Requests
JSR 368: JavaTM Message Service 2.1

This JSR has been Withdrawn
Reason: Withdrawn at the request of the Spec Lead.

Updates to the Original JSR
The following updates have been made to the original proposal:

The schedule has been updated:
Q4 2015 Early Draft
Q1 2016 Public Review
Q3 2016 Proposed Final Draft
H1 2017 Final Release

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Oracle

Name of Contact Person: Nigel Deakin

E-Mail Address:

Telephone Number: +44 20 7562 6736

Fax Number: -

Specification Lead: Nigel Deakin, Oracle

E-Mail Address:

Telephone Number: +44 20 7562 6736

Fax Number: -

Initial Expert Group Membership:


Supporting this JSR:

Red Hat
London Java Community
Egypt Java Users' Group
Werner Keil
Antonio Goncalves
Josh Juneau
Nicholas Wright
Seunghoon Han, TmaxSoft

Section 2: Request

2.1 Please describe the proposed Specification:

The Java Message Service (JMS) API is a Java API for accessing enterprise messaging systems from Java programs in both Java EE and Java SE environments. It provides a common way for Java programs to create, send, receive and read an enterprise messaging system's messages.

The current version of this API is 2.0, which was developed as JSR 343 and which achieved final release in 2013.

The JMS 2.0 API may be implemented standalone for use in a Java SE environment. It is also a required service that must be available in a full Java EE 7 environment, in the EJB, web and application client containers. When used in a Java EE environment, certain parts of the JMS specification are overridden by parts of the Java EE, EJB and Servlet specifications, which define further how the JMS API should behave.

This JSR proposes that a new revision of the JMS specification be developed, JMS 2.1. The proposed content of JMS 2.1 is as follows:

  • The ease-of-use improvements started in JMS 2.0 will be completed in JMS 2.1 by simplifying and extending the API required to receive messages asynchronously, both in a Java SE environment and in Java EE.

    For Java EE applications an easier-to-use and more general alternative to JMS message-driven beans will be defined. The details of this feature will be determined by the expert group. The intention is to provide a simpler and more compact syntax than JMS MDBs, which will avoid the restrictions of the MDB lifecycle, and the JMS MessageListener interface, by allowing any CDI managed bean to be used to listen for messages. If possible, this feature will be aligned with CDI event observers.

  • The portability of JMS providers within Java EE servers will be improved by reviewing the two alternative APIs defined for this purpose and identifying improvements.

    There are currently two alternative APIs for integrating a JMS provider with a Java EE application server: the "application server facilities" API defined in JMS 2.0 chapter 13, and the resource adapter API defined in the Java Connector Architecture (JCA) specification. It is optional whether a JMS provider implement either of these APIs and as a result there are no CTS tests for either.

  • The optional "application server facilities" API defined in JMS 2.0 chapter 11 are not well defined and there is confusion about how they should be used. The following improvements are proposed:

    • Clarifying the relationship between the "XA" interfaces and their normal equivalents and when each should be used.

    • Defining of how asynchronous message delivery should be integrated with JTA (XA) transactions, especially where XA resource enlistment and delistment should take place. If necessary additional APIs will be defined to support this.

    • Defining a new API to allow JMS ConnectionFactory and Destination objects to be created.

  • JMS 2.0 was the first version of JMS that recommended that JMS providers implement a JCA resource adapter. A new chapter, 13, was added which defined a number of recommended MDB activation properties. The JSR 343 expert group discussed whether to make it mandatory for JMS providers to implement a resource adapter and decided that this was too onerous a requirement and that it should remain optional.

    There is further scope to improve this part of the specification, especially in areas other than activation properties, and to formally define compliance tests that vendors can use to determine whether their implementation conforms to this optional part of the specification.

  • JMS 2.0 included a number of changes to define how a JMS provider must behave when used in a Java EE transaction. However a number of improvements are still needed and will be addressed in JMS 2.1. These include:

    • Defining the behaviour of a JMS session that is created outside a JTA transaction but used to send or receive a message within a JTA transaction, and vice versa.

    • Defining an API to allow a JMS connection factory, connection or session to opt-out of a JTA transaction

    • Clarifying the existing restrictions on using client-acknowledgement and local transactions in a Java EE environment and removing these restrictions where possible.

  • Providing features to allow applications to control the redelivery behaviour when a MDB or MessageListener throws an exception. These may include redelivery delay, redelivery limits and dead message queues. In addition there may be a need for a standard way for a non-transactional MDB to be able to force a redelivery.

  • The new revision will contain a number of corrections and minor enhancements to features added in JMS 2.0, based on feedback from developers who have implemented JMS 2.0.

    These include adding new APIs to allow application servers or resource adapters to implement JMSContext without needing an additional connection pool, and adding new APIs to allow multiple XAJMSContext objects to share the same underlying connection.

  • Some minor changes may be added to make use of new features of Java SE 8.

    The existing resource definition annotations will be extended to support repeatable annotations.

    Existing methods that use callbacks to support asynchronous operations will be reviewed to determine whether there is scope to make use of the new CompleteableFuture class in Java SE 8 and related API.

  • Other features and changes will be included as requested by the community and as decided by the Expert Group. The JMS specification wiki already contains approximately 80 proposals that will be considered in detail and prioritised by the expert group. Additional proposals will be invited as well.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

The target platforms are Java EE and Java SE.

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

The Java Message Service (JMS) API is designed for both Java EE and Java SE platform environments.

It is intended that JMS 2.1 will be included as a required part of the Java Platform, Enterprise Edition version 8.

Aligning the timeline of this JSR with that of Java EE 8 may therefore impact the scope of the JMS 2.1 release.

2.4 What need of the Java community will be addressed by the proposed specification?

See 2.1 above.

2.5 Why isn't this need met by existing specifications?

See 2.1 above.

2.6 Please give a short description of the underlying technology or technologies:

See 2.1 above.

2.7 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

The API Specification will continue to use the javax.jms package.

2.8 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?


2.9 Are there any security issues that cannot be addressed by the current security model?


2.10 Are there any internationalization or localization issues?


2.11 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

This JSR is proposing to define new API for receiving messages asynchronously.

The EJB specification currently defines a way to do this using message-driven beans (MDBs).

The use of MDBs to receive JMS messages may become partially or wholly obsolete as a result of this work.

The use of MDBs to receive non-JMS messages is outside the scope of the JMS specification and will neither change nor become obsolete.

It is not expected that major changes will be needed to the EJB specification, but small changes are likely since the two specifications are so closely-related.

It is intended that it will be possible for application servers to implement the proposed new API for receiving messages asynchronously by using a JCA resource adapter. However it is possible that changes may be required to the Java Connector Architecture (JCA) specification to support this.

2.12 Please describe the anticipated schedule for the development of this specification.

Q3 2014 Expert Group formed
Q1 2015 Early Draft
Q3 2015 Public Review
Q4 2015 Proposed Final Draft
Q3 2016 Final Release

2.13 Please describe the anticipated working model for the Expert Group working on developing this specification.

The primary means of communication will be email, with conference calls and face-to-face meetings scheduled as needed.

2.14 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate:

The project site will be used to track all issues and disseminate information on the progress of the JSR.

Q. Is the schedule for the JSR publicly available, current, and updated regularly?

A. The schedule will be available on the project site

Q. Can the public read and/or write to a wiki for the JSR?

A. The project site includes a wiki which may be read by anyone. Only expert group members will be able to update the wiki.

Q. Is there a publicly accessible discussion board for the JSR that you read and respond to regularly?

A. The existing email alias will be used for this purpose. Anyone may subscribe to and post to this alias, and an online archive of past messages will be available on the project website.

Q. Have you spoken at conferences and events about the JSR recently?

In the past year I gave two presentations at JavaOne 2013 in San Francisco. One was a summary of the new features of JMS 2.0, and the other was a consultation session to discuss what might be in JMS 2.1. I have submitted proposals for two similar talks at JavaOne 2014.

Q. Are you using open-source processes for the development of the RI and/or the TCK?

A. The RI for JMS 2.0 is Open Message Queue. It is part of GlassFish Server, Open Source Edition. Both are open source. It is expected that the RI for JMS 2.1 will continue in the same vein. The TCK for JMS is not open source.

Q. What are the Terms of Use required to use the collaboration tools you have prepared to use with the Expert Group, so that prospective EG members can judge whether they are compatible with the JSPA?

A. The collaboration tools use terms of service. These are available at

Q. What is the location of your publicly-accessible Issue list? In order to enable EC members to judge whether Issues have been adequately addressed, the list must make a clear distinction between Issues that are still open, Issues that have been deferred, and those that are closed, and must indicate the reason for any change of state.

A. The issue list is available to anyone at This uses JIRA. Each issue has a status field which reflects its status.

Issues that have been incorporated into a release of the specification are closed, and the "fix version" shows which release of the spec incorporates the change.

Issues which are rejected as invalid, incomplete or inappropriate and which will not be reconsidered are marked as closed, with an appropriate comment to explain why the issue was closed.

All new issues, and any older issues which have been deferred for future consideration, are left open and are listed on the JMS 2.1 planning page

Each issue on that page is given a JIRA tag to classify whether the issue is major or minor, whether it was deferred, and so on. That page lists the possible tags that are used.

Q. What is the mechanism for the public to provide feedback on your JSR?

A. The jms-spec project front page explains the various ways in which feedback may be provided. This invites members of the community to log an issue in the issue tracker or send an email to the community email alias. Once work on the JSR begins this will be updated and given greater prominence on the site.

Q. Where is the publicly-accessible document archive for your Expert Group?

A. The document archive is at

The API interfaces and specification itself (including work-in-progress drafts) are stored in a publicly-available svn repository. Access details are at and the contents of the repository may be browsed at

Q. Does the Community tab for my JSR have links to and information about all public communication mechanisms and sites for the development of my JSR?

A. The community tab for JSR 343 ( directs readers to the project website When this new JSR is approved, its community tab will be similarly updated.

Q. Do you have a Twitter account or other social networking feed which people can follow for updates on your JSR?

A. No, though I will consider creating a Twitter account specifically for this JSR for JMS 2.1.

Q. Which specific areas of feedback should interested community members (such as the Adopt-a-JSR program) provide to improve the JSR

A. The formation of Adopt-a-JSR groups for JMS 2.1 will be encouraged and supported. The London Java Community expressed interest in participating in the Adopt-a-JSR programme for JSR 343 though little support was provided by the expert group. It is intended that the formation of this and other Adopt-a-JSR programmes for the new JSR will be encouraged and supported rather more.

2.15 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

Oracle Corporation will deliver a Reference Implementation (RI) and Technology Compatibility Kit (TCK) available both stand-alone and as part of Java EE 8.

2.16 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

No change is proposed from what was delivered for previous versions of JMS.

2.17 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

Specification license

RI license

  1. Commercial use

    The RI will be available for commercial use under the CDDL 1.1 open source license, the GPLv2 with Classpath Exception open source license, or this RI license.

  2. Non-Commercial use

    The RI will be available for non-Commercial use under the CDDL 1.1 open source license or the GPLv2 with Classpath Exception open source license.

TCK license

  1. Commercial use

    The TCK will be available for commercial use under this TCK license.

  2. Non-Commercial use

    As required by the Java Specification Participation Agreement (JSPA), the TCK will be licensed at no charge without support to qualified not-for-profit. The Compatibility Testing Scholarship Program will verify such qualification. Support may also be provided at no charge with approval of the scholarship board. For more information, please refer to:

2.18 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.

The Expert Group will conduct business using a publicly readable email alias for the JSR, similar to the email alias which was used for JSR 343. All messages sent to this alias by expert group members will be forwarded to the JMS specification community email alias. An online archive of messages will be available.

The existing JMS specification community alias, will continue to be used to allow members of the community to receive copies of all emails sent to the expert group alias, as well as to provide feedback and allow discussion on any issue related to the JMS specification. An online archive of messages will be available.

There will also be a publicly accessible issue tracker, source repository (used for draft API classes and the draft specification itself) and a document archive (used for discussion documents). See also 2.19 and 2.20 below.

2.19 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?

Instructions on how members of the community may log issues are given at

2.20 Please provide the location of the publicly accessible document archive you have created for the Expert Group.

The document archive is at

In addition, draft API classes and the draft specification itself will be available in a svn repository. Access details at

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

The JSR that developed JMS 2.0 was JSR 343. The formal JSR page is

The final specification for JMS 2.0 is available at

The API docs for JMS 2.0 is available at

The standalone JMS RI is Open Message Queue:

The Java EE 7 RI, which include Open Message Queue and some additional JMS components to provide support for JMS 2.0 in a Java EE environment, is GlassFish Server Open Source Edition. This is available at

3.2 Explanation of how these items might be used as a starting point for the work.

This new JSR will develop the specification for JMS 2.1 as as a revision of the existing JMS 2.0 specification and API.

The standalone RI for JMS 2.1 will be developed as a revision of the existing RI for JMS 2.0, Open Message Queue.

The Java EE 8 RI will similarly be developed as a revision of the existing Java EE 7 RI, GlassFish Server, Open Source Edition.

This will include Open Message Queue as well as some updated components to provide support for JMS 2.1 in a Java EE environment.