Hello All and welcome to the new JTA group,
We will be submitting an MR for JTA 1.3, shortly that will be limited in scope to:
- Removal of the javax.transaction.xa package
- This package will be subsumed into the Java Platform JSR and will no longer be part of the JTA specification
- Specify that the module name for JTA is java.transaction
The JTA 1.3 jar will include the MANIFEST attribute Automatic-Module-Name specifying ‘java.transaction’ as its module name
Why do we want to do this?
- Java SE has provided a subset of JTA since Java SE 1.3
- javax.transaction.xa supports XA transactions in JDBC.and is co-located with JDBC in the java.sql module in Java SE 9. Because the java.sql module is not upgradeable, it is not possible for a standalone version of JTA to override the Java SE version of the XA package, but this is generally acceptable to applications because the XA package has been stable for many years and the Java SE version is identical to the Java EE version.
- JEP 261 indicates that:
- If a package is defined in both a named module and on the class path then the package on the class path will be ignored. The class path can, therefore, no longer be used to augment packages that are built into the environment. The
javax.transaction package, e.g., is defined by the
java.transaction module, so the class path will not be searched for types in that package. This restriction is important to avoid splitting packages across class loaders and across modules. At compile time and run time the upgrade module path can be used to upgrade modules that are built-in into the environment. The
--patch-module option can be used for other ad-hoc patching.
- By removing javax.transaction.xa:
- Eliminates the split package issue as the java.sql module now provides javax.transaction.xa
- Alex Buckley's "Under the Hood" session from JavaOne 2016  is a great resource for understanding the split package issue.
- Allows JTA to be specified on the module path
- The java.transaction module in Java SE 9 is an upgradable module, and used by modules such as java.corba
- Provides for the use of the full version of JTA, which includes additional types that are not in Java SE, that may be required by Java EE applications
- The Automatic-Module-Name MANIFEST attribute allows for JTA to have a stable module name (which has already been defined by Java SE following the naming convention specified in JEP 200)
- Once other dependencies, such as CDI, have stable module names, then JTA may become an explicit module
- Will help avoid issues with developers requiring JTA and migrating to Java SE 9
- Will be consistent across implementations
- example: Maven artifact: org.jboss.spec.javax.transaction: jboss-transaction-api_1.2_spec
A standalone version of JTA is available as the Maven artifact javax.transaction : javax.transaction-api. As of November 2017, this JAR file represents JTA 1.2, which consists of both the XA package, javax.transaction.xa, and the CORBA interop package, javax.transaction. The JAR files for JTA 1.2 and the upcoming JTA 1.3 may be deployed as follows:
- The JAR file for JTA 1.2 may be deployed on the classpath. (The XA package in the JAR file is ignored in favor of the XA package in the java.sql module. The CORBA interop package, javax.transaction, in the JAR file is used in preference to the package in the java.transaction module, which is not resolved by default on JDK 9. Note that if
--add-modules java.se.ee or
--add-modules java.transaction is used on JDK 9, then the CORBA interop package in the JAR file will be ignored in favor of the package in the java.transaction module.)
- The JAR file for JTA 1.2 may not be deployed on the modulepath. (It would be treated as an automatic module that contains the XA package, but this package would conflict with the XA package in the java.sql module.)
- The JAR file for JTA 1.3 may be deployed on the classpath. (The CORBA interop package in the JAR file is used in preference to the package in the java.transaction module, which is not resolved by default in JDK 9.)
- The JAR file for JTA 1.3 may be deployed on the modulepath and used as an automatic module called