I have a simple AWS lambda which uses AWS Rekognition Service. I wanted to compile it to GraalVM native image so it would be faster etc. Unfortunately I devoted two days of my life and still couldn't do it - it was written having Graal in the mind - too many reflections, proxy classes, invokes etc - please consider providing support for GraalVM native image
Hello,
Is there any update or plan on this ?
When I try to build a quarkus project containing the AWS Java sdk I get several errors regarding IdleConnectionReaper class.
Thanks.
@jbourbo Yes right now it is not possible to compile it to a native image. See -> https://github.com/oracle/graal/issues/1441
@solveretur Apologies for the long silence here. Although we cannot guarantee the SDK will work with third-party apps, I'm marking this as a feature request.
As the SDK team is actively working in releasing features for the SDK v2.x, we don't have a timeline for when/if this will prioritized.
Hi,
These days there is a strong movement towards serverless architectures and many developers want to leverage AWS Lambda as a first class infrastructure for their big data app. Consider you also want to use other AWS services along which is very natural, so you choose Java as the implementation language because it is the best supported language by AWS sdk(first class support, most mature sdk, DynamoDBMapper etc...).
But when you use the Java in AWS Lambda you hit the cold start problem with the min 3 seconds starting time at 1 GB memory configuration which prevent developers to benefit from Java-Sdk. I think it is time to make your greatest lang Java to be suitable for your most powerful compute service by making AWS-Java-SDK native image compatible.
Native image will make apps fire starting within a couple of miliseconds, sonic execution speed and low memory footprint. This will make you the DeFacto- serverless system provider to work with in cloud business and of course us the developers happy :D.
I strongly agree with @xeard
@debora-ito Any news regarding when or if this will be prioritized?
Sorry, no news to report at this time. We understand the benefits and are aware of this feature request, though.
Id like to bring this back to the top. Trying to get even a simple s3 client running in native is taking longer then one would expect
Everyone who is interested in this feature, be sure to thumbs-up the top comment to emphasize your desire for the SDK team to implement this. It helps with prioritization of this versus other features!
@millems do you need another issue for this regarding aws-sdk-java-v2?
@gustf do you mean ask-java-v2, i.e Alexa? +1 if so.
Yes, been pulling my hair out trying to get the Alexa ask-sdk-v2 to work with Native Image. Got it to work with a reflection-config.json that requires more than 9,000 lines and took more than 35mins to compile. The ask-sdk needs massive refactoring, frankly I don't want to use Node.js et al, as the alternative to a working GraalVM native image.
@oztimpower sorry for the typo, what i meant was https://github.com/aws/aws-sdk-java-v2
@gustf Yes please
I would like this feature
+1
I (finally) created a feature request for v2 a few days ago, if anyone is also interested in this feature in v2. please add a thumbs up on this one also 馃憤
Most helpful comment
Hi,
These days there is a strong movement towards serverless architectures and many developers want to leverage AWS Lambda as a first class infrastructure for their big data app. Consider you also want to use other AWS services along which is very natural, so you choose Java as the implementation language because it is the best supported language by AWS sdk(first class support, most mature sdk, DynamoDBMapper etc...).
But when you use the Java in AWS Lambda you hit the cold start problem with the min 3 seconds starting time at 1 GB memory configuration which prevent developers to benefit from Java-Sdk. I think it is time to make your greatest lang Java to be suitable for your most powerful compute service by making AWS-Java-SDK native image compatible.
Native image will make apps fire starting within a couple of miliseconds, sonic execution speed and low memory footprint. This will make you the DeFacto- serverless system provider to work with in cloud business and of course us the developers happy :D.