Add support for GraalVM native images

[jdubois]

It would be great to be able to use this library as part of a GraalVM native image build. This would mean less resources needed for end-users, with less cost and less CO2.

It's currently failing because you are using Jackson with Kotlin, and that uses a ton of reflection. It's near impossible to solve it by hand.

I've managed to make it work in one of my (private) projects, using the GraalVM's native image agent. For this to generate the full configuration, it needs to go through all of the execution paths (to find out all those Jackson-configured files, and there are a lot). So instead of doing the GraalVM configuration by hand (again, nearly impossible), it would be all automatic.

The trick is to use it during the test phase, as the test suite should use all of those reflection-heavy files.

Here's how to do it:

1. Install GraalVM and use it for your build (here's the GitHub action: https://github.com/marketplace/actions/github-action-for-graalvm )
2. Run the tests for the open-java-core module with Gradle, and add -agentlib:native-image-agent=config-output-dir=src/main/resources/META-INF/native-image to the command line
3. This will generate the correct configuration metadata for GraalVM, in a file called openai-java-core/src/main/resources/META-INF/native-image/reachability-metadata.json
4. Next time the application is packaged, this file containing the GraalVM configuration will be shipped with it, and projects will then be able to use it correctly when building the native executable.

If that's fine for you, I can do a PR for this, either:

• in the .github/workflows/ci.yml action, so you'll have it correct all the time. The main downside, is that it's weird that the CI action generates a file that is needed for the build, that seems counterintuitive.
• In a specific action, for example .github/workflows/graalvm.yml, that would run once every day. As those files shouldn't move very often, that should be good enough. The main downside would be if a new file is added, and you do a release, all in the same day before that action is triggered.

As an example, here's the reachability-metadata.json file I generated for my project (it's not complete as I don't need everything, but it gives an idea and works 100% for my use case):

reachability-metadata.json

[TomerAberbach]

Sounds like a cool idea :)

Is it necessary for the file to be committed? Or could we just generate it in https://github.com/openai/openai-java/blob/main/.github/workflows/create-releases.yml right before publishing?

[jdubois]

I guess that's annoying for you to commit it because of your code generation process, and I doubt anyone will ever look at this file, so yes it can be done on the fly during a release.

[TomerAberbach]

Cool, PR welcome!

[jdubois]

I'll submit it this week!! I probably won't be able to run the action, so I might need your help to test it.

[TomerAberbach]

Sounds good :)

[TomerAberbach]

By the way, this issue is making me extra glad that I added JSON roundtrip tests for every class. Guarantees we calculate the reachability correctly I think

[jdubois]

It was a bit more complicated than expected, that's why you'll have this next week instead :-)
I have it running fine now, it's just a matter of cleaning and documenting things.

[jdubois]

And the PR is ready! It's a bit complex, happy to discuss it!