Resource and JNI configuration files to support CRT in GraalVM native image

[timmattison]

Motivation and Context

These changes are required to allow customers to build GraalVM native images that utilize the AWS CRT libraries. This may be starting point to address issues raised in #2948.

Modifications

I ran the GraalVM agent to gather the initial JNI configuration. Then I had to tune the results by:

• Forcing java.nio.Buffer and java.nio.ByteBuffer to include all constructors, methods, and classes
• Including all resources that end in .so, .dylib, .dll

Testing

I have tested this with Gradle on a separate application that interacts with Greengrass V2's IPC. I believe that it will need some modifications to work in other contexts.

For completeness the only classes that my IPC code references directly in CRT are:

• software.amazon.awssdk.crt.io.ClientBootstrap
• software.amazon.awssdk.crt.io.EventLoopGroup
• software.amazon.awssdk.crt.io.SocketOptions

jdeps provides this list of dependencies it detected:

software.amazon.awssdk.crt.io.ClientBootstrap
software.amazon.awssdk.crt.io.ClientTlsContext
software.amazon.awssdk.crt.io.EventLoopGroup
software.amazon.awssdk.crt.io.HostResolver
software.amazon.awssdk.crt.io.SocketOptions
software.amazon.awssdk.crt.io.SocketOptions$SocketDomain
software.amazon.awssdk.crt.io.SocketOptions$SocketType

So it is possible that applications that depend on CRT classes outside of these may not work.

Some tuning code be done on:

• java.nio.Buffer and java.nio.ByteBuffer to use only the required elements. I couldn't get this working without everything but there may be some things that could be trimmed.
• jni-config.json might have extra classes referenced that are not needed. I tried trimming this down but eventually fell back onto the default output of GraalVM's agent.

It is likely Maven configuration will need to be done to pick up the binaries and put them in a place where GraalVM native image can find them. Without building a specific task to copy the binaries to my build/resources directory in Gradle the resource-config.json did not work.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[timmattison]

Here is the Gradle snippet I used to bring the binaries into my resources directory to get resource-config.json working

https://gist.github.com/timmattison/f4e1dbb165607c168e8b3f0ca2296d33

[debora-ito]

Thank you for the submission @timmattison, we'll review it shortly, most likely next week.

[zoewangg]

Thank you for your PR. This is a good start. I wonder if https://github.com/awslabs/aws-crt-java/ is a better place for these files.
For the time being, we can certainly merge this change to a branch and continue to work on it.

[zoewangg]

Can we move the file to the aws-crt-client module?

[timmattison]

Yes, I have a separate PR for this - awslabs/aws-crt-java#464 - any idea how we can move that one forward?

[zoewangg]

Do we need S3 related classes in the CRT HTTP client?

[antechrestos]

Is there any news on it? How can I help, I also met the same problem.. 😢