running Groovy on JDK9

[Alan Bateman]

On 11/04/2016 16:57, Jochen Theodorou wrote:
> :
>
> Can it be registered via registerDriver? That actually made me wonder 
> why exactly we require the system loader here in the first place.
>
> Part of the problem is DriverManager#getConnection, which is 
> @CallerSensitive. So if I want to get a connection from an arbitrary 
> loader, it has to be the same loader, that registered the driver, or a 
> higher one. Here getConnection is done from library code, with a 
> different loader. So it cannot work that way... sigh... not reliably.
I need to dig into the history of JDBC to fully understand why this is 
so. Clearly the original JDBC API used a global registry of JDBC drivers 
and this falls apart when there are several applications running in the 
VM, esp. as each might bundle its own drivers and have a different view 
of the available drivers. In Java EE applications then the TCCL is often 
used to identify the application and it's not clear why this wasn't done 
here.

> :
>
> And then of course there is the problem of XML parser being loaded 
> dynamically. You get effects like this: 
> https://bugs.openjdk.java.net/browse/JDK-8015099, and we too had 
> already a load of fun with xerces being part of the distribution and 
> the violation of classloading constraints. All that gets worse, if you 
> want to "download" something like xpp3 from the web in your 
> application and then use it directly.

This is very fishy too as this is not how JAXP is intended to work. If 
there are two web applications in the same VM then they shouldn't 
interfere. The only obvious interference that I can see in the bug 
report is the "workaround" as that changes VM wide default. Someone 
needs to dig into it but it may be that the first app is also setting 
org.xml.sax.driver to change the VM-wide default.


> :
>
> that would then be:
>
>> org.codehaus.groovy.runtime.InterfaceConversionTest > 
>> testDefaultInterfaceMethodCallOnProxy FAILED
>>     java.lang.AssertionError: java.util.Comparator/2
>>         at 
>> java.lang.invoke.MethodHandles$Lookup.toString(java.base at 9-ea/MethodHandles.java:792)
>>         at java.lang.String.valueOf(java.base at 9-ea/String.java:2806)
>>         at 
>> java.lang.StringBuilder.append(java.base at 9-ea/StringBuilder.java:135)
>>         at 
>> java.lang.invoke.MemberName.makeAccessException(java.base at 9-ea/MemberName.java:867)
>>         at 
>> java.lang.invoke.MethodHandles$Lookup.checkAccess(java.base at 9-ea/MethodHandles.java:1642)
>>         at 
>> java.lang.invoke.MethodHandles$Lookup.checkMethod(java.base at 9-ea/MethodHandles.java:1582)
>>         at 
>> java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(java.base at 9-ea/MethodHandles.java:1731)
>>         at 
>> java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(java.base at 9-ea/MethodHandles.java:1725)
>>         at 
>> java.lang.invoke.MethodHandles$Lookup.unreflectSpecial(java.base at 9-ea/MethodHandles.java:1336)
>>         at 
>> org.codehaus.groovy.vmplugin.v7.Java7.getInvokeSpecialHandle(Java7.java:96)
>>         at 
>> org.codehaus.groovy.runtime.ConversionHandler.invoke(ConversionHandler.java:109)
>>         at com.sun.proxy.$Proxy47.reversed(Unknown Source)
>>         at java_util_Comparator$reversed$0.call(Unknown Source)
>>         at 
>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
>>         at 
>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
>>         at 
>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
>>         at 
>> org.codehaus.groovy.runtime.InterfaceConversionTest.testDefaultInterfaceMethodCallOnProxy(InterfaceConversionTest.groovy:52)
>
> but if I see the trace correctly, this is already due to a failed 
> access check and just a secondary error, or wrong?
I suspect there is a bug here as I think how it is possible to have a 
Lookup with this lookup mode. Are you able to establish where this 
Lookup is created and if it indeed created with only the PRIVATE mode set.

-Alan