Jakarta EE 社区之声：CDI 才是 Jakarta EE 的未来

据 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 社区的第一幕。