ClassGraph v4.8.93 Release Notes

Release Date: 2020-12-02 // over 3 years ago
  • A few changes to classloading:

    1. If .overrideClassLoaders(...) or .overrideClasspath(...) is called before .scan(), then only the overrides are used (ClassGraph will not fall back to trying any other known classloaders). This might break things for some users, but it matches the expectation that should have been conveyed by the API. 🚀 2. If you run a scan inside a scan, and you call .overrideClassLoaders(MyClass.class.getClassLoader()), where MyClass was itself loaded by ClassGraph in the outer scan, using scanResult.getClassInfo("mypackage.MyClass").loadClass(), then the override classloader is actually an instance of ClassGraphClassLoader. This was not supported before, but it supported now as of this release. If you use this, then any classloading in the inner scan will first try loading classes with the ClassGraphClassLoader instance from the outer scan, and if that fails, then the inner scan's ClassGraphClassLoader will be tried. This is to allow for classes to be compatible between the outer scan and the inner scan, in cases where both scans find the same classes. (Classes that are identical but were loaded by different classloaders are not seen by the JRE as being the same class.) (#485, thanks to @TheSpiritXIII for the bug report.)