GSSCredential

[Philippe Marschall]

On 05.06.19 17:57, Douglas Surber wrote:
> I believe that even if this were added to the java.sql module, users of that module would not have to use java.security.jgss unless they actually used the method. java.security.jgss would not be required either to compile against java.sql or to execute code compiled against java.sql unless the method was used. Yes, compiling java.sql would require java.security,jgss, but using the compiled code either to build or execute would not.
> 
> Is my understanding correct?

I don't think so. jlink allows you to build a JDK with just the 
transitive closure of the modules you need. This means that 
java.security.jgss may not be present. It is my understanding that in 
this case ConnectionBuilder will not load.


> And regardless of whether the above is correct, if we decide not to include this method in java.sql, how should this capability be exposed in standard way? Surely the move to modules is not so restrictive as to prevent exposing such a capability when all the types in question are present in Java SE.

The issue is with exposing types on interfaces that should work when 
types are not present, ie. ConnectionBuilder.

I think a possible solution may include an extension mechanism on 
ConnectionBuilder. Something like

ConnectionBuilder credential(CredentialAccessor ca);

interface java.sql.CredentialAccessor<T> {

   T getCredential();

}

interface java.sql.GssCredentialAccessor extends 
java.sql.CredentialAccessor<org.ietf.jgss.GSSCredential> {


}

There is probably room for improvement here but such design or similar 
would allow for using other credentials as well without having their 
types on ConnectionBuilder.

I think it is best to ask for feedback on jigsaw-dev.

Cheers
Philippe