build(deps-dev): bump io.github.classgraph:classgraph from 4.8.194 to 4.8.195

[dependabot]

Bumps io.github.classgraph:classgraph from 4.8.194 to 4.8.195.

Release notes

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

ClassGraph 4.8.195

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

The themes this time are a scan that can never finish, temporary files that were left behind or misnamed, classpath entries that were silently dropped, and a set of correctness fixes in the class graph itself.

New API

• ClassGraph#setWorkerTimeout(long, TimeUnit). Every Future#get() call in the scanner now has a timeout, so a scan that can never finish reports why instead of hanging. The two known causes are the classloading deadlock of #933, and a worker thread blocking on a filesystem or network read of a classpath element — a stalled HTTP server serving a remote jarfile, for instance. The timeout defaults to one minute, so a scan that previously blocked forever now fails with an exception naming the reason. A timeout of zero or less waits indefinitely, which is the previous behavior.

Bug fixes: scans that never return

• The call stack and the context classloader were read on a worker thread during scanAsync(). The Scanner was constructed inside the task submitted to the ExecutorService, so the call stack that ClassGraph reads to find classloaders, and the thread context classloader it uses, were those of a pool thread rather than of the caller. They are now read on the calling thread, before anything is submitted.

• The #933 fallback now works on Java 8, and covers a classloader as well as a static initializer. If the calling thread holds a class loading lock, loading a class on a worker thread deadlocks the scan, so the whole scan is run on the calling thread whatever number of threads was requested, and the frame holding the lock is named in the verbose log. Where StackWalker is not available, the classes declaring the stack frames are taken from the call stack that was already read, so a frame can be matched to its class without loading anything — which is what must not be done while a class loading lock is held.

Bug fixes: temporary files

• A jarfile whose name contains --- was scanned under a truncated name. ClassGraph names the files it extracts ClassGraph--<random>---<name>, and leafName() treated --- anywhere in a path as that separator. A jarfile genuinely named x---y.jar was therefore reported as y.jar, and that truncated name is what accept and reject criteria are matched against. Worse, a --- in a path inside a jarfile falls after the end of the leafname, so the leafname came back empty and the jar matched no criterion at all and was silently skipped. The separator is now only honored in a leafname that starts with ClassGraph--, and only at the first separator after that prefix.

• A temporary file that was still memory mapped at the end of a scan was left on disk for the life of the JVM. Below JDK 22 a mapping is dropped by freeing its address range, which cannot be done while the caller can still read a buffer of it, so a file held open by such a view stays mapped after the scan closes. Windows refuses to delete a mapped file, and the retry that closing the scan makes after asking for a garbage collection cannot help either, since the buffer the caller holds is strongly reachable. The file is now deleted when the last view of its mapping is released, rather than being left to the deleteOnExit() hook.

• A slice or an arena that would not close was not reported. An IOException from a slice that would not close was dropped silently, so a file handle or a mapping that outlived a scan left nothing in the log to explain why a jarfile could not afterwards be deleted or overwritten on Windows; an unchecked failure was not caught at all, and abandoned the rest of the teardown — the slices still to be closed, the inflater recycler, and the temporary files. On JDK 22 and later, an arena that fails to close leaves its file mapped, and that too went unrecorded, so no collection was asked for before the temporary files were deleted.

• Scanning an exploded module leaked an open directory for the life of the JVM. ModuleReader#list() returns a stream that walks the module's directory tree, and closing that stream is what closes the directories the walk opened. It was collected into a list and dropped without being closed.

Bug fixes: classpath elements that were dropped or duplicated

• A nested classpath element was missed when a sibling sorted between it and its parent. findNestedClasspathElements() sorts the classpath elements and walks forward from each looking for elements nested within it, stopping at the first element that is not nested. Every character below / sorts before it, so for the base path /a/classes the sibling /a/classes-extra falls between it and /a/classes/sub: the walk stopped at the sibling, the outer element no longer masked the nested one, and the nested element's resources were reported twice.

• A package root or nested jarfile that exists only under a version prefix could not be found. An entry stored under META-INF/versions/N/ in a multi-release jarfile is served without that prefix, and the base copy it masks is gone from the entry list, so a lookup by the stored name matched nothing: naming app.jar!/WEB-INF/classes on the classpath failed with "Path WEB-INF/classes does not exist in jarfile", and the package root of a war or Spring Boot jar whose classes are versioned was dropped.

