Please do not EOL the AWS Java SDK v1

[gredler]

IMO the v2 SDK is heavy, complex, gratuitously different, and unnecessary.

My eyes glaze over and my finger begins to cramp as I scroll through the v2 dependency tree.

My hard disk whimpers and my ISP throttles my connection as I download half of repo.maven.apache.org.

My daughters look at me teary-eyed, asking me to fix the now-frozen Ponysitters Club stream.

My customers curse my name as they purchase new servers with larger hard disks that can fit the v2 SDK.

My wife wonders why I'm spending yet another late night at the office, beholden to the busy-work generated by the stylistic and architectural bikeshedding taking place thousands of miles away.

Please continue to support the v1 SDK.

Thanks!

[debora-ito]

Hi @gredler, thank you for the feedback, we appreciate it.

When you say:

the v2 SDK is heavy, complex

what are the pain-points, specifically? Is it artifact jar size when compared to v1? Is it code complexity? Is it client tuning? All of the above?

How can we help make the migration experience easier?

[gredler]

Hi Debora, thanks for the follow-up!

From my first (and only) hour of attempting a quick migration of a hobby project:

• The number of JARs seems to have exploded. I can't figure out which transitive dependencies I need and don't need, since there's a lot of "batteries included" by default.
• The class names are all slightly different, rearranged to presumably prioritize internal consistency over downstream impact (BasicAWSCredentials -> AwsBasicCredentials, AWSStaticCredentialsProvider -> StaticCredentialsProvider, etc).
• Once you do find the correct class, you inevitably must perform either the "constructor -> builder" dance or the "constructor -> factory method" dance.

I'm sure these changes made maintenance 10% easier for Amazon, but it must have created tens of thousands of man-hours of unnecessary work downstream (assuming the SDK v1 EOL moves forward).

I would ask, first, that you not EOL the v1 SDK, and second, that you do not "learn" from the v2 SDK to create a v3 SDK 😄

Ideally both v1 and v2 would be supported (at least for security fixes) until the heat death of the universe, Christ's return, or Amazon's bankruptcy -- whichever comes first.

Have a great weekend!

[debora-ito]

• The number of JARs seems to have exploded. I can't figure out which transitive dependencies I need and don't need, since there's a lot of "batteries included" by default.

In a regular use case you don't have to remove any transitive dependency, we take a lot of things under consideration when including them by default. Also, removing dependencies can cause runtime errors when not made carefully, so we recommend against it. When you look for dependencies you don't need, what is the main concern behind it?

• The class names are all slightly different, rearranged to presumably prioritize internal consistency over downstream impact (BasicAWSCredentials -> AwsBasicCredentials, AWSStaticCredentialsProvider -> StaticCredentialsProvider, etc).
• Once you do find the correct class, you inevitably must perform either the "constructor -> builder" dance or the "constructor -> factory method" dance.

We understand that a lot of manual work can go into the migration. To assist with the code migration we released a Migration Tool that uses OpenRewrite to automate the refactoring from 1.x code to 2.x code. It is currently under preview release, and transformation of some clients are not supported yet (like AmazonS3Client, TransferManager and DynamoDB Mapper). There's more information in the Developer Tools Blog Post and in the Developer Guide, including steps to execute the tool and a list of current limitations. We encourage you to try it out, all feedback is welcome.