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
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 `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
- 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
Update `JarFile` so that the `close()` method no longer closes nested
jars or the wrapper. Prior to this commit it was possible for a parent
jar file to be garbage collected and closed even though references still
existed to the nested jars. When this happened the nested jars would get
closed and any access to entries would result in `JarFile.ensureOpen()`
throwing an `IllegalStateException`. The user would often not see this
exception directly, but rather find `ClassNotFoundException` being
thrown.
Fixes gh-31853
Update `JarFile` and related classes so that `close()` is not longer
called early.
Prior to this commit, we would always immediately close the underlying
jar file to prevent file locking issues with our build. This causes
issues on certain JVMs when they attempt to verify a signed jar.
The file lock issues have now been solved by returning a custom input
stream from `JarUrlConnection` which captures and delegates the close
method.
Fixes gh-29356
Update the Maven and Gradle packaging for war files so that a
`classpath.idx` file is written into the archive that provides the
original order of the classpath, as was previously done for jar files.
The `WarLauncher` class will use this file when running as an exploded
archive to ensure that the classpath order is the same as when running
from the far war.
Fixes gh-19875
Update `JarURLConnection` to use a single shared wrapper per
jar file rather than creating a new one each time. This update
should help to reduce GC pressure.
Fixes gh-28042
Previously, a Zip64 jar file was identified by the number of entries
in the central directory being 0xFFFF. This value indicates that
there the number of entries is too big for the 2-byte field. However,
a jar may be in Zip64 format due to it exceeding the Zip format's
maximum size rather than its maximum number of entries so this field
cannot be used as a reliable indicator. The Zip specification doesn't
require any of the fields of the end of central directory record to
have a value of 0xFFFF (2-byte fields) or 0xFFFFFFFF (4-byte fields)
when using Zip64 format so we need to take a different approach.
Additionally, a number of places in the code assumed that an entry's
offset would always be available from the central directory file
header directly. This assumption did not hold true when the jar was
a Zip64 archive due to its size as the offset's value would be
0xFFFFFFF indicating that it should be read from the Zip64 extended
information field within the header's extra field instead.
This commit updates the Zip64 detection to look for the Zip64 end of
central directory locator instead. If present, it begins 20 bytes
before the beginning of the end of central directory record. Its
first four bytes are always 0x07064b50. The code that reads the
local header offset has also been updated to refer to the Zip64
extended information field when the offset is too large to fit in
the 4-byte field in the central directory file header. To allow
greater-than-4-byte offsets to be handled, a number of fields,
method parameters, and local variables have had their type changed
from an int to a long.
Fixes gh-27822
Update `JarFile` and `JarFileWrapper` classes so that they no longer
close the `JarFile` early if a `SecurityManager` is in use.
Prior to this commit, the closed `JarFile` would cause (an ultimately
swallowed) NPE in `ZipFile` which manifested itself as a
`ClassNotFoundException` when starting the app.
Closes gh-25538
Update `build.gradle` files to ensure that `junit-platform-launcher` is
a `testRuntimeOnly` dependency. This ensures that tests can be run from
Eclipse.
Closes gh-25074
Update jar `Handler` fallback logic to directly support Tomcat
'jar:war:file' URLs. This commit allows contents to be accessed without
the JDK needing to extracted the nested jar to the temporary folder.
Closes gh-24553
Update the jar `Handler` class to support a non-reflective fallback
mechanism when possible. The updated code attempts to capture a regular
jar URL before our handler is installed. It can then use that URL as
context when creating the a fallback URL. The JDK jar `Handler` will
be copied from the context URL to the fallback URL.
Without this commit, resolving new Tomcat URLs of the form
`jar:war:file:...` would result in an ugly "Illegal reflective access"
warning.
Fixes gh-18631
Phillip Webb
Andy Wilkinson
Moritz Halbritter
Krzysztof Krason
Scott Frederick
Johnny Lim
aoyvx
Marc Wrobel
dreis2211
Lars Grefer
Gnaily
Stephane Nicoll
Yanming Zhou
Leo Li
weixsun