蘇州JAVA中級(jí)培訓(xùn)學(xué)費(fèi)?

蘇州JAVA中級(jí)培訓(xùn)學(xué)費(fèi)

2017 年夏天，Oracle（Sun 公司早已被 Oracle 收購(gòu)）表達(dá)了想要開源 Java EE 的意圖，緊接著又宣布希望將 Java EE 移交給 Eclipse 基金會(huì)管理，這被很多開發(fā)者認(rèn)為是 Java EE 發(fā)展的重要里程碑之一。因?yàn)楹竺孢@些年，Java EE 的開發(fā)已經(jīng)跟不上時(shí)代變化，并且迭代速度已經(jīng)到了讓人難以忍受的地步。這也許是 Oracle 求變的方式之一。

緊接著在 2017 年的 10 月，Eclipse 基金會(huì)表示正準(zhǔn)備將 Java EE 基于 Eclipse Public License 2.0 許可協(xié)議，并作為 Eclipse Enterprise for Java（EE4J）項(xiàng)目進(jìn)行開源，包括 Oracle、RedHat、IBM 等項(xiàng)目都會(huì)參與其中。

但是，接下來的進(jìn)展看起來并不好，也在意料之中，在我（InfoQ 編輯）理解來看沖突還主要是 Oracle 商業(yè)利益以及開源社區(qū)之間。其實(shí)，Oracle 在 2017 年 9 月宣布將 Java EE 所有權(quán)轉(zhuǎn)交給 Eclipse Foundation 時(shí)，曾明確表示希望 Java EE 重命名。

Java EE 守護(hù)者也擔(dān)心 Oracle 會(huì)限制使用 EE4J 中的“Java”和“javax”相關(guān)的包名（不了解的同學(xué)可以看看 Google 和 Oracle 的官司）。聊聊架構(gòu)也報(bào)道了 Java EE 將會(huì)重命名為 Jakarta EE 的消息，并且為了避免法律風(fēng)險(xiǎn)，包換也有可能會(huì)對(duì)應(yīng)更換，甚至包括類和接口（還沒有得到確認(rèn)，還在討論中）。

前段時(shí)間，Java EE 守護(hù)者 Jean-Fran?ois James 撰寫了系列文章，來探討未來 Java EE 的發(fā)展方向，InfoQ 為了幫助大家了解這個(gè)項(xiàng)目目前的進(jìn)展以及狀態(tài)，同步進(jìn)行了翻譯。以下為全文。

據(jù) Oracle 的 Java EE 布道師 David Delabassee 透露，Oracle 之所以要開源 Java EE，主要是想讓它變得更敏捷，以適應(yīng)快速發(fā)展的行業(yè)和技術(shù)需求。

事實(shí)上，盡管 JCP（Java Community Process）也在這方面做出了一些努力，但仍然無法趕上現(xiàn)代 IT 市場(chǎng)快速發(fā)展的步伐。從 2013 年 6 月發(fā)布 Java EE 7 以來，出現(xiàn)了很多新興技術(shù)，比如 NoSQL、容器、微服務(wù)和無服務(wù)器架構(gòu)，但它們都未能被包含在 Java EE 當(dāng)中。

在我看來，這一決定顯得有點(diǎn)唐突，因?yàn)樗c Oracle 在 JavaOne 2016 上發(fā)布的路線圖完全背道而馳。

當(dāng)然，這一決定也表明了 Java EE 不再是 Oracle 的首要關(guān)注點(diǎn)。Oracle 似乎把更多的注意力放在新的開源項(xiàng)目 Fn 上，F(xiàn)n 是一個(gè)無服務(wù)器框架，類似亞馬遜的 Lambda 和 IBM 的 OpenWhisk（現(xiàn)在是 Apache 項(xiàng)目）。

2017 年 9 月 21 日，Java EE 正式發(fā)布。我們先來看看 Java EE 8 的主要變更。具體如下：

• 與 Java SE 8 同步：DateTime API、CompetableFuture 和可重復(fù)注解。

• CDI 2.0：異步事件、事件保序以及與其他規(guī)范更好的集成。

• Servlet 4.0：支持 HTTP/2（服務(wù)器端推送）。

• JAX-RS 2.1：服務(wù)器端發(fā)送事件、反應(yīng)式擴(kuò)展。

• JSON Processing 1.1 和 JSON Binding 1.0。

• 安全：簡(jiǎn)單化、秘鑰管理、現(xiàn)代化、OAuth2 和 OpenID 支持。

