S3 and AWS Java SDK 2.0: Look Before You Leap

Introduction

Back in mid-2017, Java developers everywhere were given access to a preview of the long-awaited v2 of the AWS Java SDK.

Time passed.

A little over a year went by with several revisions being made available before Amazon published the GA release of the new SDK, and there was much rejoicing.

But not all was well in AWS land.

The Issue

If you've ever made use of S3 via any SDK, then you know that a fundamental part of integrating the service is the creation of pre-signed URLs.

These pre-signed URLs are handed back to an application via AWS and allow for the safe and secure upload/access of files in a specified S3 bucket. After all, you don't want just anyone rooting around (weak pun intended) in your buckets, especially if that bucket contains sensitive files or data.

Of course, this particular feature is well documented in the AWS SDK and is used extensively, as one might imagine.

Inexplicably, however, Amazon decided not to include that particular feature in v2 of its AWS Java SDK.

Say What?

As of the writing of this article, this particular omission is still an open issue, much to most integrators' chagrin. You can read the thread/debacle as it's progressed since it was first raised in 2017.

Yes, that's right: It's been a known issue for two years.

Now, I don't work at Amazon, and I certainly don't know all the ins and outs of their development cycle or feature prioritization process, but given the fundamental nature of this particular feature of the S3 SDK, it seems a rather odd item to neglect for such a lengthy period of time.

Workarounds

Really, there are two options:

1. The link above (re-linked here) includes ideas and code to enact a workaround, although it isn't officially sanctioned or guaranteed to include all the same options and features of the pre-signed URL feature.

2. Rollback to AWS Java SDK v1.x and stay safe until Amazon finally releases an updated v2 SDK that contains the full version of the pre-signed URL feature.

One of the workarounds above should handle your particular case.

That said, my personal opinion is to go with the second option in order to avoid any potential pitfalls involved with using unofficial workaround code. Of course, if you're midway through a migration/implementation with v2.0 of the AWS Java SDK elsewhere, this might not be a viable route.

Conclusion

Given how common S3 is used as part of any AWS integration, it would be extremely prudent to consider the points raised in this article before migrating from v1.x of the SDK to 2.0, or in choosing a version of the AWS Java SDK to use for a new project.

There's nothing worse than getting knee-deep into a project, only to find out you now have to make a critical decision that could potentially cause serious delays.

Hopefully, the relevance of this article is short-lived, but until then, I hope the points raised in this article help save some developers from entering a sticky situation.