ModifiedClassPathRunner is broken with Java 9

[snicoll]

The classloader type is not a URLClassLoader anymore:

Caused by: java.lang.ClassCastException: java.base/jdk.internal.loader.ClassLoaders$AppClassLoader cannot be cast to java.base/java.net.URLClassLoader
	at org.springframework.boot.junit.runner.classpath.ModifiedClassPathRunner.createTestClassLoader(ModifiedClassPathRunner.java:96)
	at org.springframework.boot.junit.runner.classpath.ModifiedClassPathRunner.createTestClass(ModifiedClassPathRunner.java:74)
	at org.junit.runners.ParentRunner.<init>(ParentRunner.java:83)
	at org.junit.runners.BlockJUnit4ClassRunner.<init>(BlockJUnit4ClassRunner.java:65)
	at org.springframework.boot.junit.runner.classpath.ModifiedClassPathRunner.<init>(ModifiedClassPathRunner.java:68)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)

[AlanBateman]

The implementation type of the application class loader has never been specified and has changed in JDK 9 (JEP 261 has details on this). In general then the only supported/documented way to dynamically extend the class path is with JVM TI or java.lang.instrument.

Is there is a good description as to why test runner is doing? Why doesn't it create a URLClassLoader itself to load what needs to be tested?

[snicoll]

@AlanBateman we do have a fix in our JDK9 branch in case you'd like to have a look to it

[AlanBateman]

RuntimeMXBean::getClassPath is equivalent of System.getProperty("java.class.path") so it's the initial class path. The Class-Path attribute in JAR files may mean that search class includes other JAR files.

Also just to point out that File::toURL is deprecated (for good reasons).

[wilkinsona]

Thanks for taking a look, @AlanBateman.

RuntimeMXBean::getClassPath is equivalent of System.getProperty("java.class.path") so it's the initial class path. The Class-Path attribute in JAR files may mean that search class includes other JAR files.

Good point. We could just use the system property. This code is only used in our tests so we don't need to worry too much about the Class-Path attribute in JAR Files. We do consider it for Surefire's booter jar and that's served us well thus far.

Also just to point out that File::toURL is deprecated (for good reasons).

I can't see where we're calling that (and neither can Eclipse judging by the lack of deprecation warnings). I can see this::toURL which calls File.toURI().toURL() (and turns any checked exception into a lamda-friendly unchecked exception).

[snicoll]

Duplicate of #10020