Details
-
Task
-
Resolution: Fixed
-
P3
-
None
-
b46
Backports
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8082036 | emb-9 | Alan Bateman | P3 | Resolved | Fixed | b46 |
Description
This task tracks a review of the Java Transaction API (JTA) is conjunction with EE with a view to agreeing a solution for how it will work with modules going forward.
The main issue here is that Java SE defines a subset of JTA, specifically:
1. javax.transaction with 3 exceptions. Java SE is required to carry these 3 exceptions because of the CORBA Java Language to IDL Mapping specification, specifically the section that deals with the mapping of CORBA System Exceptions to RMI Exceptions.
2. All of javax.transaction.xa due to an API dependency in JDBC (javax.sql.XA*).
In our prototype module graph then we have subsumed javax.transaction into the java.corba module, and javax.transaction.xa into the java.sql module. The primary motive was to avoid the JDBC module transitively requiring RMI (as the exception types in javax.transaction are java.rmi.RemoteException types). A secondary motive was to avoid having a tiny JTA module with a grand total of 6 tiny classes.
We need to see whether the approach in the current prototype module graph can be agreed with EE. It amounts to splitting JTA into javax.transaction and javax.transaction.xa and puts a constraint that rev'ing javax.transaction.xa will require rev'ing it in Java SE. For javax.transaction then it will come down to whether EE will override both CORBA and JTA. If they only override one of these then the current approach of subsuming the 3 exceptions for RMI-IIOP into the CORBA module will need to be re-examined.
The main issue here is that Java SE defines a subset of JTA, specifically:
1. javax.transaction with 3 exceptions. Java SE is required to carry these 3 exceptions because of the CORBA Java Language to IDL Mapping specification, specifically the section that deals with the mapping of CORBA System Exceptions to RMI Exceptions.
2. All of javax.transaction.xa due to an API dependency in JDBC (javax.sql.XA*).
In our prototype module graph then we have subsumed javax.transaction into the java.corba module, and javax.transaction.xa into the java.sql module. The primary motive was to avoid the JDBC module transitively requiring RMI (as the exception types in javax.transaction are java.rmi.RemoteException types). A secondary motive was to avoid having a tiny JTA module with a grand total of 6 tiny classes.
We need to see whether the approach in the current prototype module graph can be agreed with EE. It amounts to splitting JTA into javax.transaction and javax.transaction.xa and puts a constraint that rev'ing javax.transaction.xa will require rev'ing it in Java SE. For javax.transaction then it will come down to whether EE will override both CORBA and JTA. If they only override one of these then the current approach of subsuming the 3 exceptions for RMI-IIOP into the CORBA module will need to be re-examined.
Attachments
Issue Links
- backported by
-
JDK-8082036 Add module java.transaction to export API javax.transaction
-
- Resolved
-
- relates to
-
JDK-8077991 Missing javadoc in exceptions types in javax.transaction
-
- Closed
-
-
JDK-8068413 Exception types in javax.transaction are missing SUID
-
- Resolved
-