Java 无反射的春天

是否可以用其他依赖项注入工具替代默认Spring框架通过反射创建和管理对象的方式（这会更快，因为这样可以避免反射），同时仍然保持Spring的富API

例如，我希望Dagger 2或Tiger或Feather创建的bean仍然能够与Spring Data/Social/MVC交互

我知道有人会说“当性能成为问题时，就开始担心性能”——好吧，我会说现在是时候开始担心它了

在我的选择中，它将允许Spring接受FaaS（作为服务的功能）。FaaS jvm将在服务于它的调用后关闭，所以您要么让它继续运行（像普通服务器一样），并每毫秒支付一次费用，要么某些调用可能会延迟几秒钟（以启动所有东西）

我发现了两个项目，它们试图在FaaS环境中使用Spring，并且正在解决这个问题，但是在我的选择中，更容易消除问题（反射），尝试用黑客来克服它

或者，也许有另一种方法可以解决这个问题，并在FaaS中有效地使用Spring，但我不知道

相关问题：

---

我一直在尝试使用最小的Spring框架应用程序（如3-5个类），但处理第一个请求（下一个请求在50-100ms内处理）仍然需要（有时）5-15秒，因此在这种情况下，最小化并不是真的起作用。

我在同一条船上，试图为JVM找到一个FaaS友好的DI框架。因为在JVM上没有什么能比得上Spring生态系统，所以如果Spring有无反射机制和编译时DI就更好了。不过，在这方面我找不到太多

解决完全相同的问题，看起来很有趣。它有一个用于spring注释的适配器层。Micronaut是专门为使用编译时DI的更快启动而构建的

---

当然，这对于较新的应用程序是有好处的，但对于具有大量现有spring代码库的非常大的应用程序则不是这样。

今天，可以选择创建spring应用程序无反射方法

根据其文件：

Spring Fu是JaFu（Java DSL）和KoFu（Kotlin DSL）的孵化器，设计用于以声明方式使用代码显式配置Spring Boot，由于auto complete，具有很强的可发现性。它提供了快速启动（比最小的Spring MVC应用程序上的常规自动配置快40%）、低内存消耗，并且由于其（几乎）无反射的方法，非常适合GraalVM native

---

注：spring fu不应用于生产

我认为，在正常情况下，spring和DI的很大一部分是使用反射来基于模板创建对象，因此我不确定这是否可行，除非在非常特殊的情况下。如果没有spring，预热需要多长时间？“具有大量现有spring代码库的非常大的应用程序”无论如何都不应该被转换为AWS Lambda，因此这不应该是一个问题。事实上，Micronaut值得一看。奇怪的是，它没有出现在OP的研究中。另请参阅不要只发布链接答案。解释链接与问题的关系。