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
Update `JarFileEntries` so that the interface is obtained rather than
the concrete implementation. This allows `JarEntry` values to be used
without causing a ClassCastException.
Closes gh-19041
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
Andy Wilkinson
Gnaily
Stephane Nicoll
Yanming Zhou
Scott Frederick
Leo Li
Phillip Webb
dreis2211
weixsun
Santhoshkumar. P
Andy Wilkinson
Stephane Nicoll
mathieufortin01