Hello Alan, > On 11 Mar 2016, at 08:50, Alan Bateman <alan.bate...@oracle.com> wrote: > > > > 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.
Yes my mistake, I did mean javax.transaction. > > 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. Whatever the motivation, I referred to this package as “broken” because it has caused a great many problems for OSGi users. Applications that import the javax.transaction package may encounter NoClassDefFoundError due to the missing types if they wire to the platform export. The most commonly employed practical solution is to add back those types with the application ClassLoader. A properly constructed set of OSGi bundles *should* never throw NoClassDefFoundError or ClassNotFoundException, and I would hope this will also be the case in Jigsaw. > > 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. Would this include the javax.sql.* packages? Since javax.sql exposes XAResource via its method signatures, it would be necessary for the classloader of javax.sql to have visibility of those types also. Regards, Neil > > 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
