Update `Path` creation for nested locations to allow both UNC and classic
file references to be used. This commit attempts to align our URL
handling with that of standard file URLs. The `NestedLocation` class
no longer attempts to remove leading all `\` characters and instead
only removes the first `\` when the second char is `:`. This duplicates
the logic found in Java's own internal `WindowsUriSupport` class which
is used when calling `Path.of(url)` with a `file:` URL.
Fixes gh-40549
Fix regression in `JarUrlConnection` where a NullPointerException could
be thrown internally causing performance issues.
When the SecurityManager is present, the following stack trace is
thrown:
java.lang.NullPointerException: Cannot invoke "java.net.URLConnection.getPermission()" because "this.jarFileConnection" is null
at org.springframework.boot.loader.net.protocol.jar.JarUrlConnection.getPermission(JarUrlConnection.java:175)
at java.base/jdk.internal.loader.URLClassPath.check(URLClassPath.java:553)
at java.base/jdk.internal.loader.URLClassPath$Loader.findResource(URLClassPath.java:612)
at java.base/jdk.internal.loader.URLClassPath.findResource(URLClassPath.java:296)
at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:629)
at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:627)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at java.base/java.net.URLClassLoader.findResource(URLClassLoader.java:626)
at org.springframework.boot.loader.net.protocol.jar.JarUrlClassLoader.findResource(JarUrlClassLoader.java:70)
at java.base/java.lang.ClassLoader.getResource(ClassLoader.java:1403)
at java.base/java.net.URLClassLoader.getResourceAsStream(URLClassLoader.java:290)
at java.base/java.lang.Class.getResourceAsStream(Class.java:2850)
See gh-39856
Refine the fix for gh-38611 so that `ClosedByInterruptException` no
longer retries in a loop.
Our previous fix was flawed due to the fact that another interrupt
could occur after we clear the first and whilst we are reading data.
If this happens 10 times in a row, we raise an exception and end up
causing NoClassDefFoundError errors.
Our new approach retains the use of `FileChannel` and a direct buffer
up to the point that a `ClosedByInterruptException` is raised or the
thread is detected as interrupted. At that point, we temporarily
switch to using a `RandomAccessFile` to access the data. This will
block the thread until the data has been read.
Fixes gh-40096
Rename the internal `FileChannelDataBlock` to `FileDataBlock` since we
want to fallback to a `RandomAccessFile` when a thread is interrupted.
See gh-40096
URL can contains empty spaced encoded as %20, so it should be decoded
before passing it to NestedLocation. NestedLocation expects file system
path which should not contain URL encoded values.
See gh-39675
Update `NestedJarFile` so that the `getManifest()` method returns the
manifest from the parent jar file for nested jars based on directory
entries.
This restores the previous behavior supported by Spring Boot 3.1 and
allows class methods such as `getPackage().getImplementationVersion()`
to return non `null` results.
Fixes gh-38996
Update `ZipContent` so that `META-INF` entries are no longer duplicated
in nested jars created from directory entries. This aligns with the
behavior of the classic loader and prevents the same META-INF file from
being discovered twice.
Fixes gh-38862
Update `JarFileArchive` so that unpacked jars use `file:` URLs rather
than `jar:file:`. This aligns with the behavior of Spring Boot 3.1 and
allows calls to `class.getSigners()` to work again.
Fixes gh-38833
In gh-38154, we started handling ClosedByInterruptException. The
FileChannel was repaired by recreating it and then the exception was
rethrown. This allowed other threads to use the channel that had been
read by an interrupted thread while allowing that interruption to
continue.
This approach has proven to be insufficient as there are scenarios
where the read needs to succeed on the interrupted thread. This
commit updates the handling of ClosedByInterruptException so that
this is the case. The FileChannel is recreated as before but the
thread's interrupted flag is now cleared before retrying the read.
The flag is then reinstated so that any subsequent actions that
should fail due to the interruption will do so.
We could clear and reinstate the interrupted flag before the first
read, rather than catching ClosedByInterruptException. This approach
was rejected as it will have an impact on the performance of the
happy path where the thread hasn't been interrupted.
Fixes gh-38611
Moritz Halbritter
Phillip Webb
arefbehboudi
Andy Wilkinson
Scott Frederick
rajin
Ahmed Ashour
yokotaso
Johnny Lim
_ext Slovak, Jiri
Piyal Ahmed
Tobias Lippert
Christoph Dreis
Yanming Zhou