Fallback isolated ClassLoader to platform classes

[paul-hristea]

Solves #338

[mgaffigan]

Can you post repro steps for testing purposes?

[github-actions]

Test Results

  112 files  ±0    216 suites  ±0   6m 41s ⏱️ +55s
  654 tests ±0    654 ✅ ±0  0 💤 ±0  0 ❌ ±0 
1 308 runs  ±0  1 308 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit dabc06b. ± Comparison against base commit 7e35abe.

♻️ 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.