v4.8.94December 10, 2020
v4.8.93 ChangesDecember 02, 2020
A few changes to classloading:
.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
MyClasswas itself loaded by
ClassGraphin 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
ClassGraphClassLoaderinstance from the outer scan, and if that fails, then the inner scan's
ClassGraphClassLoaderwill 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.)
v4.8.92 ChangesNovember 28, 2020
🚀 Small update to previous release: strip final slash from URIs that end in an automatic package prefix, i.e.
!/BOOT-INF/classes/ -> !/BOOT-INF/classes
v4.8.91 ChangesNovember 28, 2020
➕ Added automatic package roots to classpath element URIs, e.g. for Spring-Boot applications. Previously if you called
ClassGraph#getClasspathElementURIs(), you would get the URI for the Spring-Boot jar, rather than that URI with
Thanks to Giuseppe Navato for the report.
v4.8.90 ChangesSeptember 09, 2020
v4.8.89 ChangesAugust 26, 2020
➕ Added the ability to filter classpath elements by URL, using
v4.8.88 ChangesAugust 24, 2020
🛠 Fixed issue where
+characters were mistakenly being replaced with spaces in classpath URLs, due to a longstanding JDK bug that the JDK team is never going to fix. (#468, thanks to @adelel1 for reporting)
v4.8.87 ChangesJune 23, 2020
Construtor<?>instances for constructor methods. (#447, thanks to @Thomas-Langer for the request.)
v4.8.86 ChangesJune 12, 2020
✅ In solidarity with worldwide protests demanding an end to racial injustice and racism, all methods of ClassGraph containing the words "whitelist" and "blacklist" have been renamed to instead use the words "accept" and "reject" respectively. (The old methods are still in place for compatibility, but they have been marked as deprecated.)
Some may object to this change as an over-sensitization or racialization of terms that were never inherently racial in nature. The terms "whitelist" or "blacklist" may not bring to mind racially-oriented connotations to many people. However, these terms originated in a time when the very words "white" and "black" had even stronger discriminatory connotations than they have now:
From https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6148600/ :
In this context, it is worth examining the origins of the term “blacklist” from the Douglas Harper Etymology Dictionary, which states that its origin and history is:
✅ > also black-list, black list, “list of persons who have incurred suspicion,” 1610s, from black (adj.), here indicative of disgrace, censure, punishment (attested from 1590s, in black book) + list (n.). Specifically of employers’ list of workers considered troublesome (usually for union activity) is from 1888. As a verb, from 1718. Related: Blacklisted; blacklisting.
It is notable that the first recorded use of the term occurs at the time of mass enslavement and forced deportation of Africans to work in European-held colonies in the Americas.
👀 May we soon see concrete progress towards a world free of racism, prejudice and injustice.
-- Luke Hutchison (ClassGraph creator and maintainer)
v4.8.85 ChangesJune 10, 2020
🛠 Fix a package root prefix duplication issue with Spring Boot executable jars (#435, thanks to @michael-simons for reporting).