Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not compatible with native image since version 0.2.5 #116

Open
loicmathieu opened this issue Jun 24, 2021 · 1 comment
Open

Not compatible with native image since version 0.2.5 #116

loicmathieu opened this issue Jun 24, 2021 · 1 comment

Comments

@loicmathieu
Copy link

Since version 0.2.5, the library uses a dynamic proxy (via WrapperProxy) on top of the JDBC connection.
Dynamic proxy didn't work OOTB on GraalVM native image, they need to be configured explicitly.

However, to configure native image dynamic proxy capability, we must configure the list of interface of the proxy, in the right order ! WrapperProxy generates a list of interfaces in no order, so we must register all possible combinations which can be huge, see the following experiment with an underlying Postgres driver: https://gist.github.com/luneo7/453ea0bd0d51a48c6c4377237e8ad831

Imagine native support where we want to support multiple database drivers, this becomes challenging.

Be also aware that with such configuration time to build the native image incrase a lot.

I don't know if it' easily feasable to switch back to not using any proxy, or if at least the WrapperProxy can be updated to generate a list of interfaces in a reproducible manner so we don't have to configure all possible combinations.

@gsmet
Copy link

gsmet commented Dec 20, 2021

Hey there,

We are kinda stuck in Quarkus to an old version (0.2.4) due to this proxy issue.

As Loïc mentioned it, for GraalVM and native executables, we need to register the proxies beforehand. Proxies have to be generated with the exact list of interfaces in the exact order in which they are used in the proxy declaration.

I think there are two issues we need to solve:

  • we need a stable order for the interfaces, at the moment it's a set with no particular order - see discussions here: Patch Classes.getAllInterfaces to return predictable array java-common#2
  • less important but I think it would be a nice cleanup as it makes things more complicated on both sides: I don't think you should use getAllInterfaces() for creating a proxy. Having the proxy implementing the direct interfaces should be good enough. Maybe I'm missing something as for what you declare all the interfaces?

We are very willing to help on this issue and open to discussions so please reach out to us and let's try to get this fixed.

BTW, the problem is not specific to Quarkus but will impact all projects supporting GraalVM's native executables.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants