LayersIndex.Node kept its children in a list and scanned that list
linearly to find the child for each path segment. Building the index is
therefore O(entries x siblings), a cost that is dominated by the largest
flat directory in the jar: BOOT-INF/lib/ for the dependencies, and any
bundled resource directory such as a front-end build output.
Keep the children in a LinkedHashMap keyed by the segment name so that
lookups are constant time. Insertion order is preserved, so the order in
which buildIndex() walks the tree is unchanged.
For a jar with 32,529 entries, 426 dependencies and a 12,000 file static
resource directory, this reduces the number of string comparisons from
73.7M to 222K and the time spent building the index from 197ms to 12ms.
For a jar with no large flat directory (20,529 entries, 426
dependencies) the gain is much smaller: 1.58M comparisons to 162K, and
12.5ms to 9.6ms. The generated layers.idx is byte for byte identical in
both cases.
See gh-51654
Signed-off-by: Junggi Kim <kimjg2477@gmail.com>
Packager#isCycloneDxBom only recognized CycloneDX SBOMs beneath
META-INF/sbom/. In a war, the CycloneDX Maven plugin's output is
packaged beneath WEB-INF/classes/META-INF/sbom/, so repackaging did
not add the SBOM manifest attributes.
Also check beneath Layout#getClassesLocation(), which findMainMethod
already uses to locate application classes. Continue to support the
root location used by jars.
Signed-off-by: COBI-98 <tkdgus968@naver.com>
See gh-51551
In BootZipCopyAction and AbstractJarWriter, SHA-1 hash is calculated for
stored entries requiring unpack and set as entry comment. However, the
hash isn't used anywhere, just the marker prefix 'UNPACK:' is checked.
This commit removes the unnecessary SHA-1 hash calculation which reads
the file completely in memory, potentially three times in extreme cases.
Now the comment is simply set to 'UNPACK:' without any hash, improving
performance.
See gh-46520
Signed-off-by: Hyunjoon Choi <hyunjoon@example.com>
Signed-off-by: academey <academey@gmail.com>