Add a `NestedFileSystemProvider` implementation so that the JDK's
`ZipFileSystem` can load content from nested jars and nested
directory entries.
Creating a `ZipFileSystem` may be a relatively expensive operation as
zip structures need to be parsed and in the case of directory entries
a virtual datablock nees to be generated on the fly. As such, we
install the `ZipFileSystem` as late as possible since in a typical
application it may never be needed.
This commit also tweaks Gradle and Maven plugins to ensure that the
service loader file is written to repackaged jars.
Closes gh-7161
Update Gradle and Maven plugins to write an empty `META-INF/BOOT.SF`
file whenever there is a nested signed jar.
This update allows Oracle Java 17 to correctly verify the nested JARs.
The file is required because `JarVerifier` has code roughly equivalent
to:
if (!jarManifestNameChecked && SharedSecrets
.getJavaUtilZipFileAccess().getManifestName(jf, true) == null) {
throw new JarException("The JCE Provider " + jarURL.toString() +
" is not signed.");
}
The `SharedSecrets.getJavaUtilZipFileAccess().getManifestName(jf, true)`
call ends up in `ZipFile.getManifestName(onlyIfSignatureRelatedFiles)`
which is a private method that we cannot override in our `NestedJarFile`
subclass. By writing an empty `.SF` file we ensure that the `Manifest`
is always returned because there are always "signature related files".
Fixes gh-28837
Rewrite nested jar code to better align with the implementations
provided in Java 17. This update makes two fundamental changes to
the previous implementation:
- Resource cleanup is now handled using the `java.lang.ref.Cleaner`
- Jar URLs now use the form `jar:nested:/my.jar/!nested.jar!/entry`
Unlike the previous `jar:jar:/my,jar!/nested.jar!/entry` URL format,
the new format is compatible with Java's default Jar URL handler.
Specifically, it now only uses a single `jar:` prefix and it no longer
includes multiple `!/` separators.
In addition to the changes above, many of the ancillary classes have
also been refactored and updated to create cleaner APIs.
Closes gh-37668
Create alternative launcher classes under the package
`org.springframework.boot.loader.launch` and use them in favor
of the previous location.
This update is designed to improve compatibility with future
changes in the loader.
Closes gh-37667
Accessing bind mount directories as is done in the tests for building
images with bind mount caches requires Docker configuration when
using Docker Desktop. It works without configuration on Linux with
Docker Engine.
See gh-28387
When building an image using the Maven `spring-boot:build-image` goal or
the Gradle `bootBuildImage` task, the build and launch caches can be
configured to use a bind mount as an alternative to using a named
volume.
Closes gh-28387
This reverts commit 6506208d29. The
upgrade to the Jammy builder was causing
failsWhenBuildImageIsInvokedOnMultiModuleProjectWithBuildImageGoal to
hang on CI.
See gh-36689
Configuration files managed by the Docker CLI are now used to determine
the host address of the Docker daemon used when building images using
buildpacks when a host address is not configured with environment
variables or build tool plugin configuration.
Closes gh-36445
Gradle 7.3.3 does not support Java 20 so the test that verifies that
the plugin fails fast when running on a version of Gradle that it
does not support needs to be disabled on Java 20 and later.
See gh-35931
Andy Wilkinson
Phillip Webb
Scott Frederick
Fouad Almalki
Yanming Zhou
Stephane Nicoll
Moritz Halbritter
Johnny Lim