Corba and Transaction module problems with JDK9-ea+138

[Stephen Felts]

I have the following:
Module path:  javax.enterprise.cdi.api.jar  javax.interceptor.javax.interceptor.api.jar
Upgrade module path: java.transaction.jar  javax.annotation-api-1.2.jar

I'm not sure how much of that you will need.

-----Original Message-----
From: Alan Bateman 
Sent: Wednesday, October 05, 2016 7:28 AM
To: Christian Beikov; jigsaw-dev at openjdk.java.net
Subject: Re: Corba and Transaction module problems with JDK9-ea+138

On 05/10/2016 10:41, Christian Beikov wrote:

> Hello again,
>
> I am trying to run OpenEJB on JDK9 but can't get it to work. I added 
> java.corba and java.xml.bind but since java.corba has a dependency on 
> java.transaction, the JAR on the classpath containing the other 
> classes of the javax.transaction package seem "invisible". Is there a 
> way to deactivate the java.transaction module although it is required 
> for java.corba?

I assume you need the EE version of the java.transaction module. If you had that then you could deploy it on the upgrade module path (--upgrade-module-path option) to upgrade/override the Java SE version of java.transaction and move on.

The EE version of the java.transaction module `exports java.transaction` and does not contain any classes in javax.transaction.xa (because they have moved to the java.sql module, long story).

Sadly, there isn't an EE version of this module published anywhere yet. 
In the mean-time there are ways to get this working, it's just a bit complicated until there are EE versions of components that are shared between Java SE and Java EE.

1. Patch the JDK's java.transaction module to add the extra classes that Java EE defines. This means creating a directory or JAR file with the javax.transaction classes (not the javax.transaction.xa classes) and patch the module with a command like this:
    --patch-module java.transaction=/d/transaction.jar

2. Alternatively, create your the java.transaction module yourself. You can do this by unpacking the EE transaction.jar to a "classes" 
directory, blowing away the classes in javax/transaction/xa, and then compiling the module descriptor:

module java.transaction {
     requires public java.rmi;
     exports javax.transaction;
}

$ javac -d classes module-info.java
$ jar cf transaction.jar -C classes .

You can then deploy the resulting modular JAR on the upgrade module path
with:
     -upgrade-module-path eemods (or eemods/transaction.jar if you want)

I'm assuming in both approaches that they aren't additional dependences, if they are then the direct dependences will need to be modules (automatic modules to the rescue). Let's see if you need that.

-Alan