Ensuring the closed-world assumption when compiling GraalVM native images

I upvoted but this is both inherent to the GraalVM architechture, as also dynamic reflection is not something to strive for. So use reflection only in libraries and provide alternative (declarative) solutions.

When you run your code in an ordinary, recent Java environment, each time you have to add an --add-opens argument you know who is using deep Reflection. Put your application code in a named module and libraries do not automatically get acces to your private members.

Since this is something the libraries have to cope with, ensuring that you use the most recent version of the library may often solve such problemes.

Quick answer:
yes, frameworks like Spring Boot, Micronaut or Quarkus will help and guide you in avoiding/solving problems like in this questions.

Longer answer:

1. You may be wrong by judging about GraalVM native image building, Ahead-of-time (AOT) compilation, by just trying good and old Jackson. Have you tried searching for

• "Jackson JSON deserializer problems on GraalVM"
• "Jackson JSON deserializer features that support GraalVM"
• "Jackson alternative JSON deserializer for GraalVM"

2. By Java feature that allows to introspect private fields, I guess you meant reflection. That is nice that you do not know the name, and if you did, forget it, because current JDK development sends very clear message: Java private and final classes/fields MUST exactly be. And SHOULD be no way to go around. Next Java LTS (29) that may be exactly the case.

3. And specifically for cases like deserialization/serialization, annotation, reflections and other similar problems, that comes from the facts that 1) they use some data that is not in Java code and 2) GraalVM native compilation is actually second/alternative compilation for Java. So just do not expect that everything will behave absolutely as with OpenJDK (.class bytecode) compilation. But the GraalVM developer surely do great effort, that it would seem so.

P.S. Extending quick answer:
With those frameworks, developer does not even needs to care about what JSON deserializer library and version is used. They would just work on GraalVM.

TBC

have a good look around and good luck.

It's not that I'm striving for dynamic reflection, but we have three decades of libraries that (ab)use this feature. How do I make sure to include libraries that don't?