JDBC DriverManager never updated for system classloader?

[Charles Oliver Nutter]

Hello!

I've been looking for a concrete explanation for why the JDBC DriverManager
can't find drivers under the following circumstances:

* Driver jar loaded into child classloader of app classloader
* Child classloader set for current thread's context classloader

My long explanation of the issue is here:

https://github.com/jruby/jruby/issues/8910#issuecomment-3453029437

The short explanation is that when the DriverManager goes to check for
"allowed" drivers, it ends up using the wrong classloader.

https://github.com/openjdk/jdk/blob/8151251fa683459e57430abf8e3583c444315746/src/java.sql/share/classes/java/sql/DriverManager.java#L157

* Caller's class is acquired with Reflection.getCallerClass
* Caller's classloader is acquired
* If that classloader is null, as it would have been for classes loaded on
the root classpath in Java 8, it instead uses the thread context
classloader.
* If that classloader is not null (Java 9+) and not the platform
classloader, it is used for verification; in this case it is the system
classloader (a "ClassLoader#AppClassLoader" instance) so the child
classloader's driver is disallowed.

My confusion is why this code was never patched for the change to the
system classloader (from null to an AppClassLoader). The logic in
DriverManager will never use the ThreadContext classloader now, since
there's almost no cases where "getClassLoader" will return null.

Is there a good explanation for why this code still checks for a null
classloader?

*Charles Oliver Nutter*
*Architect and Technologist*
Headius Enterprises
https://www.headius.com
headius at headius.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251027/450dbc2d/attachment.htm>