IndexedLayers.getLayer() walked every entry of layers.idx for each jar
entry being extracted, making extraction O(entries x index size). The
dependency entries are listed first while the application classes are
covered by a single directory entry near the end, so the most numerous
entries consistently scanned the longest.
Index the candidates once when the index file is read, keeping the
directory candidates in a separate map that preserves index order. A
file name is then resolved with a single map lookup and only the
handful of directory candidates has to be scanned.
For a jar with 24,823 entries and 700 dependencies this reduces the
number of string comparisons from 17,179,582 to 72,946 (106.9ms to
2.5ms). With 4,173 entries it goes from 1,019,857 to 11,896 (5.4ms to
0.1ms) and with 903 entries from 70,612 to 2,426 (0.8ms to 0.1ms).
Lookups resolve to the same layer as before. LayersIndex only writes a
name once its whole subtree belongs to a single layer, so no indexed
name is a prefix of another and at most one candidate can match, which
makes the order the two kinds of candidate are consulted in immaterial.
See gh-51653
Signed-off-by: Junggi Kim <kimjg2477@gmail.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Add an 'sbom' command to the tools jar mode which prints the SBOM
packaged in an uber jar or war. The SBOM is located using the
Sbom-Location manifest attribute and its bytes are copied verbatim to
the console, or to the file given by --destination.
See gh-51505
Signed-off-by: Hyeongjun Cho <ryuu.public@gmail.com>
Junggi KimandClaude Opus 5
Andy Wilkinson
Hyunwoo Jung
Manu Sridharan
Moritz Halbritter
Hyeongjun Cho
Phillip Webb
Stéphane Nicoll