quarkusio / quarkus

Quarkus: Supersonic Subatomic Java.
https://quarkus.io
Apache License 2.0
13.54k stars 2.61k forks source link

AWS SDKv2 now supports GraalVM #15652

Open oztimpower opened 3 years ago

oztimpower commented 3 years ago

Description The AWS SDKv2 now has integration with GraalVM and can generate the required reflect and resource config automatically.

https://aws.amazon.com/blogs/developer/graalvm-native-image-support-in-the-aws-sdk-for-java-2-x/

Implementation ideas

Would it make sense then to have one quarkus-aws-sdk2 module that incorporates this and let users pick and choose which AWS components they want, instead of creating a Quarkus extension for each? Common registration of the AWS credentials is already in place, and perhaps via a Quarkus-AWS property the required services such as S3 or KMS could register the CDI client beans?

There's an opportunity for refactoring?

/cc @patriot1burke /cc @gsmet /cc @marcinczeczko

drissamri commented 3 years ago

This would be very cool, there's quite a bit of features unsupported in the current extensions (example: https://github.com/quarkusio/quarkus/issues/12168) this would probably solve that

patriot1burke commented 3 years ago

I don't see a difference from specifying one artifact, 'quarkus-aws-sdk2', and specifying what features you want in app.props

vs.

specifying the mvn artifact for each feature you want. The latter creates smaller JDK-based deployments. So my vote would be to keep it the way it is.

I'm not sure the new AWS SDK will help us with Lambda. We have to override JSON parsing because we need to have a wrapper lambda so we can do things like injection. I also need to know how they handle executables.

drissamri commented 3 years ago

I don't mind one or multiple artifacts, I do think its important that we can leverage all the SDKs and features in GraalVM without having to provide extra settings or extensions if its already supported in the framework? I think that's the main point of @oztimpower

If the SDK provides GraalVM support out of the box for all clients, what has to happen now in Quarkus to use them if there is not a specific quarkus extension (AWS IOT, AWS EventBridge, ...?) and/or if the extension does not provide all support (like Enhanced DynamoDB Client in amazon-dynamodb quarkus extension)

I'm not sure the new AWS SDK will help us with Lambda. We have to override JSON parsing because we need to have a wrapper lambda so we can do things like injection. I also need to know how they handle executables.

This is only if you want to be invoked from certain event source, but if you want to use certain SDKs during your invocation as a client this is completely separated right? It's more important to be able to use the clients than be invoked by all event types (which is also useful but less critical imho)

patriot1burke commented 3 years ago

I'm saying that its probably NOT as simple as "Hey if we include the new SDK everything will work on Graal". We also need to investigate exactly what they've done as their graal switches might not be compatible with what Quarkus is doing. Quarkus pushes a lot to static init by default, for example.

geoand commented 1 year ago

@patriot1burke is there anything more to do on this ticket or should we close it?

quarkus-bot[bot] commented 1 year ago

/cc @aloubyansky(extension-proposal), @gastaldi(extension-proposal), @gsmet(extension-proposal), @maxandersen(extension-proposal)

yrodiere commented 1 year ago

@patriot1burke is there anything more to do on this ticket or should we close it?

@patriot1burke Bump :)