File tree
1 file changed
+11
-3
lines changed1 file changed
+11
-3
lines changedOriginal file line number | Diff line number | Diff line change | |
---|---|---|---|
| |||
516 | 516 |
| |
517 | 517 |
| |
518 | 518 |
| |
519 |
| - | |
520 |
| - | |
| 519 | + | |
| 520 | + | |
| 521 | + | |
| 522 | + | |
| 523 | + | |
| 524 | + | |
| 525 | + | |
521 | 526 |
| |
522 | 527 |
| |
523 | 528 |
| |
| |||
1186 | 1191 |
| |
1187 | 1192 |
| |
1188 | 1193 |
| |
1189 |
| - | |
| 1194 | + | |
| 1195 | + | |
| 1196 | + | |
| 1197 | + | |
1190 | 1198 |
| |
1191 | 1199 |
| |
1192 | 1200 |
| |
|
2 commit comments
AlanBateman commentedon Nov 28, 2023
I don't think these changes to ServiceLoader make sense. Would it be possible to track down the service lookup that the changes now trigger during startup?
jianglizhou commentedon Nov 29, 2023
I looked into my notes on this. The related issue that I ran into on JDK 11 was a
java.util.ServiceConfigurationError
during VM initialization. In the particular case,java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass()
needed to callClassLoader.getSystemResources(fullName)
to find custom provider specified byMETA-INF/services/java.nio.file.spi.FileSystemProvider
. With the early usage ofjava.nio.file.FileSystems.newFileSystem()
due to hermeticJavaHome
changes, it triggered theFileSystemProvider.loadInstalledProviders()
call path duringinitPhase3
. DuringinitPhase3
,ServiceLoader
constructor used the null class loader to load the custom provider, hence the failure. Normally (for most of tests),FileSystemProvider.loadInstalledProviders()
was triggered afterVM.initLevel(4)
and thejdk.internal.loader.ClassLoaders$AppClassLoader
instance was used for loading theFileSystemProvider
, so no issue in those cases.With the latest code base, I've also changed to delay initializing the
jarFileSystem
usingFileSystems.newFileSystem
in JavaHome. That may hide thisj.u.ServerLoader
issue.