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