GSSCredential
Mark Rotteveel
mark at lawinegevaar.nl
Wed Jun 5 16:33:18 UTC 2019
On 5-6-2019 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?
>
> 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 whole idea of modules is that you don't depend on the Java SE as a
whole, but only on the modules that you really need. If you use modules,
then you only get what you require.
I believe attempts to load implementations of this interface would
probably fail if the module hasn't been declared as a required
dependency, but I would need to experiment to confirm because I'm not
that familiar with modules yet.
And for Java itself, attempts to compile `java.sql.ConnectionBuilder` or
generate its Javadoc will fail without the module dependency declared in
`java.sql`s `module-info.java`.
In other words, this addition might introduce additional headaches or
otherwise additional module dependencies for java.sql, which the
majority of drivers would not need otherwise. On the other hand, module
`java.security.jgss` is pretty small.
The alternative would be to have a driver specific interface declaring
the method, and the unwrapping/casting to that interface to set the
property.
Mark
--
Mark Rotteveel
More information about the jdbc-spec-discuss
mailing list