Quarkus GraalVM native build fails in AWS Lambda with ClassNotFoundException

Question

I want to create a java project with quarkus and want to use GraalVm for ahead of time compilation to lower cold startup times in AWS lambda.

When I deploy it in AWS Lambda and run Test I get the following error:

Class not found: de.timguy.lambda.GreetingLambda: java.lang.ClassNotFoundException
    java.lang.ClassNotFoundException: de.timguy.lambda.GreetingLambda. Current classpath: file:/var/task/

Steps I took

• Create project: https://code.quarkus.io/?g=de.timguy&a=quark2&b=GRADLE&e=io.quarkiverse.amazonalexa%3Aquarkus-amazon-alexa&e=amazon-lambda&extension-search=lambda

  • Quarkus version: 2.8.2.Final (gradle.properties)

• gradlew build -Dquarkus.package.type=native -Dquarkus.native.container-build=true

Version info: GraalVM 22.0.0.2 Java 11 CE
 3 user-provided feature(s)
  - io.quarkus.runner.AutoFeature
  - io.quarkus.runtime.graal.DisableLoggingAutoFeature
  - io.quarkus.runtime.graal.ResourcesFeature    
Produced artifacts:
 /project/quark2-1.0.0-SNAPSHOT-runner (executable)
 /project/quark2-1.0.0-SNAPSHOT-runner.build_artifacts.txt

Finished generating 'quark2-1.0.0-SNAPSHOT-runner' in 11m 54s.

BUILD SUCCESSFUL in 12m 52s

• AWS - create function "quark2"
  • runtime "Java 11 Coretto"
  • Edit runtime setting: Handler = de.timguy.lambda.GreetingLambda
  • Upload quark2/build/runner.zip via S3
  • Test -> ClassNotFoundException (see complete error at top)

Answer 1

I choosed the wrong runtime setting:

• Lambda -> Code -> runtime settings -> "Custom runtime on Amazon Linux 2" or "Custom runtime" instead of Java11

(Still curios about:

• the 2 different custom runtimes because both of them work. Documentation couldn't help me here
• how does GraalVM / Quarkus know about my target environmet for the ahead of time compiliation?
  • yes, command line tells "native" but which docker image is fetched to build the stuff? )

Answer 2

Quarkus will produce a special zip file when it's targeting AWS Lambda. If you open it you will see a bootstrap file. The bootstrap file is only used with the custom runtimes. The custom runtimes know to execute that when they start up.

If you deploy a native executable to a Java-managed runtime by mistake then the JVM will not be able to find your handler method because it isn't a class on the classpath but a native executable instead.

Quarkus knows how to package your Lambda function this way because you've used the amazon-lambda extension.