Instructions on how to deploy without GraalVM

[lxwbr]

Please provide instructions on how to deploy and run such a Lambda if not using GraalVM but the jar file using sbt-assembly

[mbelikov]

Is this one not sufficient?

[stub22]

I think the hidden question comes after the Java code is deployed as .zip:
Whether+how zio-lambda can fit into the AWS Lambda standard runtime setup with AWS default JDK v11 Coretto?
If it cannot, then how should we setup an appropriate custom runtime?

zio-lambda seems designed mainly to run its own event loop in "Custom runtime" mode of AWS Lambda.
This Scala class has a comment saying it is "The main class to use ZLambda as a Layer":
https://github.com/zio/zio-lambda/blob/master/lambda/src/main/scala/zio/lambda/internal/ZLambdaAppReflective.scala

Alrighty then, but ZLambdaAppReflective is a .main() App that expects to be the boss of its own JVM, which I think implies that under AWS Lambda it needs to be launched as a "Custom runtime". (I am not an expert on the custom runtime stuff, and that's why I am interested in this github issue!).

If that's correct, then it's not obvious how launching the "Custom runtime" app best intersects with the idea of a Java "Layer" in Lambda that is uploaded as a .zip. Do we have to supply our own JDK image, or can we use AWS builtin Java-11 Coretto? This page mentions custom-runtime right at the top, but it's not obvious exactly how to do this for our Java+Scala-based runtime.
https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html
This is where I think some additional instructions would be very helpful.

Alternatively, a relatively easy way to use .zip Java Layers is with the AWS standard Lambda runtime for the Java-11 Coretto JVM. In this approach we just deploy some Java library .zips and then tell AWS Lambda (e.g. through the AWS Console GUI) the name of a Handler class that implements com.amazonaws.services.lambda.runtime.RequestHandler. But that is not what ZLambdaAppReflective is for, and it's not obvious how the zio-lambda mechanisms would come into play in this approach.

[heaven-born]

It is not obvious to me what the practical difference between uploading the function as a lambda Layer is, but what I managed to understand is that we kind of need a runtime for the Java-11 Coretto JVM to deploy the layer, but not because we need the runtime itself, but only because this runtime image provides the java installed. The layer doesn't work if you deploy it to a custom AL2 runtime, because there is no JVM in there. It also doesn't work if you just deploy the layer to Java-11 Coretto runtime, because this runtime doesn't lunch the bootstrap provided inside the layer package. So the trick is to create a lambda function based on Java-11 Coretto JVM runtime and then change this runtime to "Custom". It looks like this "Custom" means something else than the custom runtime when we create a function. Looks like it means something like "use the current image (with java installed), but run bootstrap files provided in zip files"