On 10/03/2016 23:58, Neil Bartlett wrote:
Paul,
This sounds like you are suggesting a backwards-incompatible change to the
behaviour of the application classpath.
For example, many apps include on their classpath a library containing
javax.transaction.xa, since the version of this package provided by the JDK is
broken (omits several types).
In general it has always been permissible for applications to provide their own
alternative implementations of the javax.* hierarchy, with only the java.*
hierarchy being off-limits due to the SecurityException that would be thrown by
ClassLoader.defineClass.
"provided by the JDK is broken" is misleading. On the other hand, "omits
several types" is accurate, assuming you mean javax.transaction rather
than javax.transaction.xa.
The transaction API is one of a small number of APIs shared between Java
SE and EE. The complete set is non-aggregator modules that java.se.ee
requires. In the case of the transaction API then Java SE defines the
minimum subset of javax.transaction required to support the mapping of
CORBA system exceptions to RMI exceptions. The Java Language to IDL
Mapping spec has the details. Java SE defines all the types in
javax.transacation.xa, important because JDBC supports XA.
The EE/app servers need to override JTA with the version that EE defines
(the version has all of the javax.transaction types). In JDK 8 and older
then the supported way of doing this was via the endorsed standards
override mechanism. It was never supported to deploy the upgraded
version as a JAR file on the class path. The endorsed standards override
mechanism doesn't make sense with modules and the replacement, as Alex
notes, is to deploy the EE version of the java.transaction (no 'x')
module on the upgrade module path.
Another way that would work is to compile or run with`-limitmods
java.se` so as to limit observability to just the Java SE modules that
do not overlap/share with Java EE. It would be as if the JDK doesn't
have the modules that are shared with EE.
For those interested in the transaction API then the module summary page
[1] has the details on the modules. The surprise might be that the
java.sql module has taken ownership for the javax.transaction.xa package.
-Alan
[1] http://cr.openjdk.java.net/~mr/jigsaw/ea/module-summary.html
