A change in Quarkus 3.16 broke ClassGraph

[triceo]

Hey everyone,

I recently filed this ClassGraph issue. (Not filing a Quarkus issue, because this is a downstream problem.)
The problem is that ClassGraph is accessing the elements field of the Quarkus classloader, which no longer seems available.

However, I would like to understand what changed, and what would be the preferred approach for ClassGraph to take to address this. I'm assuming that depending on the internals of Quarkus classloader is a bad thing.

Perhaps the classloader working group may be able to give some context?

[dmlloyd]

Correct, depending on internals is a losing strategy. The correct thing to do would be to use supported APIs. In order to provide such an API we would need information about what is needed and why.

[triceo]

This comes transitively from webjars-locator. It uses ClassGraph to figure out which webjars are on the classpath, and ClassGraph has special handling for Quarkus.

My app uses the webjars-locator, because it needs to work both in plain Java and with Quarkus.
What this bug means is that the app works perfectly outside of Quarkus (and on Quarkus 3.15 and older), but fails on 3.16 where the Quarkus classloader changed.

It seems like the easiest way for me to go forward here would be to avoid using the webjars-locator and do the webjar extraction on my own - that would work equally well in both plain Java and in Quarkus, because I would be ignoring the existence of Quarkus altogether.

[dmlloyd]

When you say "outside of Quarkus" I think it would be more accurate to say "only in environments that happen to use a URLClassLoader-based class loader". Just to make it abundantly clear, programs which depend on non-public implementation details of the environment are already broken, even if they seem to work in some cases. This can be frustrating to the end user but no project should reasonably be expected to maintain internal implementation details in order for a downstream project to continue working. The onus would be on the downstream project to use (or request) supported APIs to satisfy the use case.

That said, avoiding the webjars-locator could be part of a successful strategy. Enhancing it (or requesting it to be enhanced) to support a wider variety of run time environments could also be a good strategy.

[lukehutch]

@dnlloyd let's make the conversation more helpful then. What is the correct public API to get the classpath from the new Quarkus classloader? If it doesn't have one, where is the classpath stored non-publicly in the classloader?

ClassGraph only depends on non-public APIs when it has to. Java does not specify that a classloader has to provide a way for a caller to get its classpath. However all classloaders really need to make this information public, because it is legitimately useful information, and this information is critical when Java also does not provide a class metadata scanning API (which is why ClassGraph is needed).

[gsmet]

@lukehutch I posted in the ClassGraph issue, let's try to make progress there: classgraph/classgraph#891 .

[cescoffier]

\CC @dmlloyd

I think elements was part of the URL Classloader class.

[Foobartender]

By the way, there is a previous discussion about the same underlying issue: #23312.

I need to get a list of all classes with a particular annotation within my project (i.e. not in its dependencies) and then initialize a library with it. What would be the best approach in Quarkus, ideally during build time?

[gsmet]

@Foobartender during build time, the idea is to create a Quarkus extension and to get the Jandex index (using CombinedIndexBuildItem) injected in a @BuildStep method.

Then you can just ask the index for all classes with a particular annotation... but the index only contains what's indexed i.e. not all dependencies will get indexed. You can configure it though and ask for additional indexing if needed.

Not sure how familiar you are with Quarkus and what you want to achieve and if this will help you.

[gsmet]

@triceo I see your use case is related to webjar-locator. In Quarkus, we have https://quarkus.io/guides/web-dependency-locator that is a bit more tied to how Quarkus works. Is there something you are missing in this Quarkus extension and a reason why you are using webjar-locator?

[triceo]

Timefold Solver is a library that has to work with and without Quarkus on the classpath. (We also support Spring Boot, and plain old standalone Java.) Therefore for this functionality, I can not rely on Quarkus.

[triceo]

For the record: I have already fixed the issue on my end, by not relying on the webjars-locator either.