<div dir="ltr"><div dir="ltr">On Sun, Nov 2, 2025 at 3:08 AM Alan Bateman <<a href="mailto:alan.bateman@oracle.com">alan.bateman@oracle.com</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I don't think it's possible to engage on the question as to why <br>
DriverManager does a visibility check.  The discovery and and driver <br>
registration in this API date back to early JDK releases and have been <br>
very problematic to secure.  I think (need Lance to confirm) that the <br>
hope was that the eco system would move to DataSource but it seems there <br>
is still a lot of usage of DriverManager.<br></blockquote><div><br></div><div>I don't want to get into that quagmire either. I know this code is from the distant past and has been troublesome to migrate forward.</div><div><br></div><div>However, I think the intent of the code can be restored with a simple patch:</div><div><br></div><div>```diff</div>diff --git a/src/java.sql/share/classes/java/sql/DriverManager.java b/src/java.sql/share/classes/java/sql/DriverManager.java<br>index 2f51dee5e70..328d5f19946 100644<br>--- a/src/java.sql/share/classes/java/sql/DriverManager.java<br>+++ b/src/java.sql/share/classes/java/sql/DriverManager.java<br>@@ -588,7 +588,9 @@ private static Connection getConnection(<br>          * or bundled with an application, is found.<br>          */<br>         ClassLoader callerCL = caller != null ? caller.getClassLoader() : null;<br>-        if (callerCL == null || callerCL == ClassLoader.getPlatformClassLoader()) {<br>+        if (callerCL == null ||<br>+                callerCL == ClassLoader.getSystemClassLoader() ||<br>+                callerCL == ClassLoader.getPlatformClassLoader()) {<br>             callerCL = Thread.currentThread().getContextClassLoader();<br>         }<br> ```</div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container">I believe the original goal of the `callerCL == null` check was to allow driver load requests from the system/boot classloader to fall back on the thread context classloader, since such classes used to have `getClassLoader` as null. But with the module change, that classloader is now an instance of `ClassLoaders::AppClassLoader` and neither null nor == `getPlatformClassLoader`. My patch above restores the original intent by also checking if the callerCL is the same classloader as `getSystemClassLoader`, the default base application classloader now.</div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container">This change fixes the reported issue:</div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container">```</div>$ JAVA_HOME=build/macosx-aarch64-server-release/images/jdk/ jruby -r 'jdbc/sqlite3' -e 'Jdbc::SQLite3.load_driver' -e 'java.sql.DriverManager.get_connection("jdbc:sqlite:local.db")'<br>WARNING: A restricted method in java.lang.System has been called<br>WARNING: java.lang.System::load has been called by org.sqlite.SQLiteJDBCLoader in an unnamed module (file:/Users/headius/work/jruby/lib/ruby/gems/shared/gems/jdbc-sqlite3-3.46.1.1/lib/sqlite-jdbc-3.46.1.1.jar)<br>WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module<br><div class="gmail_quote gmail_quote_container">WARNING: Restricted methods will be blocked in a future release unless native access is enabled</div><div class="gmail_quote gmail_quote_container">```</div></div>