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
Relax the constraint that a `NestedLocation` must have a nested entry
name specified so that URLs can be split and rebuilt.
Prior to this commit, given a URL of the following form:
jar:nested:/myjar.jar!/nested.jar!/my/file
It was possible to create a FileSystem from
"jar:nested:/myjar.jar!/nested.jar" and from that create a path to
"my/file".
However, it wasn't possible to create a FileSystem from
"jar:nested:/myjar.jar", then create another file system from the path
"nested.jar" and then finally create a path to "/nested.jar".
This was because `nested:/myjar.jar` was not considered a value URL
because it didn't include a nested entry name.
Projects such as `JobRunr` were relying on the ability to compose file
systems, so it makes sense to remove our somewhat artificial
restriction.
Fixes gh-38592
Update `NestedByteChannel.read` so that it loops until all
remaining data has been read into the buffer. Prior to this
commit, it was possible for to read only some bytes into the
buffer. Although it looks like this should be OK according to
the API documentation, the `ZipFileSystem` relies on all
remaining bytes being returned.
Fixes gh-38595
Update `ZipContent` so that `eocd.totalNumberOfCentralDirectoryEntries`
is converted from a short to an unsigned int to prevent a negative
number from being used.
This commit also updates the code to consistently use `X.toUnsigned...`
helper methods rather than using bitwise operators.
Fixed gh-38572
Update jar `Handler` code so that the `parseUrl` method can accept an
empty `spec`. Prior to this commit, a `classLoader.getResource("")`
call would result in a `null` result. This breaks a number of things
including `ClassPathResource` and `PathMatchingResourcePatternResolver`.
Fixes gh-38524
Update `JarUrlConnection` and `NestedUrlConnection` so that calls
to `getLastModified()` and `getHeaderFieldDate("last-modified", 0)`
always return a result.
Fixes gh-38204
When an interrupted that calls FileChannel.read, the channel is
closed and the read fails with a ClosedByInterruptException. The
closure of the channel makes it unusable by other threads. To
allow other threads to read from the data block, this commit
recreates the FileChannel when a read fails on an interrupted
thread with a ClosedByInterruptException. The exception is then
rethrown to continue the thread's interruption.
Closes gh-38154
Previously, the .class file for the renamed properties class was
on the class path of the compilation in two places:
1. The output directory of the test's previous compilation
2. The output directory of the compilation of src/test/java of
spring-boot-configuration-processor
The first of these locations is addressed by updating TestProject.
The .class file is now deleted from the project's output location
at the same time as the .java file is deleted from its source
location.
The second of these locations is addressed by configuring the class
path of the compiler to include a copy of the result of compiling
src/test/java of spring-boot-configuration-processor. From this copy
entries can then be deleted as needed without destabilizing other tests.
Closes gh-26271
Fix issues with `DataBlockInputStream` including the fact that remain
bytes were not tracked correctly. Also add some tests and fix a few
other unusual details with the implementation.
Closes gh-38066
Update JarUrlConnection so that the full raw zip data is returned from
nested jars when no entry name is specified. This update allows
Tomcat's `WarURLConnection` to work with our nested connections since
they can parse the returned raw zip data.
Fixes gh-38047
The zip specification states that when 'bit 3' of the general purpose
flags is set then a data descriptor record must be present. Prior to
this commit, our `VirtualZipDataBlock` ignored such records and would
create invalid data.
Although the generated data would work for zip parsers that read the
central directory records, it causes problems with streaming reader
implementations such as `JarInputStream`.
This commit updates the code so that it now copies the data descriptor
records. It support both blocks that have a signature and those that
don't. It also updates the generation logic to correctly deal with
any extra data bytes present after the local file header record.
Fixes gh-38063
Update `UrlJarFileFactory` so that `runtimeVersion` is used by default
instead of `baseVersion`. Prior to this commit we tried to mirror the
JDK handler on look for a `#runtime` fragment. This unfortunately
doesn't work with the URLs produced by `URLClassPath`.
This commit also fixes a bug in `NestedJarFile` where we didn't return
the correct result from `hasEntry`.
Fixes gh-38050
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
Update `DefaultCleanerTracking` and `@AssertFileChannelDataBlocksClosed`
to capture and store the source object if it is a `Cleanable` so that
it can be released later.
Although the real cleaner cannot keep a reference to `obj`, it is safe
for us to do so in tests since we are in control of the object lifecycle
and we don't need it to be garbage collected.
This commit also updates the `UrlJarFile` to call the cleaner so that
it can be tracked.
See gh-37668
Update `NestedJarFile.close()` to call `super.close()` so that the outer
jar file is closed and files can hopefully be deleted on Windows.
See gh-37668
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🫙/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
The default socket timeout with HttpClient 5 is not long enough
in some cases where Docker images are built that require the
GraalVM native image compiler to run in a buildpack. This commit
increases the timeout to 30 minutes.
Fixes gh-37665
Co-authored-by: Scott Frederick <sfrederick@vmware.com>"
Prior to this change, this test would create files in the project
directory. This can cause issues with Gradle caching and up-to-date
checks.
To address this, the value of the working directory is mocked to a
temporary directory like all the other tests.
See gh-37395
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
Update `PrivateKeyParser` implementations so that algorithm parameters
for PEM encoded 'EC PRIVATE KEY' files are loaded from the incoming
data.
Prior to this commit, the algorithm parameter was hard-coded to
'secp384r1' which could result in a mismatch to the actual file
content.
Fixes gh-34232
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
This clarifies what used to be called "directories" as both a directory
and a jar file can be provided. A directory with `/*` would also load
all the jar files from that directory.
The "directories" property has been deprecated as a result.
Closes gh-35179
- Replace synchronized with Lock when guarding long-running operations
- Remove unnecessary synchronization in FileSystemWatcher
- Replace HashMap with ConcurrentHashMap in Restarter
- Remove unnecessary locking on AtomicBoolean in
SpringApplicationBuilder
- Remove unnecessary locking in SimpleFormatter
Closes gh-36670
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
Previously, we tried to prevent spring-boot-docker-compose from
causing problems with AOT and native images by excluding it from
the AOT processing classpath. This allowed AOT processing to
succeed. We cannot apply the same exclusion to the native image
classpath so spring-boot-docker-compose was still included in the
native image. This results in a failure at runtime due to missing
reflection hints.
This commit reverts that changes that excluded
spring-boot-docker-compose from the AOT processing classpath. This
allows AOT processing to generate reflection hints but reintroduces
the failure caused by the connection details bean definitions using
an instance supplier callback. To overcome this problem we disable
DockerComposeLifecycleManager during AOT processing and in a native
image. This ensures that no attempt is made to call docker compose up
and no connection details beans are defined.
Fixes gh-35676
When excluded from the AOT processing classpath, a reflection hint
for DevTools' RestartScopeInitializer that's registered in
spring.factories is not generated. When the native image is compiled
we have no control over its classpath so DevTools is included. This
causes a failure at runtime as RestartScopeInitializer cannot be
loaded due to the missing reflection hint.
Until we have control over the native image classpath, we need to
include DevTools on the AOT processing classpath and then rely on
DevTools disabling itself in a native image which it already does.
Fixes gh-35853
This commit also disables the creation of forward merge issues
when merging into main. Forward merge issues will be re-enabled
once 3.1.1 has been released.