總的來說，Java EE 8 更像是大躍進(jìn)，而不是小步快跑。不過，云原生相關(guān)應(yīng)用并沒有包含在 Java EE 8 中，如分布式跟蹤、集中式配置、健康監(jiān)測(cè)、回路斷路器、負(fù)載均衡。

對(duì)于大多數(shù)企業(yè)來說，Java EE 仍然是一個(gè)非常有價(jià)值的平臺(tái)：

• 完善而靈活的編程模型。

• 單一的依賴管理：通常一個(gè) Maven 的 pom.xml 不會(huì)包含超過 20 行配置代碼，即使項(xiàng)目很復(fù)雜。

• CDI 易用且強(qiáng)大。

• 可以與大多數(shù) IDE 集成。

• 有很多輕量級(jí)的應(yīng)用服務(wù)器，比如 TomEE、Payara、Red Hat Wildfly 和 IBM Liberty，它們不僅啟動(dòng)速度快，而且占用資源小。

• 可以使用 Java EE 來開發(fā)容器化的微服務(wù)，雖然不完美，但也不失為一種選擇。

在我看來，Java EE 的不足在于：

• 不夠先進(jìn)：盡管它還有一定的價(jià)值，但大部分開發(fā)者并不會(huì)將它作為開發(fā)云原生應(yīng)用的**。

• 因?yàn)榻M件模型的差異，缺乏整體的一致性：Servlet、CDI、EJB……確切點(diǎn)說，CDI 和 EJB 之間的界限有點(diǎn)模糊，或許 CDI 在未來會(huì)成為“**類公民”。

• 測(cè)試相對(duì)復(fù)雜。

• 規(guī)范及其實(shí)現(xiàn)的演進(jìn)速度較慢。

• 與 Java SE 不同步：要想在 Java EE 中看到 Java 9 的模塊化系統(tǒng)尚需時(shí)日。

Oracle 的決定給整個(gè) Java EE 生態(tài)系統(tǒng)帶來重大影響。

作為 Java 技術(shù)（包括 Java EE）和品牌的所有者，Oracle 仍然會(huì)繼續(xù)負(fù)責(zé)維護(hù) Java EE 8。

但這種所有權(quán)在品牌和未來的技術(shù)發(fā)展方面存在一些限制，比如：

• 不能再使用 Java EE 作為品牌名稱。

• 在新名稱中使用 Java 要經(jīng)過多方討論和允許。

• 不能再使用 javax 包名。

JCP 旨在“為 Java 技術(shù)制定標(biāo)準(zhǔn)技術(shù)規(guī)范”。但 JCP 幾乎為 Oracle 所掌控：項(xiàng)目管理辦公室、選舉、投票、規(guī)范管理等等。從組織角度來看，JCP 是開放的，它歡迎任何人加入，IBM 和 Red Hat 就是非常重要的成員。同時(shí)，JCP 涵蓋了 Java EE 中的很多規(guī)范，如 Servlet、EJB、CDI、JAX-RS……

其中每個(gè)規(guī)范都是以 JSR（Java Specification Request）的形式進(jìn)行管理的（比如 Java EE 8 對(duì)應(yīng) JSR 266，Servlet 4.0 對(duì)應(yīng) JSR 369，CDI 2.0 對(duì)應(yīng) JSR 365，CDI 2.1 對(duì)應(yīng) JSR 370），并由專家組負(fù)責(zé)管理每個(gè)規(guī)范的生命周期。

專家組要交付三個(gè)方面的內(nèi)容，包括規(guī)范文檔、規(guī)范的參考實(shí)現(xiàn)以及測(cè)試套件。

從外部來看，這個(gè)流程太過笨重：從規(guī)范的啟動(dòng)到**終發(fā)布需要很長(zhǎng)時(shí)間，而應(yīng)用服務(wù)器實(shí)現(xiàn)規(guī)范也需要一些時(shí)間。

從內(nèi)部來看，作為 JCP 的成員，我不得不承認(rèn)，JCP 的監(jiān)管質(zhì)量和人們的投入程度給我留下了深刻印象。或許它的步子邁得不夠快，但話說回來，在制定一個(gè)標(biāo)準(zhǔn)時(shí)，創(chuàng)新又占有多大比重呢？

EE4J **為成功的一個(gè)方面在于它的敏捷性，它能夠很快建立起強(qiáng)壯且靈活的監(jiān)管模型。

Java EE Guardians 由“一群致力于**社區(qū)和擁護(hù)者來推動(dòng) Java EE 平臺(tái)發(fā)展的草根組成”。Reza Rahman 在 2015 年成立了 Java EE Guardians，旨在催促 Oracle 重啟 Java EE 8，因?yàn)楫?dāng)時(shí)的 Java EE 8 處于停滯狀態(tài)。

