CRT Http Client still in developer preview

[msailes]

Describe the issue

The CRT Http Client is still in developer preview after being released in 2 Apr 2020.

https://github.com/aws/aws-sdk-java-v2/blob/master/http-clients/aws-crt-client/pom.xml#L31

What criteria will be used to determine when this will leave developer preview?

Steps to Reproduce

n/a

Current behavior

n/a

AWS Java SDK version used

n/a

JDK version used

n/a

Operating System and version

n/a

[cenedhryn]

Are you currently using it? We would like to get more feedback/data points on usage.

[drissamri]

I have been using it for over a year, the biggest frustration is the size of the package. It makes my Lambda deployable 2-6x bigger just by adding this dependency

[debora-ito]

We are in constant communication with the CRT Team, planning the next steps of the CRT client in the Java SDK and also across other SDKs. This issue is in our radar.

In the meantime, please send us feedback of how's the experience has been so far, any pain points and what you'd like to see added to the CRT client.

[msailes]

Could a classifier be used to separate different architecture builds and reduce file size? The Amazon Corretto team do this for their crypo provider.

Example:

<dependency>
  <groupId>software.amazon.cryptools</groupId>
  <artifactId>AmazonCorrettoCryptoProvider</artifactId>
  <version>[1.0,2.0)</version>
  <classifier>linux-x86_64</classifier>
</dependency>

[zoewangg]

@msailes yeah, CRT team has plans to distribute platform specific JARs. We will still include the uber JAR in the SDK to provide better onboarding experience, but customers can customize it based on their use-cases.

[adrian-skybaker]

One pain point for us was that it doesn't seem possible to have the CRT on the classpath as an optional opt-in client, while still falling back on the standard client auto-detection logic.

This makes writing a generic library that wants to opt-in to using CRT client difficult - any application using the library then immediately fails to start up unless they start configuring a system property to specify the default.

More broadly however, given the client has been in preview has been for over two years, we're reluctant to invest much time in it. We don't want to be tied to a library that remains in preview for an uncertain period, that's measured in years.

[sebastian-zero]

Another pain point from our perspective, besides the client size that is too large for lambdas, is that the current CRT client only supports async clients and that requires us to rewrite existing sync logic. While it's often just adding .join(), other parts are more complicated to rewrite, e.g. paging logic. In general, we find sync client APIs are much easier to use and still cover most use cases.

[debora-ito]

@sebastian-zero Great feedback, thank you! Can you please open a new feature request for this? We'd like to track it separately.

[msailes]

@sebastian-zero please link in this thread when you make it, I'd like to 👍🏻 . I often call .get() at the end of my Lambda usage.

[sebastian-zero]

@debora-ito and @msailes #3343

[zoewangg]

Hi all, just a quick update, platform-specific CRT JARs are available now (note that it is an experimental feature for now). See https://github.com/awslabs/aws-crt-java#platform-specific-jars-experimental for more formation.

[zoewangg]

Hey all, AWS CRT HTTP client is now generally available. 🎉 Thank you all for your patience! Check out our blog post and Developer Guide for more information. As always, feedback is welcome! 🙂 I'll go ahead and close the issue, feel free to create new issues.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.