[GR-55885] Initialize FileSystemProvider at run time (future defaults) #11205
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This changes allows initializing
FileSystemProviders at image run time. Since that is a behavioral change, the functionality must be unlocked with--future-defaults=allor--future-defaults=run-time-initialized-jdk(see also #10531).Note that with this turned on, no
FileSystemProviders are allowed in the image heap. Since those are referenced from common JDK classes, likejava.io.Fileorjava.nio.Path, and these classes unfortunately often end up in static variables, we have special handling for those to allow them in the image heap. However, this is not the case for customPathimplementations. So the general advice is to ensure thatPathandFileobjects are created at image run time.It allows to do the following that was previously not possible if the custom
FileSystemProvidercannot be initialized at build time (e.g. because it depends on run-time state):The example assumes that
META-INF/services/java.nio.file.spi.FileSystemProvidercontains a customFileSystemProviderthat registers themyfsscheme.Fixes #5134