Hi cstrobl I agree with your suggestion at high level, but I won’t have the bandwith to implement such changes. Contributions are very welcome. Frankly I don’t think it’s viable for us to make Hibernate ORM work out of the box in any custom framework within GraalVM native images - each runtime will need to plug or drive some customization, especially if one wants an optimised output; I’d dare say that if people don’t care about an optimised output, then there’s no point to look into native images at all so the optimal output is an hard requirement.

So I’ll welcome PRs that improve and allow any framework to have more control on such details, but I don’t think it’s a viable plan to make any use of Hibernate ORM simply compile to native out of the box. Also because of diminishing returns, there’s very few non-advanced users who will not be using a runtime framework to bootstrap Hibernate, so such a limitation is acceptable.

Regarding to the codepaths leading to the inclusion of ByteBuddy - I think I’ve improved that in https://hibernate.atlassian.net/browse/HHH-16058. A further improvement, could be to move the actual ByteBuddy integration code into a different jar, so to make it easier to exclude from the classpath when compiling a native image. I think the current code will already lead into a full exclusion of such code when creating a binary, but clearly that’s easier to verify and maintain if we make this code fully optional.

Again I don’t think I’ll have bandwith to extract that code into a separate module myself soon, but I’d welcome pull requests and would be happy to review them.