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