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 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
Update the performance improvements to push certificate loading
and storage into the `JarFileEntries` class. This allows us to
keep certificates without needing to cache all entry data. We
now also keep certificates and code signers in a dedicated class
which is set whenever the full jar stream as been read, even if
the contained values are `null`. The logic that assumes META-INF
entries are not signed has been removed in favor of delegating to
the streamed entry results.
See gh-19041
Update Spring Boot nested JarFile support to improve the performance of
signed jars. Prior to this commit, `certificates` and `codeSigners`
were read by streaming the entire jar whenever the existing values
were `null`. Unfortunately, the contract for `getCertificates` and
get `getCodeSigners` states that `null` is a valid return value. This
meant that full jar streaming would occur whenever either method was
called on an entry that had no result. The problem was further
exacerbated by the fact that entries might not be cached.
See gh-19041
Previously, PropertiesLauncher would close each archive that it
iterated over when creating its ClassLoader. This was not aligned
with JarLauncher's behaviour and left the ClassLoader with closed
archives. The close was introduced in [1] and became more apparent
following the change to fail operations on closed archives [2].
This commit updates Launcher to remove the close() that was added in
[1]. This aligns the behavior of PropertiesLauncher with JarLauncher
and ensures that the ClassLoader does not have entries backed by
closed archives on its classpath.
Fixes gh-23165
[1] ad72f86bdb
[2] ed7a5db174
Create a new `JarFileWrapper` class so that we can wrap and existing
`JarFile` and offer a version that can be safely closed.
Prior to this commit, we provided wrapper functionality in the `JarFile`
class itself. Unfortunately, because we override `close` and also create
a lot of wrappers this caused memory issues when running on Java 11.
With Java 11 `java.util.zip.ZipFile` class uses `FinalizableResource`
for any implementation that overrides `close()`. This means that any
wrapper classes will not be garbage collected until the JVM finalizer
thread runs.
Closes gh-22991
Update `LaunchedURLClassLoader` so that packages defined from exploded
archive folders have manifest attributes applied to them. Prior to this
calling `package.getImplementationTitle()` would only return the a
manifiest attribute when running non-exploded.
The root cause of this issue is the way that `URLClassLoader` handles
the different URL types. For URLs that reference a jar the manifest is
available. For URLs that reference a folder it isn't. When running
exploded we use a URL that references to the `BOOT-INF/classes` folder
directly. To fix the issue we now attempt to detect when `definePackage`
is being called directly, and replace `null` entries with actual
manifest values.
Fixes gh-21705
Update `JarFile` so that `super.close()` is called early so that the
file is not left open. Since we re-implement `JarFile` methods to work
directly on the underlying `RandomAccessDataFile`, it should be safe
to close immediately.
Closes gh-21177
Update `JarFile` so that `super.close()` is called early so that the
file is not left open. Since we re-implement `JarFile` methods to work
directly on the underlying `RandomAccessDataFile`, it should be safe
to close immediately.
See gh-21126
Update `JarURLConnection` to ensure that when connections are opened
a new copy of the JarFile is provided.
Prior to this commit, a single `JarFile` instance was shared which meant
that it could be accidental closed if accessed via
`JarURLConnection.getJarFile()`. If the underlying jar file is closed
then it's possible for a `NoClassDefFoundError` to be thrown if running
on JDK 11 with an active `SecurityManager`.
Closes gh-17796
Update the `Launcher` class to allow a packaged jar to be launched in
a different mode. The launcher now checks for a `jarmode` property and
attempts to find a `JarMode` implementation using the standard
`spring.factories` mechanism.
Closes gh-19848
Update the `Repackager` class so that an additional `classpath.idx` file
is written into the jar that provides the original order of the
classpath. The `JarLauncher` class now uses this file when running as
an exploded archive to ensure that the classpath order is the same as
when running from the far jar.
Closes gh-9128
Co-authored-by: Phillip Webb <pwebb@pivotal.io>
The JarFile was not being closed which linked a file handle and caused
a test failure on Windows.
The local variable has been renamed as, when declared in a
try-with-resources, Checkstyle was confused by the shadowing of the
jarFile field and required references to jarFile within the try-block
the be prefixed with this.
See gh-19595
Andy Wilkinson
dreis2211
weixsun
Stephane Nicoll
Phillip Webb
mathieufortin01
Andy Wilkinson
Phillip Webb
Johnny Lim
Madhura Bhave
Stephane Nicoll