Jandex indexing, GraalVM features and runtime classes

[Guillaume Smet]

Hi,

We recently stumbled upon an issue with a GraalVM feature being referenced at runtime.

A combination of factors is at play in the issue we are currently considering:

- A GraalVM feature is added to the index by the CXF extension - it's part of a jar that is added to the index

- The GraalVM feature has a `List` implementation

- HV will keep track of this class because of ^

- GraalVM chokes because you can't have a Feature referenced in the image heap

Problem is:

- The GraalVM feature is in the runtime artifact and as such is considered runtime

- Except it's actually not present at runtime

While it's the first time we actually hit this issue, and that we are working on local fixes, I think we have a more global issue with this and that we should probably consider how to solve the issue in a generic way.

QuarkusClassLoader.isClassPresentAtRuntime() is of no help as from a class loader perspective this resource is visible at runtime.

I wonder if GraalVM/Mandrel should expose a method that allows to check if a class is a feature. Ideally just by pushing the name of the class as a string to avoid loading it.

A bit similar to what is exposed with ImageInfo.

If so, we could return false in QuarkusClassLoader.isClassPresentAtRuntime() when the class is a feature.

Note: I know I could load the class, get the annotation and see if there is a Feature annotation but I was hoping we could avoid this.

--

Guillaume

[Guillaume Smet]

On Mon, Apr 7, 2025 at 5:57 PM Guillaume Smet <guillau...@gmail.com> wrote:

Note: I know I could load the class, get the annotation and see if there is a Feature annotation but I was hoping we could avoid this.

Sorry, to be exact, it would be checking that the class implements the Feature interface.

[Max Rydahl Andersen]

funky - got link to any specific issue this caused problems?

was it correct by the CXF extension to add the classes in the first place?

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo8BKj9G%3Db_7Rc9NFFr9xNE61iEZ4%3DfC3obMJS1ocg3%3DKQ%40mail.gmail.com.

[Guillaume Smet]

I can push you the pointers but the thing is a bit convoluted so let me summarize:

- the gist of the issue is that the angus-activation jar gets added to the index by Quarkus CXF. It's not wrong per se, it makes things easier for them - even if I think we should probably adjust it and be more surgical

- that means you end up with the Angus Activation GraalVM feature class in the Jandex index

- the Angus Activation GraalVM feature class is using a good (well, bad if you ask me) old pre-Java 11 pattern to define a static List meaning you end up with an anonymous class extending ArrayList (see my fix here: https://github.com/eclipse-ee4j/angus-activation/pull/52/files)

- when the user is using `@Valid List<MyBean>` (which is deprecated, you should use List<@Valid MyBean> for this use case), HV collects constraint metadata for all the List implementations, including the anonymous class extending ArrayList that is in the Angus Activation GraalVM feature class

- HV keeps a reference to the feature class that will be included in the image heap

- GraalVM is not happy as feature classes may not be included in the image heap

So this is a conjunction of a lot of factors but it all boils down to this: GraalVM features are in the runtime artifact but they are actually not present in the runtime and shouldn't be considered as runtime classes.

--

Guillaume

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/0A3E9BB4-4ED1-41DB-A483-98D00BE26DF9%40redhat.com.