IBM MQ classes for Jakarta Messaging: an overview

IBM® MQ 9.3.0 introduces support for Jakarta Messaging. For Jakarta Messaging 3.0, control of the JMS specification moved from Oracle to the Java Community Process. However, Oracle retains control of the "javax" name, which is used in other Java technologies. So although Jakarta Messaging 3.0 is functionally equivalent to JMS 2.0, there are some differences in naming. The official name for version 3.0 is Jakarta Messaging rather than Java Message Service, and the package and constant names are prefixed with jakarta rather than javax.

Background

For many years, the Java platform has come in two forms – Standard Edition and Enterprise Edition.

Java Platform, Standard Edition (sometimes abbreviated as Java SE) is the core language and class libraries, capable of being run in a stand-alone context. Most Java packages in Java SE have names starting with "java.".

Java Platform, Enterprise Edition (Java EE) extends this, adding functionality like Messaging, various Beans, transactionality and so on. Some of these technologies can also be used in a Java SE context. Most Java packages in Java EE historically have names starting with "javax." – there is some crossover, however, so some Java SE packages have "javax." as the prefix to their name.

The Java Message Service (JMS) is part of Java Platform, Enterprise Edition. Java EE 7 incorporates JMS 2.0.

Up to Java EE 7, the technologies were under the stewardship of Oracle.

The Java EE technologies have recently moved from the stewardship of Oracle to a community process overseen by the Eclipse Foundation.

As the "javax." name could not be moved to the new project, new naming has been adopted – all packages and property names are now prefixed with "jakarta." and the Java Platform, Enterprise Edition will be called "Jakarta EE" in future. The version numbering has continued: Version 8 was an interim version which can largely be ignored, and Jakarta EE 9 is the point at which the "jakarta." prefix takes effect.

The main Jakarta EE technology that applies in the IBM MQ context is Jakarta Messaging 3.0 – the successor to Java Message Service (JMS) 2.0. So Jakarta EE 9 incorporates Jakarta Messaging 3.0.

IBM MQ continues to support Java EE 7 and JMS 2.0, while introducing support for Jakarta EE 9 and Jakarta Messaging 3.0.

What is delivered: Java SE

For the Java Platform, Standard Edition, in addition to the IBM MQ classes for JMS (which support JMS 2.0 operations with IBM MQ) IBM MQ 9.3.0 and later versions provide IBM MQ classes for Jakarta Messaging. These classes provide a Jakarta Messaging 3.0 provider that integrates with IBM MQ, allowing use of IBM MQ queue managers to facilitate Jakarta Messaging operations.

These are provided as a standard JAR file, com.ibm.mq.jakarta.client.jar, in the java/lib subdirectory of the IBM MQ installation.

For use in OSGi containers, such as Apache Felix or Eclipse Equinox, IBM MQ also provides a pair of OSGi bundles:

com.ibm.mq.osgi.jms30.clientprereqs_V.R.M.F.jar
com.ibm.mq.osgi.jms30.client_V.R.M.F.jar

where V.R.M.F represents the version of IBM MQ, for example 9.3.0.0. These bundles can be found in the java/lib/OSGi subdirectory of the IBM MQ installation.

What is delivered: Jakarta EE 9 and Jakarta EE 10

To support IBM MQ-based messaging in Jakarta EE 9 and later compatible application servers, IBM MQ provides a resource adapter for Jakarta Messaging: wmq.jakarta.jmsra.rar. This can be found in the in the java/lib/jca subdirectory of the IBM MQ installation.

IBM MQ continues to provide a Java EE 7 compatible resource adapter, wmq.jmsra.rar, in the java/lib/jca subdirectory of the IBM MQ installation.

How these artifacts are delivered

These JARs and the RAR file for the resource adapter are packaged with the preexisting artifacts in the usual IBM MQ installation media – both the platform-specific installation media, such as ".rpm" files, and the redistributable media, such as the self-extracting redistributable client JAR files.

What has changed between JMS 2.0 and Jakarta Messaging 3.0

Jakarta EE 9 and Jakarta Messaging 3.0 introduce no new functionality. All that changes is names. For example, where you use "javax.jms.Connection" in JMS 2.0, you use "jakarta.jms.Connection" in Jakarta Messaging 3.0.

As the Eclipse Foundation takes the Jakarta EE platform forward, it will build on this foundation and this naming convention will be used for new functionality introduced in future.

What has changed between IBM MQ classes for JMS and IBM MQ classes for Jakarta Messaging

Summary

IBM MQ classes for JMS, which provide support for JMS 2.0, remain available and are recommended primarily for maintaining and extending existing applications. They are fully supported.

IBM MQ classes for Jakarta Messaging, which provide support for Jakarta Messaging 3.0, are recommended for new development.

At IBM MQ 9.3.0, these two offerings were functionally equivalent. Only naming differs. However, new messaging functionality is more likely to emerge in IBM MQ classes for Jakarta Messaging than in IBM MQ classes for JMS.

The two offerings are interoperable. Messages produced by IBM MQ classes for JMS can be consumed by IBM MQ classes for Jakarta Messaging, and vice versa. But the two offerings must not coexist in a single application.

Naming changes

Table 1. Changes to package names
IBM MQ classes for JMS package name	IBM MQ classes for Jakarta Messaging package name
com.ibm.mq.jms[.*]	com.ibm.mq.jakarta.jms[.*]
com.ibm.jms	com.ibm.jakarta.jms
com.ibm.msg.client.jms.*	com.ibm.msg.client.jakarta.jms.*
com.ibm.msg.client.wmq.*	com.ibm.msg.client.jakarta.wmq.*

The packages relating to common services (trace, logging, national language support etc) and the JMQI implementations (local and remote) are common to both IBM MQ classes for JMS and IBM MQ classes for Jakarta Messaging, so no changes are necessary in these areas.

Note that property names have also changed. For example, the property to enable IBM MQ extensions in IBM MQ classes for Jakarta Messaging is com.ibm.mq.jakarta.jms.SupportMQExtensions.

Property names which are independent of IBM MQ classes for JMS or IBM MQ classes for Jakarta Messaging, such as the various com.ibm.msg.client.commonservices.trace.* properties, apply equally to both offerings.

Administrative utilities

The crtmqenv and setmqenv utilities now accept an option to specify whether the classpath should be configured for IBM MQ classes for JMS (-j 2.0) or IBM MQ classes for Jakarta Messaging (-j 3.0), and there are IBM MQ classes for Jakarta Messaging variants of the runjms utilities, called runjms30 and similar names.

The dspmqver utility, when requested to report on Java components, includes IBM MQ classes for Jakarta Messaging in its output.

To configure IBM MQ classes for Jakarta Messaging objects to be retrieved via JNDI, the new JMS30Admin utility is equivalent to the JMSAdmin utility for IBM MQ classes for JMS.

Note that as the underlying objects are from different packages. JNDI definitions created by JMSAdmin cannot be used by IBM MQ classes for Jakarta Messaging, nor can those created by JMS30Admin be used by IBM MQ classes for JMS.

Note: There is no support for IBM MQ classes for Jakarta Messaging objects provided by IBM MQ Explorer; its JNDI integration is for IBM MQ classes for JMS only.