[sannegrinovero]

The problem is not different than how we do things in JBoss Modules - i.e. in the modular classloader used by WildFly. You have several choices.

One option is to use `-upgrademodulepath` so to override the JTA API module from Java SE and replace it with your JavaEE version, to add the missing classes such as javax.transaction.Synchronization. This will effectively replace the one bundled by the JavaSE platform with the one you want, so it's the most powerful option but requires end users to enable the right flags on JVM boot as you'd need both to replace the module and then to make sure it's also exposed to the application classloader. This is I suspect what we'd want to do for WildFly, although this is just my impression: better ask David Lloyd for confirmation.

Another option is to let java.corba to use the java.transaction module from Java SE, while you use your own. The benefit of modularity is that different components can use different implementations, so you have such choices but to understand if this is a smart choice depends on how we want to interact with the corba and transaction modules and how you want them to interact with each other: it's not a good idea to have them use different module implementations if you expect them to interact directly w/o your own code somehow separating the two layers.

This would have the added benefit of not needing end users to set any JVM flag but it's only a safe choice if the Corba module never ever exposes any javax.transaction class in practice: you'd need to make sure that there is never ambiguity about "which" implementation of any class is being passed in a reference (or returned). This is usually easiest to achieve if a module like Corba were to never expose such types on its public API. If it does expose it, you might be able to avoid using or touching those methods in practice but it gets tricky to handle.

I hope this helps; if you have a specific issue I'm happy to have a look so to make the conversation less abstract.

[mmusgrov]

I updated my script to create a new java EE transactions api spec jar to "fix" this issue which also manifests if one needs to use the java.sql module together with the java EE transactions api spec jar since they both export the javax.transaction.xa package and will therefore get a run-time error. The script:

• fetches (via wget) a copy of jboss-transaction-api_1.2_spec-1.0.0.Final.jar
  
• adds a module-info class to the spec jar that
  • requires public java.sql;
  • exports javax.transaction;
• removes the javax.transaction.xa package from the spec jar

[adinn]

Well, this outcome is a bit of a bummer. It seems any app wanting to use our transactions code (including EAP etc) on a Jigsaw-enabled JDK will have to override the javax.transaction module from the java command line to use this modified version of our transactions api spec jar as a module. And this is all because java.sql exposes package javax.transaction.xa causing a conflict when we deploy our current  transactions api spec jar. Here is the relevant note from Alan Bateman providing some background for why this problem has arisen

  http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008781.html

n.b. it might be good to ask Antoine Sabot-Durand what  his interest in this is (he is Red Hat's current CDI Spec lead) into this -- he asked the question Alan is replying to.

Also, does anyone know anything more about the discussion referred to in Alan's comment "The proposal has of course been discussed/agreed with the relevant JSR leads."? Given that the JTA spec is in maintenance and has only one Oracle empoloyee (Paul Parkinson Oracle) in charge of it looks like the discussion must either have happened a long time ago or not have involved many interested parties.

[tomjenkinson]

Hi Andrew,

Can you just clarify. Is the intention that java.sql exports the XAResource interface? Because if that is the case how about if you are just using JMS or some other XAResource type?

I can ask this myself but it would be useful to understand what you believe to be the case first.

Thanks,

Tom

[adinn]

Hi Tom,

Tom Jenkinson wrote:

Hi Andrew,

Can you just clarify. Is the intention that java.sql exports the XAResource interface? Because if that is the case how about if you are just using JMS or some other XAResource type?

I can ask this myself but it would be useful to understand what you believe to be the case first.

It is already the case that in a Jigsaw-enabled JDK9 module java.sql exports package javax.transaction.xa. The current JIgsaw module implementation contains the same 3 XA classes that are in our current JBoss transaction api jar.

I am not really sure what this means as regards using JMS or some other XAResource type.

What I do know is that when you package the current JBoss transaction api jar as a module either by adding a module-info.class or simply by adding it to the module path so it is 'auto-modularised' the presence of classes in package javax.transaction.xa causes Jigsaw to barf because that package has been bagged by rmodule java.sql.

I would also expect deploying a jar in the classpath which includes classes in package javax.transaction.xa would also cause Jigsaw to barf. However, I am not sure this will happen. Perhaps Mike knows the answer to that?

[mmusgrov]

Andrew Dinn wrote:

I would also expect deploying a jar in the classpath which includes classes in package javax.transaction.xa would also cause Jigsaw to barf. However, I am not sure this will happen. Perhaps Mike knows the answer to that?

Yes "javac will emit a warning when compiling classes in a package of an existing module" (Project Jigsaw: Quick Start Guide). The solution would be to put the extra classes into the existing module using the patching mechanism (I had to do this for the java.corba module since the OTS idl generates classes in the org.omg.CORBA package):

[sannegrinovero]

Do you need to use the java.sql module from the platform, or could we use a custom module instead?

[mmusgrov]

Sanne Grinovero wrote:

Do you need to use the java.sql module from the platform, or could we use a custom module instead?

I do not understand your comment.

[adinn]

Hi Sanne,

Sanne Grinovero wrote:

Do you need to use the java.sql module from the platform, or could we use a custom module instead?

We could perhaps substitute a java.sql module which does not contain the javax.transaction.xa classes. However, if there is any code in the runtime that imports java.sql and does not import the javax.transaction module then the risk is that it might expect and not find the classes in package javax.transaction.xa. Since this is what the JSR owners have agreed is the right place to find these classes (according to Alan) we would be doing something non-standard if we did what you suggest. It probably makes no difference but ...

[tomjenkinson]

It struck me we never provided a link to the issue where this work is taking place: [JBTM-2685] Check that narayana builds and runs using the Java SE 9 compiler - JBoss Issue Tracker

Feel free to look at our in-progress branch for this work: Comparing master...jdk9-experimental · jbosstm/narayana · GitHub