使用GraalVM时，Java AWS Lambda的最佳实践是否会改变？

来自AWS Lambda最佳实践文档的两条核心建议：

将部署包大小最小化至运行时所需的必要内容
最小化依赖项的复杂度

我一直在研究quarkus-amazon-lambda和Micronaut 2这类适配AWS Lambda的框架，了解到它们提供并推荐使用对GraalVM友好的轻量库。

我之前创建AWS Lambda的原则一直是尽量减少依赖、缩小工件体积。

我的问题是：在GraalVM原生环境中，上面提到的AWS最佳实践是否仍然适用？还是说因为冷启动曾是主要痛点，现在可以放宽对依赖的限制？

编辑补充：

评论区用户@jarmod提示：

另外请注意，SnapStart可能会改变这一局面。

这确实影响了我的选择，我决定采用Plain Old Java搭配SnapStart。这解决了我当初评估那些框架时最在意的冷启动问题。在我看来，AWS Lambda本质是简单的函数，没必要引入额外依赖。

顺带一提，我看到一篇关于Micronaut框架搭配AWS Lambda SnapStart的文章，里面提到“Hello World”场景下，SnapStart和原生镜像的性能相当，但在加载框架时，原生镜像的速度大概快一倍。虽然这只是个例，但我由此得出结论：小体积jar搭配SnapStart的速度和原生镜像差不多，而大体积jar搭配SnapStart的速度会比原生慢。这让我更倾向于坚持使用Plain Old Java并遵循AWS的最佳实践。

内容的提问来源于stack exchange，提问作者Robert Bain