Prior to this commit, if a FileSystemResource was created from a
java.nio.file.Path or java.nio.file.FileSystem, the URI returned from
getURI() was based on the semantics of Path#toUri() which always
includes the "authority component" (i.e., "//") after the scheme (e.g.,
"file://..."). In contrast, if a FileSystemResource is created from a
java.io.File or String, the URI returned from getURI() never includes
the "authority component" due to the semantics of File#toURI().
Consequently, invoking myFileSystemResource.getURI().toString() could
result in "file:/my/path" or "file:///my/path", depending on how the
FileSystemResource was created.
This behavior is not new; however, recent changes in
PathMatchingResourcePatternResolver -- which result in a
FileSystemResource being created from a java.nio.file.Path instead of
from a java.io.File -- make this difference more noticeable to users
and may in fact surface as a breaking change.
To address that issue, this commit revises the implementation of
FileSystemResource.getURI() by normalizing any `file:` URIs that it
returns. Effectively, URIs like "file:///my/path" will now take the
form "file:/my/path".
See gh-29163
Closes gh-29275
7175c4ca9a