GSSCredential

[Douglas Surber]

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?

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.

Douglas

> On Jun 4, 2019, at 10:16 AM, Mark Rotteveel <mark at lawinegevaar.nl> wrote:
> 
> On 2019-06-04 16:24, pm at netcetera.ch wrote:
>> On 28.05.19 20:54, Douglas Surber wrote:
>>> We have received a request to add the following method to java.sql.ConnectionBuilder.
>>>   /**
>>>    * Provide a GSSCredential to authenticate the connection with the server.
>>>    *
>>>    * @param credential used to authenticate the connection. Not null.
>>>    * @return this ConnectionBuilder
>>>    * @throws SQLException if an error occurs.
>>>    */
>>>   ConnectionBuilder gssCredential(org.ietf.jgss.GSSCredential credential) throws SQLException;
>>> Any thoughts?
>> As the JDK is fully modular now the java.sql module will now
>> additionally require the java.security.jgss module. Anybody building a
>> customized JDK with jlink with a direct or indirect dependency to
>> java.sql will now have to package java.security.jgss as well.
> 
> That sounds like a good argument against this change.
> 
> Mark