There were no significant changes in that area, but H2 uses reflection in a few places in both these versions. Actually 1.4.200 uses less amount of reflective calls.

Please, report bugs and limitations of that tool to its developers.

And you need to check your configuration first, maybe you need to upgrade it for a new version of H2.

I took a look on Native Image Java Limitations section in its documentation and I think it isn't ready yet for H2. It may work somehow, but we don't have a time to support that tool in its current status.

Hmm, why 199 was working then? I activated reflection and resources as needed by h2 and this part is fine.
Issue is not the reflection but the static initialization which seems to trigger more class loading - almost all h2 - in 200 than 199 (maybe the auto load driver trigger the full h2 loading?).

I have no idea how and why older version works. Maybe you need to include more classes to your configuration for 1.4.200.

And because H2 1.4.201 will be Java 8 based, most likely it also will be even less compatible with native images until they will be improved to support more basic features of JVM.

This is a bugtracker of H2. Your issue is not a bug of H2, we don't support that tool. If you need some help, please use our mailing list, StackOverflow, or some other resource for your questions.

Hmm, what is the issue with java 8? Graal is based on java 8 and next release will support java 11 so not an issue with graal currently.
Since all the microservice ecosystem - using h2 - starts to support graal, i think it makes sense to ensure it is compliant for h2.

Native images don't properly support invokedynamic from Java 7 (not widely used before Java 8) and method handles; only a limited subset of them is somehow supported. Other limitations also exist. You should consider native images as an experimental feature that could be suitable for projects specially designed for it, but not as something that will always work with third-party projects, especially with complex ones.

I do consider it as specific to a deployment but it is no more experimental and officially supported for prod. It is also required in several cloud/k8s cases - to reduce boot times and memory usages - so it is good to be able to use h2 IMHO. What about reporting issues you have to be friendly with native-image on graal bugtracker referencing this issue? They are quick good at fixing things and I dont see why h2 would not be able to run whereas quarkus made most of jboss ecosystem running.

@rmannibucau you are welcome to debug this issue and report stuff to Graal. However, I am sorry, but no-one here is interested in doing that, and we do not consider Graal a supported feature.

FYI I put a sample on github https://github.com/rmannibucau/h2graal
Seems the issue was mainly a server cache issue.
That said would be great if h2 can check it still works before releasing ;).

Thanks guys.

+1 interesed, to use in embeded in a desktop app, compiled with graalvm. Any alternatives if H2 is not gonna be suitable?

Maybe the error has a early solution oracle/graal#3028