The logic to extract layers from a downloaded Docker image assumed that
the layer entries in the image tar archive always had the file extension
`.tar`. This was the case with Docker and other compatible daemons until
Docker 25.0. With this commit, the extension is no longer assumed, but
any entries listed in `manifest.json` will be recognized.
Fixes gh-39323
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
1. remove unused imports
2. remove redundant semicolon
3. remove empty class body
4. remove redundant 'constructor' keyword
5. remove redundant 'Unit' return type
6. use non-null type if possible
See gh-38708
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