該組織目前專注于保護(hù) Java EE 品牌和 javax 包，讓它們得以延續(xù)，他們?cè)?2018 年 1 月份發(fā)表的一封公開信中說明了他們的目的。具體如下：

https://javaee-guardians.io/2018/01/02/joint-community-open-letter-on-java-ee-naming-and-packaging/

Microprofile 把自己定義成“一個(gè)基準(zhǔn)平臺(tái)，以微服務(wù)架構(gòu)為基準(zhǔn)來優(yōu)化企業(yè)版 Java，并交付可在多個(gè) Microprofile 運(yùn)行時(shí)上運(yùn)行的應(yīng)用程序”。它從 2016 年夏天啟動(dòng)，現(xiàn)在已經(jīng)成為了 Eclipse 的項(xiàng)目，**初貢獻(xiàn)者包括 TomiTribe、IBM 和 Payara，Oracle 也在 2017 年 11 月加入其中。

Microprofile 的**個(gè)版本在 JavaOne 2016 上發(fā)布，涵蓋了 JAX-RS 2.0、CDI 1.2 和 JSON-P 1.0。

從那以后，社區(qū)同時(shí)開始了多個(gè)項(xiàng)目，包括：

• microprofile-config

• microprofile-fault-tolerance

• microprofile-health

• microprofile-metrics

• microprofile-open-api

• microprofile-jwt-auth

Microprofile.io 的**初目標(biāo)是專注于 JCP 標(biāo)準(zhǔn)的快速創(chuàng)新，而現(xiàn)在也可以被認(rèn)為是 EE4J 在社區(qū)、組織和監(jiān)管方面的“POC（概念性驗(yàn)證）”。

Microprofile.io 的未來將去向何處？與 EE4J 合并抑或是繼續(xù)保持獨(dú)立？現(xiàn)在還沒有定論。

EE4J 的章程上寫道：“Eclipse Enterprise for Java（EE4J）是一個(gè)開源倡議，旨在建立和實(shí)現(xiàn)標(biāo)準(zhǔn) API，為 Java 運(yùn)行時(shí)提供技術(shù)工具，促進(jìn)服務(wù)器端和云原生應(yīng)用的開發(fā)、部署和管理。EE4J 以 Java 平臺(tái)和 Java EE 標(biāo)準(zhǔn)為基礎(chǔ)，并在 Java EE 8 的基準(zhǔn)上建立新的標(biāo)準(zhǔn)”。

需要注意的是，EE4J 只是項(xiàng)目的名稱，而不是一個(gè)品牌。2017 年 11 月份，他們?yōu)閷ふ液线m的品牌名稱進(jìn)行過一次問卷。但因?yàn)槭艿缴鲜龅囊恍┫拗?，至今未達(dá)成共識(shí)。不過，社區(qū)當(dāng)中有 79% 的人似乎希望能夠保留 Java EE 這個(gè)品牌。

2017 年 11 月，項(xiàng)目管理委員會(huì)成立，成員來自原先的 Java EE 生態(tài)系統(tǒng)。委員會(huì)的首要任務(wù)是完成過渡、建立新的社區(qū)，以及基于 Java EE 8 發(fā)布**個(gè)版本。

目前有兩個(gè)項(xiàng)目正式成為 EE4J 的一部分：

• Yasson：JSON-B 的參考實(shí)現(xiàn)。

• EclipseLink：JPA 的參考實(shí)現(xiàn)。

對(duì)于 Java EE 廠商（Red Hat、IBM、TomiTribe 和 Payara）來說：

• 他們?cè)?JCP 中將擁有更多的話語權(quán)和影響力。

• 他們可以自由地訪問測(cè)試套件，而之前它是屬于 Oracle 的。

• 他們可以迭代推出“應(yīng)用服務(wù)器”，不需要再承受 Java EE 新版本發(fā)布的“隧道效應(yīng)”所帶來的痛苦。

新的 Java EE 會(huì)成為“保護(hù)傘”抑或是由一系列獨(dú)立的規(guī)范組成？

由此引申出的問題是：應(yīng)用服務(wù)器會(huì)繼續(xù)扮演“單體平臺(tái)”的角色，還是會(huì)變成可組合的模塊平臺(tái)？

我傾向于選擇第二種可能，Red Hat 的 Wildfly Swarm 就是**的例子。

