Unnamed module and duplicate package

Alan Bateman Alan.Bateman at oracle.com
Fri Mar 11 08:50:51 UTC 2016



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


More information about the jigsaw-dev mailing list