build(deps): Bump io.github.classgraph:classgraph from 4.8.193 to 4.8.194

[dependabot]

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

Release notes

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

ClassGraph 4.8.194

ClassGraph 5.0.0 is coming shortly, and requires JDK 17 or newer. 4.8.194 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 through 4.8.193. 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 theme this time is the order in which scan sources are searched: which classloader's copy of a class wins, where the application classpath sits in that order, and how module layers are traversed. There is also a fix for a scan that never returns.

Bug fixes: deadlock

• A scan started from a thread holding a classloader lock never returned (#933). scan() and scan(int) submitted the Scanner to an ExecutorService and blocked the calling thread on the Future, so the first classes the scan needed were loaded on a worker thread. If the calling thread held a lock that the classloader also acquires — not unusual during a host's startup, as in Fabric/Knot — the worker blocked in ClassLoader.loadClass while the caller waited for it, and neither ever moved. Neither side of that cycle is a monitor that both threads contend for, so the JVM did not report it as a deadlock either, and jstack showed nothing wrong. The Scanner now runs on the calling thread; the ExecutorService is still used for the parallel stages of the scan, and is not used at all when numParallelTasks is 1, so scan(1) now loads every class it needs on the calling thread and cannot deadlock that way. scanAsync() is unchanged, since running on a pool thread is its purpose.

Bug fixes: classpath and classloader order

• A classloader could be ordered behind its own ancestors. The list of classloaders found in the environment was seeded with the thread context classloader, ClassGraph's own classloader and the system classloader before the call stack was read, so an ancestor could be placed ahead of the descendant that actually called ClassGraph. Only the position of the first classloader of a delegation chain to be reached is decided by that list — once a classloader is reached, its ClassLoaderHandler decides where its ancestors' classpath elements go relative to its own — so pinning an ancestor first silently converted parent-last delegation, the default for Tomcat's WebappClassLoader and for Spring Boot DevTools' RestartClassLoader, into parent-first delegation, inverting the class masking order. The classloaders found in the environment are now sorted by descending delegation depth, which cannot place an ancestor ahead of one of its descendants, and the call stack is read innermost frame first, so the immediate caller's classloader is preferred over that of the code that called it, mirroring how Class.forName(String) resolves against its immediate caller. Classloaders added with addClassLoader() are still appended after them, as that method documents.

• The application classpath was searched after the classloaders that delegate to it. The java.class.path entries were appended after every classloader had been visited, which inverts the masking order: a class present both on the application classpath and in a child classloader was reported from the child, whereas parent-first delegation makes the JVM load the application classloader's copy. Those entries are now contributed by the handler for the application classloader, so they land at the position the application classloader takes in the delegation order, like any other classloader's entries. This also makes ignoreParentClassLoaders() behave as its documentation says: it now leaves out only the entries that a parent classloader declares, instead of also dropping the application classloader's own entries when the application classloader is itself one of the classloaders being searched.

• A module layer reachable from more than one named layer was listed more than once, and the resulting order then depended on which layers the caller happened to name rather than on the layer DAG alone. Naming a parent layer and its child, in either order, gave the same result — the child first — so asking for the parent's modules to be searched first had no effect. The visited set is now shared across all top-level layers, so a layer named directly keeps the position its own name gives it, and is reached indirectly through ModuleLayer#parents() only if the caller did not name it. The javadoc now also states why a layer's own modules come before its parent layers': the classloader a layer creates is a jdk.internal.loader.Loader, whose loadClass checks this layer's own modules before the parent layers' and before its parent classloader — the reverse of the classloader axis, and observable, since a child layer may define a module with the same name as one in a parent layer and the child's copy then wins.

• Six ClassLoaderHandlers were missing classpath entries that their classloaders expose. An audit of the source of every supported classloader turned these up; nothing that was already read has been removed, since a field or method absent from the current source may still be present in an older version. Uno-JAR also accepts extra entries in the uno-jar.class.path system property, separated by |. A JBoss ResourceLoader that wraps another one, such as a FilteredResourceLoader, exposes only the location of the loader it delegates to. An Equinox BundleFileWrapper installed by a framework extension copies only the base file of the bundle file it wraps, so without following its bundleFile field the sub-path within the bundle is lost. A Felix Content with no file of its own delegates to the Content in its m_content field. The bundle file of an older Equinox classpath entry can be a nested directory or a wrapper chain, exactly as in newer versions, and the bundle's fragments have classpath entries of their own. A WebSphere Liberty AppClassLoader delegates to the classloaders of its configured libraries, split by precedence into beforeAppDelegateLoaders and afterAppDelegateLoaders, and a ThreadContextClassLoader searches the classloaders in followOnClassLoaders after its parent.

Bug fixes: resource paths

• A package root within a jarfile was separated from a resource path with !/ rather than /. A classpath entry can name a package root within a jarfile, e.g. app.jar!/BOOT-INF, and Resource#getURI() appended !/ between the URI of the classpath element and the path of the resource within it, giving app.jar!/BOOT-INF!/classes/hello/HelloController.class — a URL with two !/ separators but only one archive in it, which does not resolve. A package root is a directory within the jarfile, not a jarfile nested inside it, so a resource beneath it is separated from it by /. The default automatic package root prefixes masked this for the paths they cover.

Bug fixes: classfile parsing

• A class using the JVMS-specified encoding of a Class-valued annotation element vanished from scan results. JVMS 4.7.16.1 specifies that the class_info_index of a tag c annotation element value refers to a CONSTANT_Class entry, but javac writes the type descriptor directly as a CONSTANT_Utf8 entry instead, which is what AnnotationClassRef expects. With a classfile that follows the spec to the letter, the binary class name failed to parse as a descriptor and the whole class was silently dropped. CONSTANT_Class references are now converted to type descriptors, and UTF8 constants are passed through unchanged.

• Mixing RUNTIME- and CLASS-retention type-use annotations on one declaration dropped all the RUNTIME ones. javac emits both the RuntimeVisibleTypeAnnotations and RuntimeInvisibleTypeAnnotations attributes on the same target in that case, and the field, method and class attribute readers each overwrote the decorators of the first attribute with those of the second. The two lists are now merged.

• A constant declared by an implemented interface could not be found through an implementing class. The reflection driver's member cache walked the superclass chain caching declared methods and fields, then walked the interface graph caching only declared methods. Both kinds are now cached at both traversal sites, and methods and fields are read in separate try blocks, so a class whose fields cannot be read still has its methods cached, and vice versa.

Behaviour changes

• ClassInfo#toString() now names only the class in an extends or implements clause, as Java source does. It previously rendered a superclass or superinterface with its own modifiers, class type keyword and extends/implements clauses, producing output that is not a Java declaration:

  public static class Child extends public abstract static Parent extends java.lang.Exception implements public abstract static Marker implements public abstract static Tag
  

  The named class's modifiers, class type, type parameters, record parameters and supertypes all belong to its own declaration. This changes toString() output for any class whose supertypes have supertypes or modifiers of their own.

Dependencies and documentation

• Narcissus updated to 1.0.13, which adds a native library for Linux on arm64, so ClassGraph can read the classpath through Narcissus on that platform too.

• The README and the CIRCUMVENT_ENCAPSULATION javadoc listed the wrong set of platforms Narcissus supports: there have been no 32-bit x86 builds for a long time, and Linux arm64 and macOS arm64 were missing.

Commits

• 4ac0a76 [maven-release-plugin] prepare release classgraph-4.8.194
• 3b37a81 Run a blocking scan on the calling thread
• ff10ce4 Name only the class in an extends or implements clause
• fbe7127 Put the application classloader's classpath entries in their proper place
• 4e090c9 Order a classloader ahead of its own ancestors when finding scan sources
• ade5186 List each module layer once, in the order its own loader searches
• 68fceaa Separate a package root from a resource path with '/', not '!/'
• b07d80f Read the classpath entries that six ClassLoaderHandlers were missing
• 89bdb8a Handle the JVMS-specified encoding of 'c' annotation element values
• 1c2eee6 Merge runtime visible and invisible type annotation attributes
• 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)