Native image run breaks because of method delegation in DGS Spring Boot micrometer

[AyushChaubey]

Native image fails at runtime because of a third-party dependency ByteBuddy in DGS Spring Boot micrometer.

The DGS Spring Boot micrometer library uses ByteBuddy for method delegation.

This logic breaks GraalVM's "close-world" assumption, where it needs to know about all classes/code path at the time of building the native image. There are same ways that are used to provide the hints for all the code paths like using the GraalVM tracing agent and some other flags mentioned here. Even after using these features, the native image breaks at run time.

Example Exception:
Defining a class from new bytecodes at run time is not supported Class XYZ... with hash a35588c was not provided during the image build

Possible Solution:
Similar issue has been encountered by other people. One of the way that has been suggested to fix this issue is using Java Proxy in place of ByteBuddy. I have tried using Java Proxy in place of ByteBuddy in DGS micrometer and used it in the project to build the native image. The native image was created successfully and it ran without any issues. Do you think we can use Java Proxy for method delegation ?

Thanks in advance.

[paulbakker]

Since you've tried it with a Java Proxy, could you create a PR with that? If we can get it to work well without bytebuddy that would be good.

Also, if you create a PR, could you add instructions how you're creating a native image? It would be great if we can support native images, it's just that we currently don't have much experience with it.

[AyushChaubey]

Thanks for your reply @paulbakker . I will create a PR and will let you know.

[AyushChaubey]

Here is the PR

[AyushChaubey]

Hello, it would be great if you can please review above PR. Thanks

[srinivasankavitha]

Thanks for the PR! We'll take a look shortly. Apologies for the delay on this.

[AyushChaubey]

No Problem. Thanks for your help on this.