對(duì)于開發(fā)者社區(qū)來說，這是一個(gè)很好的機(jī)會(huì)，他們需要一個(gè)敏捷的平臺(tái)來促進(jìn)創(chuàng)新。

對(duì)于開發(fā)者個(gè)人而言，參與 EE4J 是一個(gè)非常好的提升個(gè)人影響力的途徑。

對(duì)于用戶來說，目前的處境很艱難。Java EE 的優(yōu)勢(shì)在于一系列由 JCP 推動(dòng)的官方標(biāo)準(zhǔn)，而依賴這些標(biāo)準(zhǔn)對(duì)于長(zhǎng)期項(xiàng)目來說是至關(guān)重要的。

Java EE 的上一個(gè)階段已經(jīng)走到了尾聲，不管高興與否，我們都要繼續(xù)與它共同前行。新的 Java EE 標(biāo)準(zhǔn)將為我們帶來什么？沒有了 JCP 的支持，EE4J 將如何發(fā)展？

這一切要取決于行動(dòng)的快慢和實(shí)際結(jié)果的產(chǎn)出。我粗淺地認(rèn)為，這將受到以下幾個(gè)因素的影響：

1. 時(shí)間：之前已經(jīng)提到，盡管 Java EE 8 仍有它的價(jià)值，但它并不是**先進(jìn)的，所以它需要盡快縮小差距，以便在競(jìng)爭(zhēng)中勝出。如果 EE4J 要花幾個(gè)月“才能”交付一個(gè)版本，那么要實(shí)現(xiàn)這個(gè)目標(biāo)就會(huì)很困難。

2. 與 Microprofile.io 協(xié)作：Microprofile.io 已經(jīng)在云原生應(yīng)用方面發(fā)力，所以完全可以利用它，把它集成到 EE4J 中。

3. 社區(qū)：EE4J 社區(qū)將發(fā)展壯大到怎樣的程度？

4. 還是時(shí)間：廠商和開源項(xiàng)目是否有能力及時(shí)交付符合 EE4J 規(guī)范的平臺(tái)？Java EE **大的一個(gè)問題就是從規(guī)范**終版的發(fā)布到應(yīng)用服務(wù)器的實(shí)現(xiàn)需要很長(zhǎng)的時(shí)間。

不過，就像昨天文章中評(píng)論的那樣，不管名字是否改變，面對(duì) Spring 框架的強(qiáng)力沖擊，Java EE 路在何方，現(xiàn)在還不好說。從目前社區(qū)熱點(diǎn)來看，我只知道，Spring Boot、Spring Cloud 這套框架很受歡迎。

對(duì)于 Spring 生態(tài)和 Java EE 的關(guān)系，Jean-Fran?ois James 也做了評(píng)論（另外一篇文章）。

在之前評(píng)估 Java EE 生態(tài)系統(tǒng)對(duì) EE4J 發(fā)展的影響時(shí)，我漏掉了一個(gè)非常重要的因素：Pivotal 和它的 Spring 框架。

Java EE 和 Spring 之間的關(guān)系已經(jīng)進(jìn)入了“**的敵人”模式。

Spring 誕生于 2004 年，由 Rod Johnson 發(fā)起，作為對(duì) J2EE（Java 2 Platform，Enterprise Edition）和 EJB 2 復(fù)雜性的反擊。從那個(gè)時(shí)候開始，Spring 和 Java EE 之間就沒有停止過競(jìng)爭(zhēng)，并彼此影響對(duì)方：

• Spring（以及 Hibernate）的出現(xiàn)刺激了 Java EE 社區(qū)，促使他們推出了 EJB 3 和 JAP 1.0。

• Spring Batch 直接影響到了 Batch 規(guī)范（JSR 352）。

• Spring Dependency Injection 啟發(fā)了 CDI（Context and Dependency Injection）。

• Spring 恰到好處地使用了 J2EE 和 Java EE 中的某些標(biāo)準(zhǔn)，如 Servlet、JMS 和 JPA。

• Spring 5 宣稱兼容 Java EE 8。

從誕生之日起，Spring 就因?yàn)槌瑥?qiáng)的實(shí)用性受到了開發(fā)者的青睞，而且它的演進(jìn)速度很快，可以快速地集成新技術(shù)：NoSQL、AMQP、微服務(wù)、云原生應(yīng)用……

從 2006 年開始，Java EE 也將提升易用性和對(duì)開發(fā)者的友好放在首位，但在演進(jìn)速度方面還是很慢，主要有兩個(gè)原因：

