Introduce @RegisterForProxy to register interfaces of dynamic proxies for native image

[Eng-Fouad]

Description

Currently, the only option to register interfaces of dynamic proxies is to specify them in a configuration file (proxy-config.json):

[
 { "interfaces": [ "java.lang.AutoCloseable", "java.util.Comparator" ] },
 { "interfaces": [ "java.util.Comparator" ] },
 { "interfaces": [ "java.util.List" ] }
]

... -Dquarkus.native.additional-build-args=-H:DynamicProxyConfigurationFiles=proxy-config.json

See: Configure Dynamic Proxies Manually

Implementation ideas

Introduce new annotation @RegisterForProxy that is similar to @RegisterForReflection:

/**
 * Annotation that can be used to force an interface (including its super interfaces) to be registered for dynamic proxy generation in native image mode.
 */
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@Repeatable(RegisterForProxy.List.class)
public @interface RegisterForProxy {

    /**
     * Alternative interfaces that should actually be registered for dynamic proxy generation instead of the current interface.
     *
     * This allows for interfaces in 3rd party libraries to be registered without modification or writing an
     * extension. If this is set then the interface it is placed on is not registered for dynamic proxy generation, so this
     * should generally just be placed on an empty interface that is not otherwise used.
     */
    Class<?>[] targets() default {};
}

Usage:

@RegisterForProxy
public interface Foo {}

@RegisterForProxy
public interface Foo2 extends Bar2 {}

@RegisterForProxy(targets = {Foo1.class, Bar1.class})
@RegisterForProxy(targets = {Foo3.class, Bar3.class})
public interface ThirdPartyLibProxies {}

[geoand]

I think it makes sense. @zakkak WDYT?

[zakkak]

I agree. Not sure if the includeSuperinterfaces and extraInterfaces are really necessary (especially the latter can be easily replaced by @RegisterForProxy(targets = ...)).

[gsmet]

Not that we need to be extremely cautious about this one as ordering is important. We got bitten by that in the past.

[maxandersen]

This was closed yesterday but I didn't spot response/change in code to accommodate for the ordering concern @gsmet mentions above is it no longer relevant?

[Eng-Fouad]

This was closed yesterday but I didn't spot response/change in code to accommodate for the ordering concern @gsmet mentions above is it no longer relevant?

I think classInfo.interfaceNames() returns the correct order of interfaces, am I right?

quarkus/core/deployment/src/main/java/io/quarkus/deployment/steps/RegisterForProxyBuildStep.java

Lines 22 to 26 in 6bc64a0

	if (targetsValue == null) {
	var classInfo = annotationInstance.target().asClass();
	types.add(classInfo.name().toString());
	classInfo.interfaceNames().forEach(dotName -> types.add(dotName.toString()));
	} else {

Also, I added a note about interfaces order in docs:

quarkus/docs/src/main/asciidoc/writing-native-applications-tips.adoc

Lines 259 to 262 in 6bc64a0

	[WARNING]
	====
	Note that the order of the specified proxy interfaces is significant. For more information, see link:https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/reflect/Proxy.html[Proxy javadoc].
	====

[gastaldi]

For the record, I considered the note about interfaces order in docs would be enough for the concern @gsmet mentions, hence why I merged the PR

[Eng-Fouad]

cc @gsmet @geoand

[maxandersen]

assuming @gsmet is ok as this was merged so closing again.