If you utilize the aws-java-sdk to customize utility classes under Repository-->Code -> Routines and use this customized class within the components such as tJava / tJavaRow etc, please be aware that the aws-java-sdk is an all-in-one JAR. You might overlook the significance of SDK modularity and opt for an all-in-one JAR, potentially leading to the adverse effects detailed in the article.
Adverse effects
1.Increased Application Size:
The all-in-one JAR bundles all AWS service SDKs together, significantly increasing the size of your application. This results in larger deployment artifacts, slower download times, and increased storage consumption, due to the increased size of the Job design (aws-java-sdk.jar: 100-400MB), thereby intensifying the network transfer burden for deployment.
2.Higher Memory Usage:
During application startup, loading the all-in-one JAR into memory demands additional memory, as all AWS service classes are loaded, including those not in use. This can result in increased memory consumption and footprint, and may lead to out-of-memory errors in resource-constrained environments.
3.Reduced Modularity and Flexibility:
Using the all-in-one JAR reduces the modularity of your application. It limits your ability to customize or optimize the inclusion of specific AWS services, leading to a less flexible and maintainable codebase.
Resolution
Instead of including the entire aws-java-sdk JAR, opt for individual service modules. Include only the specific AWS SDK modules your application needs. For instance, if your application interacts only with S3 and DynamoDB, include only aws-java-sdk-s3 and aws-java-sdk-dynamodb dependencies.
This approach helps minimize the application size, reduces memory footprint, and enhances overall performance by loading only the necessary classes at runtime.
