GraalVM native image compatibility #8779
Comments
|
Indeed, apparently there are problems: |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
The problem appears to be the For applications not using this feature a workaround may be to build the native image using the |
|
Sorry, I already deleted my prior comment with jooq related issues. I upgraded to docker image graalvm-ce:19.3.0 for building (instead of prior 19.2.3) and got other errors, but none jooq related any more (or errors earlier not yet coming to jooq errors, don't know yet) :) |
|
We're currently thinking of a Proof of concept using jOOQ and potentially GraalVM. This issue makes us unsure about jOOQ's roadmap regarding GraalVM. Am i right to assume it's something close "jOOQ intends to support GraalVM but won't spend dedicated resource on it upfront and depending on the issue it might a blocker"? By the way can jOOQ already be used to build native app thanks to Jigsaw? I guess so but you know better for sure :) thanks again for jOOQ! |
Yes, we intend to
We'll spend time on this eventually, but it hasn't been a priority yet
We don't know yet
We don't know yet |
|
I have the following error when trying to build a very simple "insert" example with graalvm and JOOQ. I've included the flag from @knutwannheden but without success. I'm looking for another solution, but reading traces of native-image compilation is a bit cryptic 😅. Code can be found here: https://gitlab.com/davinkevin/picocli-jooq |
|
@davinkevin Thanks for your feedback. We have not really had time to look into supporting GraalVM. The error message being reported indeed looks very cryptic and similar to what is being reported here: oracle/graal#1863. It looks like the next GraalVM release might provide better error messages for this type of problem. |
|
I did a PoC a few weeks ago using Quarkus and jOOQ and was able to successfully build a native image with GraalVM. But I had to configure all generated Record classes to use Reflection. |
|
@jean-merelis Thanks for reporting back. Yes, jOOQ unfortunately depends on the JPA API, due to the features of the Can you elaborate a bit more on the problem with the generated record classes? jOOQ's Regarding your PoC, it would be very nice if you could document the required steps / configuration here in a comment. |
|
Generated record classes use reflection in some way, so them need to be registered to use reflection. I created a project to demonstrate the use of jOOQ with Quarkus This successfully creates a native image. Prerequisites:
To create native image: To run native image: |
The jOOQ maven plugin could be responsible of creating such a file I think. |
|
I did some experimentation today with jooq and quarkus and graalvm native-image. My findings, if it can be helpful one day:
I would IMHO recommend that if we want jooq to support GraalVM seriously, that all this dynamic proxy thing be moved to an opt-in/out mechanism so that we don't have to find a workaround. Another solution would be to provide, in the form of a module to add to the classpath, some mean to disable the |
|
For the record, adding the following class in the classpath is enough to satisfy graalvm so that @TargetClass(className = "org.jooq.impl.DefaultRecordMapper", innerClass = "ProxyMapper")
final class ProxyMapper_Substitute {
@Substitute
private Object proxy() {
throw new UnsupportedOperationException("Can't work with GraalVM native");
}
} |
|
And by the way, with the above substitute class, it works with GraalVM 20.0.0 :) |
|
@victornoel would you enable me to contribute this to micronaut-sql project? |
|
@morki of course yes, great news then :) |
|
I can feel it. Just throw it into the corner. |
😅 I'll try it again on linux maybe. Though, wait a sec, according to https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.3.1, AMD architecture is required also on linux. The build server is: That means, I won't be able to test this without using new machines? |
|
@lukaseder I believe amd64 here just means x86, not especially amd-brand cpu |
Well, it does say "Windows (amd64)". Anyway, I'll find out next week. |
|
@lukaseder the error message you got said "32-bit architecture x86 unsupported", is it possible you are using a 32-bit Windows version and not 64-bit? |
|
@victornoel Not really, all my machines are running 64 bit Windows, but indeed, this Visual Studio stuff installed itself in |
|
For running native image on Windows, you can check this. Native image support on Windows will become simpler and more reliable in the upcoming GraalVM 23.0 release, see this related tweet and related issue (for now, I advise to not store your project in a path with spaces). |
|
How to say I don't know jack about hardware without saying I don't know jack about hardware 😅. |
|
Any ETA on this one ? |
|
@lukaseder - Is it just the generated Record* types which are to be registered with AOT or any other JOOQ related types? |
|
I don't know |
|
In my experience GraalVM reflection is needed for jOOQ records, POJOs, UDTs, DAOs, packages and routines. Basically everything that is generated by the jOOQ code generation, except the table class that I have a project that is in use in production that uses Quarkus + jOOQ + GraalVM, and there I needed to add these reflection so working with tables, UDTs, packages/routines works at all in the I generate the Quarkus |
|
@lbkulinski & @ThoSap - Thanks for replying so quickly. @ThoSap - Do you know something similar available for spring boot as well? |
|
Thanks a lot, @ThoSap To everyone who is impatiently waiting for an ETA here, think about it this way. The Graal folks broke the WORA promise that Java had for so many years. This means, everyone has to now find out themselves how to work around this and it's really painful as this issue documents. You folks already made this choice voluntarily, but I didn't. For jOOQ, this would mean prioritising irrelevant (to jOOQ) infrastructure investigations over many other much more useful things (to jOOQ). There are other, similar "weird" integrations that keep demanding attention to "non-essential" stuff. In jOOQ, everything SQL, mapping, database related is essential. Everything integration with what not is "non-essential." This includes:
And for anyone who hates themselves, try combining 2-3 of the above for extra integration fun. So many gifts that keep on giving :( I would be very happy to address this issue here if someone did the "hard parts" of setting up a build that works out of the box, everywhere, using jOOQ, e.g. based on one of these projects:
Once such an example is set up, jOOQ can regression test it, and continue adding new stuff. Unfortunately, jOOQ doesn't have a devrel whose job is to write 100s of basic integration tutorials about arbitrary tech to generate some SEO traffic for a totally unrelated product 😅 (who enjoys this, really?) So, this would be a highly appreciated contribution to the jOOQ ecosystem, if anyone is interested. The jOOQ CI/CD pipeline uses:
I prefer not to use anything else, including Gradle, GitHub actions, etc. |
If you use Gradle you could adapt my custom @lukaseder I think this is exactly what jOOQ should do for GraalVM compatibility in the jOOQ Maven/Gradle plugin, generate this GraalVM Maybe I could work on a PR for this functionality. |
Yes, that's what I had in mind. If I can then regression test this file with a simple demo project, I'll add this to the CI/CD pipeline, aand possibly even start refactoring internals to avoid reflection where unnecessary. |
|
I've been working on building my app using GraalVM native and so far jOOQ actually seems to be working fine with generated configs using automated tracing: https://www.graalvm.org/latest/reference-manual/native-image/metadata/AutomaticMetadataCollection/ Given that jOOQ is a code generation tool (so there's no static reflection config to prescribe) and this approach seemingly works, it really seems like this should be an exercise left to the user - at most perhaps include a link to the above doc page within jOOQ documentation. [edit] As an addendum, both jooq (and its dependencies that GraalVM complains about) as well as your generated model source need to be marked for initialization at build time. |
|
@rvaidya I thought that but it seems they use reflection java.lang.IllegalStateException: Could not construct new record |
|
Working happily with Spring Boot 3.3 using Native GraalVM and jOOQ. I'm using DAOs as Spring beans in addition to the usual hand crafted queries. I just add reflections to my classpath annotate my SpringBoot application with Where MyRuntimeHintsRegistrar reads: |
|
@bylidev Reflection is used, but you can generate reflection metadata that can be passed to GraalVM using the automated tracing. Start your Java app up with automated tracing, and then exercise as much code as you can at runtime - either through automated tests or doing so by hand. The link in my earlier comment is the official documentation for this. |
I tried using the GraalVM agent to do that, but it didn't work. Anyways, I'm going to try @rcomblen's solution. |
and others
It should be checked if jOOQ is GraalVM compatible. I.e. whether native Substrate VM images can be built for applications built on jOOQ.
The text was updated successfully, but these errors were encountered: