Where should we send modularization issue on "official" packages
Alan Bateman
Alan.Bateman at oracle.com
Fri Jul 22 10:30:22 UTC 2016
On 22/07/2016 09:35, Antoine Sabot-Durand wrote:
> Hi
>
> Using jta api and datasource in my project, I just got this error message:
>
> "module reads package javax.transaction.xa from both java.sql and
> javax.transaction.api"
>
> I know it's probably not the best place to report this, but I'm not sure
> where to send this since Java EE is not very active right now. Any
> suggestion would be welcome
>
> I'll correct my issue by recompiling jta-api without javax.transaction.xa
> package (whose content is similar than the one in java.sql module).
>
This is the right place to bring up this issue.
The summary on this is that if you building or deploying an upgraded
version of java.transaction then the upgraded version should export
javax.transaction. It should not export, or contain, any types in
javax.transaction.xa. Instead, the javax.transaction.xa package is
exported by the java.sql module (as you have found).
At some point then the EE version of this module needs to be published
as it will otherwise be confusing to try to use existing JTA sources to
create an explicit module, or use an existing jta-api.jar as an
automatic module.
The complication here arises because Java Transaction API is "shared"
between Java SE and Java EE. Java SE defines a tiny subset of
javax.transaction, something that dates back to when an early version of
Java SE added CORBA. Java EE defines the complete API. You need to dig
into the IDL Mapping specification and its table that maps CORBA
exceptions to RMI exceptions to get some of the history as to how Java
SE ended up with types in javax.transaction. It might initially look
like the right thing is for the java.sql module to require
java.transaction but this is highly problematic. One reason becomes
clear when you attempt create a small runtime image that has module
java.sql (to access a database). A second reason is that should be easy
to deploy with an upgraded version of the java.transaction module
without being concerned about split packages issues. This is why the JDK
does not resolve the EE owned modules by default at startup. To cut a
sad and long story short, the proposal is to split JTA into two. Module
java.transaction will export javax.transaction and can rev at whatever
pace that JSR 907 decides. Module java.sql will "own" and export
javax.transaction.xa. If JSR 907 decides to update anything in
javax.transaction.xa, and it doesn't appear to have done so in many
years, then it will need to coordinate with Java SE. The proposal has of
course been discussed/agreed with the relevant JSR leads.
Just on the error message that you included. Is "module reads" missing
your module name? Also since the module name reported is
"javax.transaction.api" then I assume you are using an automatic module.
When you re-package then naming it java.transaction.jar will ensure that
it retains the module name "java.transaction".
-Alan
More information about the jigsaw-dev
mailing list