• Version prefixes were resolved in a jarfile that is not multi-release. A jarfile is only multi-release if its manifest carries the Multi-Release key; in one that does not, the JVM reads an entry under META-INF/versions/ from the path it is stored under. The prefix was being stripped from every entry as the central directory was read, which is before the manifest has been parsed, so a "versioned" entry masked the base entry of the same path — the scan reported the versioned entry's content under the base entry's path, and did not report the base entry at all.

• A classpath entry whose path a URI cannot hold was dropped entirely. When stripping a package root suffix from a URI or URL entry, the resolved path — which is percent-decoded — was parsed back as a URI, and the entry was discarded when neither the bare path nor the file: spelling parsed. A path containing a space took that branch, as did any Windows path, since a backslash is illegal in a URI. It now degrades to the path string, as the File branch already did.

• A URL that was already percent-encoded was encoded a second time. normalizeURLPath left an http:, https: or jrt: URL alone and then passed it to the encoder written for decoded file paths, so %20 became %2520, the colon before a port number became %3a, and a query string ?v=1&t=2 became %3fv%3d1%26t%3d2 — after which URI#getHost returned null and URI#getPort returned -1, matching nothing that ClassGraph actually fetches. Such a URL is now escaped by a rule that leaves an existing escape alone and encodes only what a URI cannot hold. File paths are unchanged.

Bug fixes: classloader order

• A classloader appeared in the delegation order once per handler that could handle it. More than one ClassLoaderHandler can handle the same classloader — one that a handler recognizes by name may also extend URLClassLoader — and each is asked for the entries it knows how to read, but the classloader itself was added to the order each time.

• Two classloaders that claim to be equal collapsed into one. findDefaultClassLoaders() collected classloaders in a LinkedHashSet, so the classes of the one that was dropped were never scanned. Separately, ClassLoaderOrder deduplicated by identity, as it must, but then kept the order in a map keyed by classloader: adding the second of two equal classloaders replaced the handlers of the first rather than appending, so one of the two dropped out of the order and its entries were never found, and the one left behind ran the other one's handlers. This is not hypothetical — TomEE makes an instance of CxfContainerClassLoader equal to the TomEEWebappClassLoader it delegates to (#515).

Bug fixes: zipfile and classfile reading

• An MS-DOS zip timestamp was read in the default locale's calendar system. The year, month and day of an MS-DOS date are Gregorian, but the conversion built a calendar for the default locale, so under th-TH-u-ca-buddhist or ja-JP-u-ca-japanese an entry timestamped September 2020 was reported as September 1477. Only an entry with no extended timestamp extra field is affected, which is what ZipOutputStream writes when ZipEntry#setTime(long) is the only time that was set.

• A read into a ByteBuffer that carried a limit from a previous read threw IllegalArgumentException. A read leaves the buffer's limit where it stopped, so a later read starting further into the same buffer positioned past that stale limit — not one of the exceptions InputStream.read(byte[], int, int) is allowed to throw for a valid range. Three of the four readers already opened the limit before positioning; ClassfileReader did not, so the same call sequence failed or succeeded depending on where the content was being read from. The file-channel reader reuses one ByteBuffer across array reads, so array reads through it were affected too.

• A stream of unknown length was read into a 64MB buffer. The buffer was allocated at maxBufferedJarRAMSize even for a stream holding a few bytes, and a stream whose length hint understated it was spilled to a temporary file rather than read into a larger buffer. The buffer now starts at the length hint, or 16kB when there is no usable hint, and doubles as it fills. A related fix: InputStream#read is allowed to return zero from a read of a non-empty buffer, and that was being treated as a full buffer, doubling the buffer on every such read until it reached the maximum or spilled to disk.

... (truncated)

Commits

• dac837f [maven-release-plugin] prepare release classgraph-4.8.195
• dc06d6c Assert the deferred temp file delete unconditionally
• fd2735a Run the deferred temporary file delete test on Windows too
• 4b90831 Delete a temporary file whose delete had to wait for the file to be unmapped
• 5688da6 Retry an interrupted SingletonMap creation instead of poisoning the key
• fdadbe2 Don't resolve version prefixes in a jar that is not multi-release
• b965f2c Find a nested classpath entry that exists only under a version prefix
• ad122a1 Never report a rejected resource from getResourcesWithPathIgnoringAccept
• 30423ed Stop discarding the cause of an exception that is rethrown
• 63cd5aa Stop percent-encoding a URL that is already percent-encoded
• Additional commits viewable in compare view

[ferenc-csaky]

@dependabot rebase