Both Apache Client and Netty are included in the runtime scope by default

[axelfontaine]

Describe the bug

When simply including a service, say ec2 in a Gradle build, both the Apache Client and Netty get pulled in as runtime transitive dependencies by default.

This is due to

aws-sdk-java-v2/services/pom.xml

Line 381 in 2f4b44d

<scope>runtime</scope>

and

aws-sdk-java-v2/services/pom.xml

Line 387 in 2f4b44d

<scope>runtime</scope>

This then automatically gets picked up by the Gradle application plugin and needlessly includes tons of jars in the final package.

Expected behavior

Default to a single client, preferably the plain and lightweight url-connection-client.

Current behavior

Dozens of additional jars are pulled in by default.

Steps to Reproduce

Create a new build.gradle.kts file and add the following dependency: implementation("software.amazon.awssdk:ec2:2.17.131").

Now run gradle dependencies and check the runtimeClasspath section.

Possible Solution

Only depend on url-connection-client by default.

Context

No response

AWS Java SDK version used

2.17.131

JDK version used

17.0.2

Operating System and version

Win11 x64

[debora-ito]

Hi @axelfontaine thank you for reaching out.

This is by design, Apache and Netty are distributed by default because they provide more robust features that support the SDK as a solution for customers of all types. With the robustness comes the jar size.

If you'd like to reduce the size of your project you can exclude both netty-nio-client and apache-client from the dependency list. We show an example of how to do this in the Developer Tools blog: Tuning the AWS Java SDK 2.x to reduce startup time. The post also have tips to reduce startup time of Lambda functions.

[axelfontaine]

I stand by my original comment. The default should be sensible, where in my opinion the current one isn't.

Regardless of the choice of default, configuration options as well as the current default should be documented on https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/http-configuration.html instead of random blog posts. It would also be nice if that page could include all available options and how to switch between them, as currently url-connection-client doesn't even get a mention.

[debora-ito]

Agreed, we can definitely improve the Dev Guide around HTTP client options.

[zoewangg]

Hi @axelfontaine, thank you for your feedback. We should definitely improve our Dev Guide.

The reason why we include a default sync and async HTTP client in the SDK is that this way, the SDK client works out-of-box; otherwise, users would need to manually add another HTTP client dependency for sync or async client, which, we think, is a bad customer experience.

I think the choice of the HTTP client really depends on the use-case. Apache HTTP client offers better connection pooling and more features at the price of JAR size and startup time, and JDK HttpURLConnection is more lightweight with limited features. IMO in most cases, Apache HTTP client should be preferred unless startup latency or JAR size is a concern. In addition, Java SDK v1 also uses Apache HTTP client, so it seems to make sense to continue to use it as the default sync HTTP client in v2 to provide a consistent experience.

[axelfontaine]

Fair enough. That's good rationale for picking the Apache HTTP client as a default. But don't bundle any additional one! If people want to switch to a different one, they can then simply follow the instructions on your soon to be updated docs page.

[erindru]

Just had this exact problem.

I think the choice of the HTTP client really depends on the use-case

Indeed. Have you considered letting people decide their own use-cases for themselves?

The current approach pulls in a specific version of netty by default, which for our use-case actually caused a conflict because the rest of our code depended on a different version of netty.

Manually excluding netty-nio-client is not a great user experience because it has to be excluded from every single SDK library we use (s3, sts, sso, glue) which is quite verbose