JDK-8164907 : Eliminate dependency on java.naming/com.sun.jndi.toolkit.url
  • Type: Bug
  • Component: other-libs
  • Sub-Component: corba
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-08-27
  • Updated: 2017-03-09
  • Resolved: 2016-12-19
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 b150Fixed
Related Reports
Relates :  
Description
The java.corba module includes the JNDI CosNaming Service Provider and currently makes use of types in  java.naming/com.sun.jndi.toolkit.url. We need to eliminate this dependency so that a java.corba module outside of the JDK does not rely on JDK internal APIs.

To demonstrate the issue then simply remove the qualified export from java.naming and the build will fail. The simplest thing might be for java.corba to take a copy of com.sun.jndi.toolkit.url.UrlUtil and  com.sun.jndi.toolkit.url.GenericURLContext and put them in its own package.

While we are at it then we should move the code in jdk/src/java.corba to the corba repo so that the code is not split between two repos.
Comments
As of today it indeed requires the following: jdeps -m java.corba | grep qualified com.sun.corba.se.spi.orb -> jdk.internal.misc java.base (qualified) com.sun.jndi.cosnaming -> com.sun.jndi.toolkit.url java.naming (qualified) com.sun.jndi.url.iiop -> com.sun.jndi.toolkit.url java.naming (qualified) org.omg.CORBA -> sun.reflect.misc java.base (qualified) sun.corba -> jdk.internal.misc java.base (qualified) sun.corba -> sun.misc jdk.unsupported (qualified) sun.corba -> sun.reflect jdk.unsupported (qualified)
15-12-2016

Note that we have explicitly decided not to put the CosNaming Service Provider into its own module, the reason is that it would would `provides javax.naming.spi.InitialContextFactory` and so would be pulled in by service binding and conflict with our policy for root modules in JEP 261.
24-09-2016