GSSCredential

Philippe Marschall pm at netcetera.ch
Tue Jun 11 11:19:50 UTC 2019


On 08.06.19 10:00, Mark Rotteveel wrote:
> On 7-6-2019 17:57, Douglas Surber wrote:
>> And here is the result with requires java.security.jgss instead of 
>> requires static.
>>
>>> dhcp-10-159-154-205:~ douglas.surber$ tmp/bin/java --list-modules
>>> bar.sql
>>> baz
>>> com.bar
>>> java.base at 11.0.1
>>> java.logging at 11.0.1
>>> java.naming at 11.0.1
>>> java.security.jgss at 11.0.1
>>> java.security.sasl at 11.0.1
>>> dhcp-10-159-154-205:~ douglas.surber$
> 
> I did some experiments, including generating a Proxy and using (direct) 
> reflection. When using the full runtime this will not yield a problem, 
> but in a fully modularized Java (built with jlink) generating a Proxy 
> will yield a `NoClassDefFoundError` like shown below (and similar for 
> calling `getDeclaredMethods` on the class implementing the interface or 
> on the interface).

I also did a small experiment [1] and adding #gssCredential as a default 
method removes the need for implementations to depend on 
java.security.jgss. SQLFeatureNotSupportedException would probably be 
more appropriate here.
I don't think this will help with proxies.

> I don't have a real objection to this, but on the other hand I don't see 
> the need for this method that can't be solved through vendor specific 
> means, or have been solved through vendor-specific means for a long time 
> already, so I wonder if this new method will see any real use.

Me neither. I just stared this discussion to make sure we understand and 
accept the consequences.

  [1] 
https://github.com/marschall/jlink-demo/blob/master/fake-jdbc/src/main/java/com/github/marschall/sql/ConnectionBuilder.java

Cheers
Philippe


More information about the jdbc-spec-discuss mailing list