timillar commented on issue #2882:
URL: https://github.com/apache/drill/issues/2882#issuecomment-1969173580
Hello,
I’ve been dealing with a similar issue last couple of days, so I thought
maybe some of the things I’ve figured out would be helpful.
Drill jdbc driver tries to patch protobuf and guava libraries and fails due
to java internals being closed to reflection by default since java 16. These
exceptions are logged (as WARNs), and are actually being swallowed by the
ProtobufPatcher / GuavaPatcher, so the first question is:
* how important are these patchers for the latest java / drill versions? If
one can live without them, then the simplest 'solution' would be to ignore the
warn logs from these classes.
These patchers also use Javassist’s toClass() without parameters, and I
think they recommend to use toClass(Class<?> neighbor) now, to deal with
illegal reflective access
([https://github.com/jboss-javassist/javassist/issues/369](https://github.com/jboss-javassist/javassist/issues/369))
- though I’m not sure how helpful it will be here.
In my case (trying to run drill-jdbc in quarkus) I had to disable the
Patchers explicitly, due to how javassist’s class patching conflicted with
quarkus’ own classloader. Disabling them also kinda fixes java’s issues with
illegal reflective access. But obviously, this is a very rough hack that I did
just to have it working for now.
```java
//must run before drill’s driver was loaded
var protobufPatchingAttempted =
ProtobufPatcher.class.getDeclaredField("patchingAttempted");
protobufPatchingAttempted.setAccessible(true);
protobufPatchingAttempted.setBoolean(null, true);
var guavaPatchingAttempted =
GuavaPatcher.class.getDeclaredField("patchingAttempted");
guavaPatchingAttempted.setAccessible(true);
guavaPatchingAttempted.setBoolean(null, true);
```
I think everything so far doesn’t depend on having module-info in your
project, and is caused by changes in reflective access checks since java 16.
As for named modules - while drill-jdbc works as an automatic module, it has
some older dependencies that might cause conflicts down the road (e.g., quarkus
requires netty 4.1+, but drill-memory-base depends on netty-buffer PoolArena
from some older version, and fails with ‘java.lang.NoSuchFieldError: Class
io.netty.buffer.PoolArena does not have member field 'int chunkSize’’).
And using drill-jdbc-all as a compile dependency with a named module is
impossible, since it doesn’t shadow all the packages under the oadd umbrella,
and sooner or later you’ll run into split package issue (e.g., ‘Module
‘your.module.name’ reads package 'org.w3c.dom' from both 'java.xml' and
'drill.jdbc.all'’ , when you add `requires java.sql` and `requires
drill.jdbc.all` together). So this one can only be used as a runtime dependency.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@drill.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