1. JCP 制定規(guī)范需要很長(zhǎng)時(shí)間：即使是一個(gè)輕量級(jí)的規(guī)范，也需要多方參與，需要更長(zhǎng)的時(shí)間才能達(dá)成一致。

2. 實(shí)現(xiàn)和認(rèn)證：在規(guī)范發(fā)布之后，需要幾個(gè)月時(shí)間才能找到符合認(rèn)證的應(yīng)用服務(wù)器。

而**近，這方面的差距在加大：

• Spring Boot 將“以約定代替配置（Convention Over Configuration）”的原則發(fā)揮到了極致，進(jìn)一步提升易用性。

• Spring Cloud 利用 Netflix 的開源組件解決了與云原生應(yīng)用開發(fā)相關(guān)的問題，如服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)、彈性、負(fù)載均衡、監(jiān)控……

• Spring 5 將反應(yīng)式編程提升為一等公民。

Java EE 在這方面的速度要慢的多。在 2013 年發(fā)布 Java EE 7 之后，經(jīng)歷了一段消停期。2016 年，在社區(qū)的壓力下，Oracle 才發(fā)布了一個(gè)新的路線圖。

Java EE 8 發(fā)布于 2017 年 9 月，雖然人們對(duì)其期望甚高，但并非革命性的。人們還是把更多的目光投向了 Java EE 9，期望下一個(gè)版本會(huì)有更多的創(chuàng)新。

與此同時(shí)，Eclipse 基金會(huì)于 2016 年中啟動(dòng) Microprofile.io 項(xiàng)目，旨在以微服務(wù)架構(gòu)為基準(zhǔn)來優(yōu)化企業(yè)版 Java，以此來推動(dòng) Java EE 生態(tài)系統(tǒng)的發(fā)展。Microprofile 1.0 涵蓋了 JAX-RS 2.0、CDI 1.2 和 JSON-P 1.0，1.2 版本于 2017 年 9 月發(fā)布，加入了更多特性，如配置、容錯(cuò)、JWT、度量指標(biāo)和健康檢測(cè)，2.0 版本有望與 Java EE 8 看齊。

EE4J 旨在提供一種更加靈活的協(xié)作方式，但要成功，有一些前提是不可或缺的：

• Java EE 8 遺留資產(chǎn)的轉(zhuǎn)移（規(guī)范文檔、參考實(shí)現(xiàn)和測(cè)試套件）。據(jù) David Delabassee 所述，這項(xiàng)工作已經(jīng)在進(jìn)行當(dāng)中。

• 建立新的監(jiān)管模型和操作系統(tǒng)，在**近發(fā)布的工作組章程中已經(jīng)提到了這一點(diǎn)。

• 建立活躍的社區(qū)。

• 品牌和包的重新命名：Oracle 不允許 EE4J 在新規(guī)范中重用“Java EE”這個(gè)商標(biāo)和 javax 這個(gè)包名，所以需要重新起一個(gè)名字。

在滿足了這些條件之后，EE4J 就可以繼續(xù)演進(jìn)，適應(yīng)云原生應(yīng)用和 Java SE 平臺(tái)（特別是 Java 的模塊化系統(tǒng)）的變更。

除了監(jiān)管和技術(shù)之外，EE4J 必須為自己找到合適的位置，因?yàn)闆]有了 JCP 的支持，它作為標(biāo)準(zhǔn)的地位就不復(fù)存在。在這樣的情況下，EE4J 已無力與 Spring 展開競(jìng)爭(zhēng)?；蛘哒f，整個(gè) Java 生態(tài)系統(tǒng)經(jīng)不起這樣的“內(nèi)戰(zhàn)”。Java 在應(yīng)用服務(wù)器方面的霸主地位已經(jīng)一去不復(fù)返，它必須與其他平臺(tái)展開競(jìng)爭(zhēng)，比如 Node.js、Go 和 Python。如果能夠?qū)⒄麄€(gè)社區(qū)甚至整個(gè)行業(yè)的力量帶動(dòng)起來，那就更好了。

為什么不呢？如果 EE4J 能夠推出一些獨(dú)立的兼容規(guī)范，Spring 團(tuán)隊(duì)就可以參與進(jìn)來，讓 Spring 成為 EE4J 的主要參與者。

咨詢聯(lián)系方式：13861302024(楊老師)或者QQ：2589245390 還可以直接在線咨詢

更多JAVA課程推薦：

蘇州JAVA培訓(xùn)網(wǎng)

蘇州JAVA軟件培訓(xùn)

蘇州三網(wǎng)IT教育培訓(xùn)

蘇州其然軟件開發(fā)培訓(xùn)