GSSCredential

[Douglas Surber]

> Given using proxies and reflection is very common in JDBC drivers and related tools and libraries (especially with `DataSource` related things), declaring as `requires static` is not an acceptable solution. Declaring with `requires` will be the minimum necessary to ensure proper functionality and the least amount of surprise. Probably `requires transitive` is better as JDBC drivers will need to actually implement this method as well. Otherwise, the driver will need to use `requires static`, `requires` or `requires transitive` themselves; although I have actually not seen modularized JDBC drivers yet so maybe that is of lesser importance.

As a driver implementer I have no problem with the driver module-info.java including 'requires static java.security.jgss'. The driver would use 'requires static' so that driver users would not have to include java.security.jgss unless they actually used it.

Proxying requiring java.security.jgss is a bigger concern. As you say, proxying a very common in stacks that use JDBC. I doubt any of our customers would care. I have no idea if there are any JDBC users that require an absolutely minimal module set and that also use proxying.

Sure this can be just a proprietary extension; there no real necessity that it be part of the standard. But from that perspective there isn't much need for a JDBC standard at all. In spite of all the standardization around SQL, the various databases are all quite different. It is hard to write a vendor independent JDBC app of much sophistication. But since we have a JDBC standard. since GSS is itself a standard, and since using GSS to authenticate to a database is common enough, it seemed reasonable to add GSS support to JDBC. Oracle is not the only vendor to want to support GSS. I know SqlServer does also. I can't say about other vendors.

Mostly I am disappointed that Jigsaw has such a profound effect on API design. Without Jigsaw this question would never have arisen.

Douglas


> On Jun 8, 2019, at 1:00 AM, Mark Rotteveel <mark at lawinegevaar.nl> 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).
> 
> Given using proxies and reflection is very common in JDBC drivers and related tools and libraries (especially with `DataSource` related things), declaring as `requires static` is not an acceptable solution. Declaring with `requires` will be the minimum necessary to ensure proper functionality and the least amount of surprise. Probably `requires transitive` is better as JDBC drivers will need to actually implement this method as well. Otherwise, the driver will need to use `requires static`, `requires` or `requires transitive` themselves; although I have actually not seen modularized JDBC drivers yet so maybe that is of lesser importance.
> 
> That just leaves the question if this is an acceptable widening of the dependencies of JDBC (for reference, the java.security.jgss.jmod is 623 kilobytes on my Java 11.0.3 compared to java.sql.jmod of 82 kilobytes).
> 
> 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.
> 
> Exception on creating proxy:
> 
> Exception in thread "main" java.lang.NoClassDefFoundError: org/ietf/jgss/GSSCredential
>        at java.base/java.lang.Class.getDeclaredMethods0(Native Method)
>        at java.base/java.lang.Class.privateGetDeclaredMethods(Class.java:3166)
>        at java.base/java.lang.Class.privateGetPublicMethods(Class.java:3191)
>        at java.base/java.lang.Class.getMethods(Class.java:1904)
>        at java.base/java.lang.reflect.Proxy$ProxyBuilder.referencedTypes(Proxy.java:712)
>        at java.base/java.lang.reflect.Proxy$ProxyBuilder.<init>(Proxy.java:624)
>        at java.base/java.lang.reflect.Proxy$ProxyBuilder.<init>(Proxy.java:635)
>        at java.base/java.lang.reflect.Proxy.lambda$getProxyConstructor$0(Proxy.java:415)
>        at java.base/jdk.internal.loader.AbstractClassLoaderValue$Memoizer.get(AbstractClassLoaderValue.java:329)
>        at java.base/jdk.internal.loader.AbstractClassLoaderValue.computeIfAbsent(AbstractClassLoaderValue.java:205)
>        at java.base/java.lang.reflect.Proxy.getProxyConstructor(Proxy.java:413)
>        at java.base/java.lang.reflect.Proxy.newProxyInstance(Proxy.java:1006)
>        at test.user/test.user.Main.main(Main.java:18)
> Caused by: java.lang.ClassNotFoundException: org.ietf.jgss.GSSCredential
>        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
>        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
>        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>        ... 13 more
> 
> -- 
> Mark Rotteveel