Fallback isolated ClassLoader to platform classes

[paul-hristea]

Solves #338

[mgaffigan]

Can you post repro steps for testing purposes?

[github-actions]

Test Results

654 tests  ±0   654 ✅ ±0   3m 17s ⏱️ +34s
108 suites ±0     0 💤 ±0 
108 files   ±0     0 ❌ ±0 

Results for commit f62537f. ± Comparison against base commit a08c114.

♻️ This comment has been updated with latest results.

[paul-hristea]

Sure thing @mgaffigan . I've edited it into the issue description (#338) for better visibility.

[jonbartels]

Would this affect cases where a user has classes in a resource directory that includes libraries that do conflict with the parent classloader?

I reviewed this issue by reading the docs for how the URLClassloader works for both old and new versions of Java:

• https://docs.oracle.com/javase/8/docs/api/java/net/URLClassLoader.html
• https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/net/URLClassLoader.html

Since the behaviour hasn't changed in 18 major versions I think we can safely assume that it won't break anything in the future :D

I read the references in the PR description.

This change is logical and correct. If a driver is loaded, that driver will have dependencies in the system classpath. Therefore including the system classpath is appropriate. HOWEVER see my question above. What happens if a user needs the classloader specifically to override something on the system classpath? Is this common enough to worry about?

[paul-hristea]

Hi @jonbartels, thanks for taking time to review!

I believe that this is why the "Load Parent-First" option was introduced - it allows us to choose whether each Resource is meant to take priority during class loading. The cases you ask to consider should be solvable by making use of this checkbox - although they should be uncommon since the move from Java 8 began quite recently.

[tonygermano]

I believe this is the correct change to make so that it behaves similarly to how it ran under java 8. The change itself would have been difficult to make prior to bumping the minimum version to java 17 because the method did not exist in java 8; it would have needed to test if it existed and call it by reflection.

I tested using the driver from https://h2database.com/html/main.html

• added the driver as a resource (did not check load parent first)
• added a database reader channel
• added the driver resource to the channel
• specified the driver as org.h2.Driver
• specified the jdbc uri as jdbc:h2:./appdata/h2.db
• clicked the Generate: Select button above the SQL section
• clicked the Get Tables button

Under the main branch, this threw a ClassNotFound Exception for java.sql.Driver.

With the fix from this branch

• no error is thrown
• no tables are returned (I never created any)
• a non-empty database file is created at the location specified in the appdata folder

[tonygermano]

What happens if a user needs the classloader specifically to override something on the system classpath? Is this common enough to worry about?

@jonbartels The platformClassLoader contains classes provided by the JRE which were just always included under java 8, but are no longer considered "core" classes since the move to the module system.

The systemClassLoader is the one that includes the classpath given when the JVM starts.

The platformClassLoader is an ancestor of the systemClassLoader.