Missing io.confluent:kafka-avro-serializer in Quarkus BOM

[pjgg]

Describe the bug

I could not find io.confluent:kafka-avro-serializer lib on Quarkus BOM and the latest version 7.1.2 is not working in native mode

Caused by: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: Detected an instance of Random/SplittableRandom class in the image heap. Instances created during image generation have cached seed values and don't behave as expected.  To see how this object got instantiated use --trace-object-instantiation=java.util.Random. The object was probably created by a class initializer and is reachable from a static field. You can request class initialization at image runtime by using the option --initialize-at-run-time=<class-name>. Or you can write your own initialization methods and call them explicitly from your main entry point.

Because there is a static java.util.Random definition in some internal library on version 7.1.2

Version: 7.0.3 works as expected.

IMO the issue is that io.confluent:kafka-avro-serializer should be defined in Quarkus BOM or be included as part of quarkus-confluent-registry-avro

WDYT?

[quarkus-bot]

/cc @alesj, @cescoffier, @ozangunalp

[pjgg]

Note(to keep in mind): Maybe from an end-user point of view, update AVRO serializers is not a minor update because all generated "serializers" objects, should be re-generated... I mean, Is possible that a producer / consumers use different Serializer versions?

[ozangunalp]

We need to add the confluent maven repo to the bom (or the parent pom) in order to add this to the bom. I don't think we want that. I think this is the reason the dependency is not added to the extension. @alesj WDYT ?

For the native compilation issue with random, we need to add the class as runtime initialized.

[alesj]

Yeah, I think that was one of the main reasons why it's not added.
But my latest change just split some of the poms, modules, dirs, classes ...
So I guess @Ladicek or who did the initial Registry integration could tell more.

[alesj]

For the native compilation issue with random, we need to add the class as runtime initialized.

So no more substitutions for such things?

[Ladicek]

I don't think adding the Confluent Maven repository into the BOM would help, even if we wanted to do that (which we don't), because importing a BOM only manages dependency versions. The extensions for Confluent Schema Registry still require people to manually add the Confluent Maven repository and the correct dependencies manually, and until Confluent publishes their libraries to Maven Central, that's the best we can do.

[ozangunalp]

That's a very good point, imported bom won't import defined repositories.

[cescoffier]

Yes, and we do not want to declare the confluent repository. So for now, there is not much we can do, except document the support version.

We could support conditional substitutions to support the newest version, but... oh my...

[cescoffier]

Assigned it to me, I will add something to the documentation.