Speed up layer lookups when extracting a layered jar

[JunggiKim]

IndexedLayers.getLayer() is called once for every entry of a layered jar while java -Djarmode=tools extract unpacks it, and each call walks layers.idx from the top:

for (Map.Entry<String, List<String>> entry : this.layers.entrySet()) {
	for (String candidate : entry.getValue()) {
		if (candidate.equals(name) || (candidate.endsWith("/") && name.startsWith(candidate))) {
			return entry.getKey();
		}
	}
}

That makes extraction O(entries x index size). The layout of the index makes it worse than the formula suggests: dependencies are listed one line per jar and come first, while the application classes are covered by a single BOOT-INF/classes/ entry near the end. The most numerous entries therefore consistently scan the longest — for a 700 dependency jar every application class walks past all 700 dependency lines before reaching the line that matches it.

This indexes the candidates once, when the index file is read, splitting them by kind:

• names that do not end in / go into a HashMap, so a file name is resolved with a single lookup
• names that end in / go into a LinkedHashMap that preserves index order, so only the handful of directory candidates has to be scanned

candidate.endsWith("/") is now evaluated once per index line instead of once per lookup.

Measurements

Realistic indexes and entry lists, median of 15 runs after 40 warm-up runs, JDK 25. Comparison counts are deterministic.

Entries	Dependencies	Before	After	String comparisons
903	80	0.76ms	0.05ms	70,612 → 2,426
4,173	250	5.36ms	0.13ms	1,019,857 → 11,896
24,823	700	106.92ms	2.51ms	17,179,582 → 72,946

The absolute saving is around 100ms on the largest jar, so this is not something most builds will notice. The point is that the cost stops growing with the product of jar size and index size.

Behaviour

Lookups resolve to the same layer as before.

The only reordering is that exact file names are now consulted before directory prefixes, where previously both kinds were interleaved in index order. That cannot change an answer, because LayersIndex.Node.buildIndex only writes a name once its whole subtree belongs to a single layer and otherwise recurses into the children. No indexed name can therefore be a prefix of another indexed name, and at most one candidate can match any given entry.

putIfAbsent keeps the first occurrence of a repeated name, matching the first-match-wins behaviour of the loop it replaces.

Verified with:

• the existing IndexedLayersTests, unchanged, plus one added test covering a name that appears in more than one layer. That test passes against the current implementation as well, so it is a regression guard rather than a new expectation
• a differential harness running both implementations side by side over randomly generated indexes — 218,963 lookups, including the thrown IllegalStateException messages, with no differences
• ./gradlew :loader:spring-boot-jarmode-tools:test checkFormatMain checkFormatTest checkstyleMain checkstyleTest — 95 tests, no format or Checkstyle violations