JDK-8042900 : Allow com.sun.security.jgss to be in different module than org.ietf.jgss
  • Type: Bug
  • Component: security-libs
  • Sub-Component: org.ietf.jgss:krb5
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-05-10
  • Updated: 2016-08-19
  • Resolved: 2014-09-17
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 b32Fixed
Related Reports
Relates :  
JDK-8164437 - Test for JDK-8042900
Sub Tasks
JDK-8056141 :  
Move com.sun.security.jgss into a new module - Resolved
Description
One of the requirements for modules that export Java SE APIs is that they don't export additional JDK-specific APIs. JDK-specific APIs need to be exported by other (JDK-specific) modules. The JGSS code needs to be re-examined with a view to factoring out com.sun.security.jgss to another module.
Comments
I can think of a way to move com.sun.security.jgss out of java.jgss but it needs a new API. The new API is a static method ExtendedGSSContext.of(GSSContext) that wraps a GSSContext object into an ExtendedGSSContext. GSSManager.createContext will always return a plain GSSContext object and user can wrap it into an ExtendedGSSContext to call the extended methods. As the second step, before GSSManager.createContext returns, it can use reflection to detect if the extended interface exists, and if so, automatically call the new of() method to return a type of extended interface.
23-05-2014
I think a solution is possible that does not require changing the API. Consider this: 1. Introduce sun.security.jgss.WideGSSContext that serves as an extended GSSContext in the java.security.jgss module. 2. Define an interface in sun.misc for mapping GSS Objects and a corresponding set/get methods SharedSecret to setup and obtain the mapper object. 3. The static initializer of a class in com.sun.security.jgss would setup the secret 4. The static initializer of GSSManager (or some class in org.ietf.jgss) would use Class.forName to load the com.sun.security.jgss type if it exists. 5. The code in the java.security.jgss module that uses the mapper (if set) to map ExtendedGSSContext to internal WideGSSContext types. This is just a rough sketch for now, I would be happy to flesh this out more if needed. We will need to use the same pattern in the base module because of the jdk.net API.
22-05-2014
I'd like to avoid a 3rd module, two should be enough. Ideally, the module java.security.jgss (the module that exports the org.ietf.jgss API) will include the implementation and just work. If someone wants to use the JDK-specific API to JGSS (com.sun.security.jgss) then they link in that module. Given that ExtendedGSSContext extends GSSContext then it will mean that the JDK-specific module will depend on the Java SE module. Hopefully the jdeps tool will help you examine the dependencies.
22-05-2014
I know this is dirty, but is it possible to put everything into java.jgss but leave the API in com.sun.security.jgss non exported? Then we can define a new empty module jdk.jgss which is a "friend" of java.jgss, where java.jgss can export those APIs only to jdk.jgss and then jdk.jgss exports them to the public.
22-05-2014
That would be tricky. org.ietf.jgss defines the base GSS-API, and com.sun.security.jgss extends it, and sun.security.jgss implemented the extended interface. It feels abnormal to put the base API and the final impl into a module but leave the extended API in another. Do we allow duplicate classes in two modules? Say, jdk.jgss is an extension of java.jgss, and when jdk.jgss is installed, the class in it will shadow the one in java.jgss. If not possible, can I detect if jdk.jgss is installed or not inside java.jgss? The JDK-specific API works like this now: GSSContext c = gssManager.createContext(...) if (c instanceof ExtendedGSSContext) { // do more thing only available in JDK-specific API } // do base API things When gssManager.createContext() is called, I need to determine the type of the result depending on whether jdk.jgss is installed.
22-05-2014
Do I need to put implementations (sun.* classes) into a 3rd module? Or they are free to stay in either of java.jgss and jdk.jgss? BTW, what is the tool to quickly detect the dependence?
22-05-2014
In our prototype module graph, we currently have one JGSS / Kerberos module with the following contents (* donates exported) org.ietf.jgss (*) javax.security.auth.kerberos (*) com.sun.security.jgss (*) com.sun.security.sasl.gsskerb sun.net.www.protocol.http.spnego sun.security.jgss sun.security.jgss.krb5 sun.security.jgss.spi sun.security.jgss.spnego sun.security.jgss.wrapper sun.security.krb5 sun.security.krb5.internal sun.security.krb5.internal.ccache sun.security.krb5.internal.crypto sun.security.krb5.internal.crypto.dk sun.security.krb5.internal.ktab sun.security.krb5.internal.rcache sun.security.krb5.internal.util sun.security.ssl.krb5 For hygiene reasons, it is important to split this so that module exporting the Java SE APIs (org.ietf.jgss and javax.security.auth.kerberos) does not additional export JDK-specific APIs. So the task here is to investigate splitting this list of APIs into two. Think of these as module java.jgss and module jdk.jgss. The java.jgss module will export org.ietf.jgss and javax.security.auth.kerberos, the jdk.jgss module will export com.sun.security.jgss. Circular dependencies are not allowed. Hopefully this is a bit clearer now, I expect this bug will require refactoring (hopefully not too much work but that remains to be seen).
15-05-2014
What am I (the assignee) supposed to do?
15-05-2014