Build(deps): bump io.github.classgraph:classgraph from 4.8.184 to 4.8.191

[dependabot]

Bumps io.github.classgraph:classgraph from 4.8.184 to 4.8.191.

Release notes

Sourced from io.github.classgraph:classgraph's releases.

ClassGraph 4.8.191

ClassGraph 5.0.0 is coming shortly, and requires JDK 17 or newer. 4.8.191 is a bugfix release on the 4.x maintenance branch, and continues the file-by-file audit of the codebase that produced 4.8.190. As before, the bugs listed here were found by Claude through careful code analysis, and were fixed on the v5 branch and backported to v4.

Spring Boot 3.2 and later

• A Spring Boot 3.2+ or 4.x executable jar is now scanned. Since 3.2, the Spring Boot launcher addresses an entry inside an executable jar or war using its own nested: URL protocol, which separates the path of the outer archive from the name of the entry within it with /! rather than the standard !/ — for example jar:nested:/path/to/app.jar/!BOOT-INF/lib/dependency.jar!/. Those are the URLs its classloader hands out, so ClassGraph resolved every one of them as a relative file path and found nothing at all: a scan of a Spring Boot 3.2+ executable jar returned zero classes. Such URLs are now converted to the equivalent jar: URL, and a classpath string containing one is no longer split at the nested: scheme's colon.

Behavior changes

• The classpath order no longer depends on the order a filesystem happens to return directory entries in. The jars of an automatic lib directory of a directory classpath element (lib/, BOOT-INF/lib/, WEB-INF/lib/ and the rest) and the JRE's own lib and ext jars are now sorted by filename, so the same JRE and the same application produce the same classpath order on every machine, and which of two jars containing the same class masks the other no longer varies from run to run. Each lib directory is sorted on its own, so the order of the lib directory prefixes still decides which one's jars come first. A dir/* wildcard classpath entry is deliberately left unsorted, because that reproduces the java launcher's own expansion order.

• ScanResult#getPackageInfo() and #getModuleInfo() return sorted lists. They previously returned hashmap iteration order, which varies between runs.

Bug fixes: zipfile reading

• Every zipfile larger than 4 GB was misread. The Zip64 extended information extra field was read as though all of its values are always present, when in fact it carries only the values that overflowed their 32-bit fields, in a fixed order. The fields present are now determined by which of the 32-bit values are set to the overflow marker.

• A zipfile whose comment is longer than 65514 bytes could not be opened. The search for the end-of-central-directory record stopped short of the largest comment the format permits.

• A zip entry whose compressed size runs past the end of the archive threw IllegalArgumentException out of the zipfile reader, rather than being reported as the malformed archive it is. An entry whose Zip64 compressed size overflowed a 64-bit addition was silently read past its end. Both now throw IOException.

• A central directory record declaring an extra field area that extends past the end of the central directory made the whole zipfile unopenable. An empty Info-ZIP Unicode path extra field also made ClassGraph read one byte outside the field. Records are now read strictly within their own bounds.

• A zip entry's Unix timestamp extra field was read as an 8-byte time rather than the 4-byte time the format specifies, so entries written by zip(1), Info-ZIP or Gradle silently fell back to their coarse local-time MS-DOS timestamps.

• A stream that returned zero from two consecutive reads made ClassGraph read a jarfile as empty. A zero-length read is not end of stream.

• A classfile attribute close to 2 GB wrapped the read position negative in ClassfileReader.skip(int).

• The log message "Skipping zip entry with invalid extra field size" claimed an entry was skipped when it was still read.

Bug fixes: resources and file handles

• A jarfile reached through a jar: URL left the outer jarfile open for the life of the JVM.

• A Resource whose open failed with an IOException was left marked as open.

• A module resource that could not be read threw IllegalArgumentException out of Resource#read() and #open(), left the resource marked as open, and leaked the ModuleReader from the recycler. It now throws IOException.

Bug fixes: classpath finding

• A Class-Path manifest entry was resolved incorrectly against a jarfile named by a URL, so jars added that way were not found.

• An unrecognized classloader added one bogus jrt:/<module> classpath element per module of the runtime image — 21 of them on Java 26. When a classloader reports nothing about its own classpath, FallbackClassLoaderHandler asks it for resources at the root of a classpath element and strips the resource path from the URLs. Resources served only by delegation to a parent are skipped, but a classloader with a null parent delegates to the bootstrap classloader, whose resources were never enumerated — so its copy of module-info.class was counted once per runtime module. The bootstrap classloader's resources are now enumerated through a classloader that has none of its own and no parent.

• classpathContentsLastModifiedTime() never changed, however the files changed. It is documented to check the files' current timestamps — the only thing it is useful for — but returned the timestamps recorded during the scan. It now reads the current timestamp of each file, as its companion classpathContentsModifiedSinceScan() always has.

• classpathContentsModifiedSinceScan() reported any directory classpath element as modified as soon as it was scanned, on Java 8. Timestamps of files in a directory classpath element were recorded through the file attributes, while every other timestamp and the comparison itself go through File#lastModified(). On Java 8 the file attributes are truncated to whole seconds, so the two disagreed unless a file's timestamp happened to land on a whole second. Timestamps are now recorded the same way they are compared.

Bug fixes: scanning

... (truncated)

Commits

• ac292fd [maven-release-plugin] prepare release classgraph-4.8.191
• 7493141 Fix a JRE lib jar sorting test that assumed a canonical temp directory
• 4a56491 Scan Spring Boot executable jars addressed by "nested:" URLs
• db01c87 Sort directory listings that feed the classpath into a fixed order
• 7d8eb6d Decode characters outside the Basic Multilingual Plane in a URL path
• 3b415e5 Report a module resource that cannot be read as an IOException
• 49ef126 Leave a resource closed if it could not be opened
• 6e5302f Do not treat a stream that returns zero from a read as an ended stream
• ac83409 Fix a skip of close to 2GB wrapping the classfile read position negative
• 9fd0653 Do not read a central directory record outside its own bounds
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)