Jakarta EE社区之声：CDI 才是Jakarta EE的未来
据ofollow,noindex">eclipse 报道，在今年10月的 CodeOne 和 EclipseCon 之前，Jakarta EE 指导委员会发出呼吁，要求社区分享他们对 Jakarta EE 未来的个人愿景。社区没有让人失望。
27位 Jakarta EE 梦想家共收到超过70个简短的书面回答，回答了7个问题。
最响亮和最详细的答案围绕着将 CDI 推向平台范围内 Jakarta EE 的远角，作为所有规格的单一且唯一的组件模型。在27个声音中，绝大多数人都表达了他们对 CDI 如何统治Jakarta EE 世界的愿景。 Payara的史蒂夫·米利奇（Steve Millidge）说得很好，“所有的规范都需要协同工作来整合CDI作为基线 bean 模型，这将推动复杂性和重复，使 Jakarta EE 平台更加轻量级，内部一致。”
可以改变采用或利用CDI的平台的特定领域包括：
-
JMS 允许消息被 EJB 消息驱动 Bean 以外的组件使用。Reza Rahma n指出：“创建基于CDI的JMS监听器的工作始于JMS 2但从未完成” 。
-
根据 Markus Karg 的说法，JAX-RS提交者“希望摆脱古老的JAX-RS DI技术，并用CDI代替它”，Sebastian Dashner，Emily Jiang和其他几个项目成员也对此表示赞同。Santiago Pericas-Geertsen指出 CDI bean 目前可以利用 JAX-RS，但“两个注入框架的组合会产生一些难以解决的丑陋边缘情况”，例如应该处理构造函数注入。
-
“JCA 是一个非常强大的 API，用于连接到许多不同的企业系统”，Steve Millidge 指出，在CDI 上重新调整它可以实现与 Apache Kafka 或 Cloud Messaging 系统等系统的更好连接。在其他答案中注意到，尽管 JCA 在 Java EE 7 中得到了极大的改进，但它与 MDB 相关联，MDB 没有明确定义的生命周期并且需要 EJB。
-
“EJB和CDI在许多领域都是多余的，最终将EJB规范中缺少的和必要的部分构建到CDI中会很好，这样EJB就可以逐步淘汰” Josh Juneau回答道。一些社区的声音呼应了积极的情绪。
虽然对CDI的热爱是明确的，但Mark Struberg和规范负责人Antoine Sabot-Durand警告说，CDI不应该成为下一个EJB，CDI的SPI应该被用来进行这些集成。Sabot-Durand补充说，他对CDI演进的看法涉及清除SPI，“还可以专注于更多的异步支持，看看如何增强CDI事件以使其更强大。”
Eclipse Vert.x 的Clement Escoffier非常关注将强大的异步支持推向CDI的热情，尽管他是“CDI新手甚至是CDI noob”但他认为CDI可以接受反应，并表示他致力于帮助它实现目标。Escoffier说，这将是一项工作，但“没有挑战，生活将无聊”。
Laird Nelson分享了CDI本身的一些激进想法，表明CDI可以成为引导服务器的权威API，允许开发人员控制public static void main，包括“将命令行参数标准化传播到CDI环境中”。类似的命令行参数思想浮现在Eclipse MicroProfile Config项目周围，这是一个很好的东西。
从应用程序框架到服务器框架
有一点很清楚。为了使所有这些规范与 CDI 保持一致，实施者将被迫使用SPI将其代码重新编码为CDI扩展。CDI将从开发人员使用的API转换到用于构建服务器的API，使其成为Jakarta EE的SystemD和SysV，迫使它解决类似的问题，例如扩展启动顺序。
我们会看到 CDI 从 DI 框架扩展到内核吗？很可能。
如果 CDI 成为我们未来的服务器构建框架，那将是因为所有 27 个社区的声音都指向了2018年的 CDI，并且作为 Jakarta EE 社区的第一幕。