feat: add GraalVM Native Image support metadata

[Aamir377300]

This pr solve issue #156

Description

This PR adds initial GraalVM Native Image support for hiero-enterprise-java. While exploring native compilation, I noticed that some parts of the project rely on reflection and configuration patterns that GraalVM cannot automatically detect during native image generation. Because of that, applications using the library may run into runtime issues when compiled as native binaries unless additional metadata is provided manually.

This PR adds the required metadata and Spring AOT hints so native compilation works more smoothly out of the box.

Changes Included

Reflection Metadata

Added reflect-config.json files under:

META-INF/native-image/org.hiero/

The metadata currently covers core data classes, protocol request/response classes and serialization-related types used at runtime

Spring AOT Support

Added HieroRuntimeHints in the Spring module to provide runtime hints required during Spring AOT processing. Also registered the hints through:

META-INF/spring/aot.factories

General Improvements

While working on this, I also reviewed the codebase for reflection usage and a few other native-unfriendly patterns related to proxies and resource loading. The metadata structure follows the standard GraalVM layout so it can be automatically picked up during native builds.

Verification

Verified successfully with:

./mvnw clean compile

@Ndacyayisenga-droid please review this pr and i am open for your feedback.

[aceppaluni]

@Aamir377300, this is great work so far.

I am taking a look at this and noticed in the description you have "This PR adds initial GraalVM Native Image support.." Am I to conclude there will be additional PR's related to this issue?

I ask as I am attempting to run this but am running into errors
My understanding is that ./mvnw clean compile verifies a successful build but does not verify successful native image generation/build.

Have you generated a native image using something like

./mvnw native:compile

or

 ./mvnw -Pnative native:compile

[Aamir377300]

Hi @aceppaluni

To answer your first question: Yes, there will definitely be additional commits on this pr related to this and I will change the name of the pr!

What this PR contributes: This initial PR focuses strictly on laying the foundation by adding GraalVM metadata (like reflect-config.json) and Spring AOT hints inside the library. This ensures that when end-users build downstream applications using hiero-enterprise-java, GraalVM automatically knows how to handle the dynamic reflection, preventing immediate runtime crashes.

Why you are seeing errors: The errors you are seeing with ./mvnw native:compile are actually expected right now. Because this repository is a library and not a standalone application, it doesn't have the application-level GraalVM plugins (like native-maven-plugin) configured globally. Libraries themselves aren't compiled into native executables; they just provide the metadata so that consumer applications can be compiled natively.

Next Steps: I plan to make commits on this pr that configures the hiero-enterprise-spring-sample app with the proper native build plugins.

Please let me know what you suggest!

[hendrikebbers]

If I understand it correctly the changes make the hero-enterprise-sping module compatible with graalVM. I dislike the changes in the current state of development since several things in Hiero can still change and this change would end in the need top always update the reflection information of all beans managed in spring.

In general it is a good idea to support that in future as part of a 1.0 release and an example but today we are not at that point. Next to that the change sadly does not bring in any integration tests that shows that it is now fully working on GraallVM.

[Aamir377300]

Hi @hendrikebbers,

Thank you for your valuable feedback! I completely understand and agree with your concerns:

• Maintenance Overhead: Since Hiero is actively evolving pre-1.0, manually maintaining dynamic reflection metadata and AOT hints across frequent bean/property changes would indeed add a significant maintenance burden.
• Lack of Automated Testing: Without native integration tests in CI, this metadata could easily drift and rot over time without anyone noticing.
• Roadmap Fit: I agree that comprehensive GraalVM support makes the most sense as part of a stable 1.0 release, backed by solid examples and proper integration testing.

Since you've mentioned we aren't at that point today, I want to ensure this work isn't lost but doesn't get in your way. How would you prefer to handle this PR? This are the options from my end:

• Option A: Convert to Draft: We can convert this PR to a Draft and put it on hold. This way, the metadata is preserved, and we can resume work on it (and add proper native integration tests and other improvement) when the project is closer to the 1.0 release.
• Option B: Close and Track: We can close this PR for now, and I can open a tracked issue (e.g., "Support GraalVM Native Image (Target: 1.0)") linking back to these changes so we have a clear reference for the future.

Let me know what you suggest!