JDK-8068682 : Deprivilege/move java.corba to the ext class loader
  • Type: Enhancement
  • Component: other-libs
  • Sub-Component: corba
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-01-08
  • Updated: 2016-08-24
  • Resolved: 2015-02-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b52Fixed
Related Reports
Blocks :  
JDK-8068680 - Move java.transaction to the ext class loader
Relates :  
JDK-8035740 - Clean up dynamicStubFactoryFactory handling in the JDK ORB
Description
We need to move the module java.transaction to the ext class loader (see JDK-8068680). As the java.corba modules requires it then it means that the java.corba module needs to be moved first.
Comments
Mark - 3rd party ORBs should continue to located via the system class loader. The parent of the system class loader is almost always the extension loader so there shouldn't be any issue.
04-02-2015
Existing tests using jtreg "policy" action will need to be updated to use "java.security.policy" so that it will extend the system java.policy instead of overriding it. Second, the test policy files should be updated to remove any entry for jdk jar files as a clean up. For example, * @run main/othervm/secure=java.lang.SecurityManager/policy=jtreg.security.policy InputStreamSubclassTest needs to convert to use * @run main/othervm/secure=java.lang.SecurityManager/java.security.policy=jtreg.security.policy InputStreamSubclassTest JDK-8043277 converted some jdk regression tests to use java.security.policy.
02-02-2015
In terms of API then I assume it is javax.rmi.CORBA.Util.mapSystemException, is that right? My understanding is that someone can configure another ORB implementation that has support for OTS and so the Util.mapSystemException may be called with an exception that needs to map to a javax.transaction.XXXException.
09-01-2015
yes, that's true as in the case of GlassFish I presume.
09-01-2015
There's no transactional support (i.e. OTS) in the JDK ORB, AFAIK. There would be in GlassFish. From a quick "find" of the corba src, it looks like a there is Util class which is mapping some CORBA exceptions, including transaction exceptions, and this is where the dependency arises. What would be the side effect of removing these? Is it a general strategy to move CORBA to ext regardless?
08-01-2015