转载

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

原文 https://www.oschina.net/news/102602/jakartavoices

正文到此结束