Better DevExp for serialization feature support as of GraalVM 21

[machi1990]

Description

The new release of GraalVM 21.0 adds serialization support, developers can configure class for serialization via the serialization configuration file -H:SerializationConfigurationResources=/path/to-serialization-config.json option.

This release will be supported in Quarkus soon thanks to @zakkak .

This can at the moment be achieved by quarkus.native.additional-build-args=-H:SerializationConfigurationResources=/path/to-serialization-config.json, however we can add features like the one we added for H:ReflectionConfigurationFiles option i.e @RegisterForReflection annotation for better developer experience.

We can also, add a way (programmaticaly) to include classes that are not part of the application e.g the ones coming from external libs / frameworks (I am wondering if there are still efforts to do this for the reflection configuration??), instead of the developer having to use the json configuration file.

/cc @gsmet @geoand @stuartwdouglas @zakkak @emmanuelbernard

[geoand]

Thanks for bringing this up @machi1990

Although it's interesting, I don't think anyone has ever complained about serialization not working in native, which probably means no one relies on it.
In that light, I propose we hold off from adding anything unless users really ask for it

[gsmet]

So... my secret dream would be to have a Wicket extension for Quarkus and we would need to be able to register classes for serialization for this to work :).

[geoand]

Then that make you the first user to request it 😂

[machi1990]

Then that make you the first user to request it

I think we are not seeing the request here (yet), as this has been mostly a GraalVM issue.

[gsmet]

For me, it's the role of Quarkus to expose this and make it easier to use, even if in the end few people use it.

[geoand]

I would argue that it's probably prudent to reduce our surface by not introducing features that users don't have a need for.

[gabrielsson]

It would be great with serialization as I use hibernate. Composite keys, special db types etc can be supported. Simple things like binding hibernate with JoinColumns without foreign keys as well. There is great potential with support for GraalVM 21 in general, and serialization in particular.

[ppalaga]

We'd very much welcome some sort of SerializableClassBuildItem being delivered by Quarkus. Actually we have a bunch of issues at Camel Quarkus that were originally blocked by oracle/graal#460 and oracle/graal#2730 and are now blocked by this one :).

[JiriOndrusek]

I'd like to create SerializableClassBuildItem and @RegisterForSerialization (both similar to reflection registration)
I'd like to create PR with contribution linked to this issue. Is there any other functionality which should be considered as a part of this feature?

[ppalaga]

I'd like to create SerializableClassBuildItem and @RegisterForSerialization (both similar to reflection registration)
I'd like to create PR with contribution linked to this issue. Is there any other functionality which should be considered as a part of this feature?

I volunteer to review and assist if necessary.

[gsmet]

I suspect we will also need something similar to the ReflectiveHierarchyBuildItem.

[gsmet]

(Except if GraalVM handles it automatically!)

[stuartwdouglas]

So I had a quick look and I think that maybe it is just an extra flag on fields to allow final fields to also be set (i.e when fields are registered for reflection, you can basically set a flag that says that final fields can also be updated).

If this is all it is then maybe it should tie into our existing reflection infrastructure.

[JiriOndrusek]

PR with the implementation is prepared and approved to be merged (#15380)