Broad pattern in sdk-core resource-config.json inflates GraalVM Native Image Heap

[bipe15]

First of all, I would like to thank you for the amazing job developing the SDK and especially for Native Image support.

I'm compiling an application with native-image, which uses AWS SDK, S3, SQS, SNS, BedRock. After enabling the build report, I noticed that the .class files are being included in the Image Heap as resources. In my opinion, it does not make much sense since a .class file won't be accessed as a resource.

GraalVm Image Heap documentation

Embedded Resources Stored in byte[]
The total size of all byte[] objects used for storing resources (for example, files accessed via Class.getResource()) within the native binary. The number of resources is shown in the Heap section. A list of all resources including additional information such as their module, name, origin, and size are included in the build reports. This information can also be requested in the JSON format using the -H:+GenerateEmbeddedResourcesFile option. Such a JSON file validates against the JSON schema defined in embedded-resources-schema-v1.0.0.json.

I found the source of all of this in sdk-core resource-config.json. There is a directive to include all under software/amazon/awssdk/

{
  "resources": {
    "includes": [
      {
        "pattern": "software/amazon/awssdk/services/\\w+/execution.interceptors"
      },
      {
        "pattern": "software/amazon/awssdk/.*"
      }
    ]
  }
}

I DID NOT TEST IT YET in AWS environment
To solve this situation, in my resource-config.json, I excluded all .class files.

{
  "resources": {
    "includes": [],
    "excludes": [
      {
        "pattern": "software/amazon/awssdk/.*\\.class"
      }
    ]
  }
}

The result is that the Image Heap was reduced by ~35MB.

I don't know if that configuration was made on purpose for any reason or if it was a mistake.

[bipe15]

I can confirm that the solution is working as expected. I will open a bug referencing this ticket

I was using S3, Bedrock, Textract, SNS, SQS and SES services; the reduction was ~35MB