I experimented lately with Graal
to create executable images. One of the goals was a small application that accesses a database using a connection pool.
SubstrateVM is in the very early stage so most things don't work yet. Plus there is a big list of various limitattions
that programs compiled into native code must work with.
I tried to adapt HikariCP to fit into SubstrateVM's closed-world assumptions and the good news is that it mostly works.
The biggest pain points are:
1) unsupported features in JDBC driver code,
2) dynamic loading of JDBC drivers,
3) reflective setup that includes dynamic classloading,
4) optional dependencies.
Let's look at those individually:
1) I found out that, unlike many others, PostgresQL JDBC driver mostly does work - the most problematic code only takes care of cleaning up badly handled resources. Limited but workable.
2) The driver code can be explicitly loaded as a dependency and manually registered. OK.
3) The reflective setup in HikariCP is a tough nut for Graal to break. But I figured out that if I just replace the dynamic code with some repetitive (and a bit ugly) static code Graal can compile the code without problems.
See this commit
. It doesn't end there - the program must prepare and pass the datasource to the pool directly bacause of other limitations. OK.
4) Optional dependencies are another thing that Graal's native-image can't handle well. Even if you don't use those features native-image will try to compile them. For now I just stubbed those. TBD.
What I'd like to see is a single version of HikariCP that would fully work in either traditional JVM or natively compiled code. The question is how to get there. What do you think?