Java7、Java8新特性瞭解
1999 年，Sun 正式釋出了 J2EE 的第一個版本。但從 1999 年誕生的第一個 J2EE 版本一直到 J2EE 1.4 版本，雖然它已經具有了強大的功能，但仍不太被人們接受。這是因為連實現一個簡單的 J2EE 程式，都需要大量的配置檔案，非常不便使用。在 2002 年，J2EE 1.4 推出後，複雜程度更是達到了頂點，尤其是 EJB 2.0，開發和除錯的難度非常大。
2006 年 5 月份 Sun 正式釋出了 J2EE 1.5（現改名為 Java EE 5）規範，Java EE 5 的主基調為“簡化開發”。即讓開發者能夠更方便、高效地使用 Java EE 技術。從 Java EE 5 開始，通過引入註釋、EJB 3.0 的業務元件、更新的 Web 服務和加強的持久化模型，將重心轉移到提高開發人員的生產力上來。
Java EE 6 進一步簡化開發流程，增加平臺的靈活性，從而更好地解決輕量級 Web 應用程式。此外，Java EE 6 開始與開源架構進行無縫整合，並對現有的技術做了精簡。實踐證明，Java EE 6 取得了巨大成功，成功的原因主要有下面幾點：
- 截至 2013 年 5 月，已有超過 50 萬人次從 Oracle 和其他行業的產商下載 Java EE 元件；
- 是企業開發人員的第一選擇；
- 是應用開發平臺的第一選擇；
- 18 家應用伺服器供應商以最快的速度相容 Java EE 不同版本。
圖 1. Java EE 7 新特性
Java EE 7 擴充套件了 Java EE 6，利用更加透明的 JCP 和社群參與來引入新的功能，如圖 1（本圖引用自 Java 官網）所示，主要包括加強對 HTML5 動態可伸縮應用程式的支援、提高開發人員的生產力和滿足苛刻的企業需求。
1、提高開發人員的生產力
通過一個緊密整合的平臺簡化了應用架構，減少樣板程式碼和加強對註釋的使用來提高效率，另外借助標準 RESTful Web 服務對客戶端的支援提高了應用程式的可移植性。
2、加強對 HTML 5 動態可伸縮應用程式的支援
基於其可擴充套件的基礎架構，Java EE 7 推動了對 HTML 5 應用的構建和支援。在新的平臺中，藉助具有行業標準的 JSON 簡化了資料分析和交換，並通過低延遲和雙向通訊的 WebSockets 減少了響應時間。以及利用改進的 JAX-RS 2.0 更好地支援非同步的、可擴充套件的、高效能的 RESTful 服務，從而更好地支援多使用者的併發操作。
3、滿足苛刻的企業需求
為更好地滿足企業的需求，Java EE 7 提供了許多新功能：
- 細化批處理作業，形成可管理的區塊，以實現不間斷的 OLTP 效能；
- 簡化多執行緒併發任務的定義，以提高可擴充套件性；
- 以及提供具有選擇性和靈活性的事務應用程式等。
Java EE 7 開發的開放性，使得 Java 社群、供應商、組織和個人都能參與其中。19 個來自世界各地的使用者組，包括來自北美、南美、歐洲和亞洲，都參與了“採用 JSR”計劃，提供了寶貴的反饋意見和程式碼示例以驗證 Java 規範 (JSR) 的 API。
在最新發布的 Java EE 平臺中都大大簡化了訪問集裝箱服務的 API，同時大大拓寬了服務範圍。Java EE 7 繼續秉承了簡化性和高效性的趨勢，並進一步拓寬了平臺範圍。下面就針對 Java EE 7 的三大新特性進行詳細的剖析。
提高開發人員的生產力
從 Java EE 5 開始，重心就一直放在提高開發人員的生產力上。這對於 Java 開發者來說非常重要，因為這使得使用 Java EE 進行開發更加便捷，更重要的是能夠滿足快速管理和生產的需求。鑑於此，Java EE 7 大大提高了開發人員的生產力。首先，減少了編寫大量核心業務邏輯所需要的樣板程式碼。其次，該平臺引入更多的註釋 POJOS 來降低 XML 配置的複雜性。最後，Java EE 7 使用更緊密整合的技術，提供一個更加無縫的開發體驗。
減少冗餘程式碼
Java EE 7 一直在致力於減少在核心業務邏輯程式碼執行前必須執行的樣板程式碼。減少樣板程式碼的三大核心區域是預設資源、JMS 2.0 和 JAX-RS 客戶端 API。預設資源是一個新的功能，要求平臺提供商預配置一個預設的資料來源和一個預設的 JMS 連線工廠。這可以讓開發人員直接使用預設的資源而無需進行額外的定義。JMS2.0 在可伸縮性和可移植性上經歷了重大的改進，減少了冗餘程式碼，已運用在無數的產品部署上，事實證明它是一個良好的規範，能夠較好地滿足企業的需求。
更多帶註釋的POJO
通過註釋 Java EE 使開發人員更專注於 Java 物件的程式設計而無需關注繁瑣的配置。
CDI 現在預設情況下已不需要使用 beans.xml 檔案就可以直接使用。開發人員可以不需要任何配置而是簡單的使用 @Inject 來注入任何 Java 物件。包括新的資源註釋 @JMSDestinationDefinition 和 @MailSessionDefinition ，使得開發人員在原始碼中就可以指定元資料資源，簡化了 DevOps 體驗。
更緊密整合的平臺
Java EE 6 引入了 Managed Beans 1.0 作為第一步來朝著 EJBs、JSF Managed Beans 和 CDI beans 發展。Java EE 7 繼承了這一點，例如，對 JSF Managed Beans 進行了改進來更好支援 CDI Beans。Java EE 7 為平臺引入了易用的 EJB 容器管理事物，使用基於 CDI 攔截器的解決方案來保證事務可用在 CDI managed beans 和其它 Java EE 元件中，把註釋 @Transactional 應用到任何 CDI bean 或者任何支援事務的方法中。
Bean Validation 在 Java EE 7 中使用廣泛，現在可以用於方法級別的驗證，包括內建和自定義的約束。約束可被應用於方法的引數以及返回值。約束也可以使用靈活渲染和違反約束的字串格式的 Java EE 的表達語言。
Bean Validation 也延伸到 JAX-RS 2.0。註釋約束可以應用到公共建構函式的引數、方法引數、欄位和 bean 的屬性。此外，他們還可以修飾資源類、實體引數和資源的方法。例如，約束可以通過 @ POST 和 @ PUT 應用於 JAX-RS 方法引數來驗證表單提交的資料。
通過精簡現有技術來簡化Java EE
Java EE 7 中新增加了許多新的特性，有些老的特性和功能已經被更簡單的特性所替代或直接棄用。Java EE 6 為過時技術的棄用和功能的修剪引入了一個正式的流程，以下的 API 在 Java EE 7 中已成可選，但在 Java EE 8 中將會被移除：
- Java EE Management (JSR-77)，原本是用於為應用 伺服器建立監控管理的 API，可各大供應商對此 API 熱情並不高漲；
- Java EE Application Deployment (JSR-88)，JSR 88 是當初用於 J2EE 應用程式在應用 伺服器上進行配置和部署的標準 API 。可是該 API 始終沒有得到眾供應商的支援；
- JAX-RPC，是早期通過 RPC 呼叫和 SOAP web services 進行互動的程式設計模型。由於 Web services 成熟後從 RPC 模型中分離出來，被更加健壯和具備更多特性的 JAX-WS API 所替代；
- EJB 2.x Entity Beans CMP，複雜、笨重、過度複雜的 EJB2.* 的 Entity Bean 模型已經被 Java EE 5 的基於 POJO 的流行輕量級 JPA 持久層模型所代替。
對 HTML 5 動態可伸縮應用程式的支援
HTML5 是包括 HTML、JavaScript 和 CSS3 在內的一套技術組合，它加快了開發人員建立高度互動的應用程式的步伐。開發出的應用程式都是以高度互動的方式提供實時的資料，如聊天應用程式，比賽實況報導等，並且這些應用程式只需要編寫一次，就可以應用在桌面、移動客戶端等不同裝置上，具有非常好的跨平臺性。這些高度動態的應用程式，使得使用者可以在任何地點任何時間進行訪問，從而對伺服器端向客戶端傳送資料的規模提出了更高的要求。Java EE 7 在更新現有技術如 JAX-RS 2.0、Java Server Faces 2.2、和 Servlet 3.1 NIO 基礎上，又藉助新的應用技術 WebSockets 和 JSON 處理為支援動態應用程式 HTML5 奠定了堅實的基礎。
低延遲資料交換：Java API for WebSocket 1.0
越來越多的 web 應用程式依賴於從中央伺服器及時獲取並更新資料。基於 HTTP 的 WebSockets 為解決低延遲和雙向通訊提供了一種解決方案。在 WebSocket API 的最基層是一個帶註釋的 Java 物件（POJO），如清單 1 所示：
清單 1. 帶註釋的 Java 物件（POJO）
@ServerEndpoint("/test")
public class TestEndpoint{
@OnOpen
public void onOpen(...){ }
@OnClose
public void onClose(...){ }
@OnError
public void onError(...){ }
@OnMessage
public void testMessage(String message,...){ }
}
通過註釋 @ServerEndpoint 來指定一個 URI。諸如客戶端連線、接收訊息和客戶端斷開這樣的回撥函式都可以用註釋來指定。WebSocket API 的最基層支援傳送和接收簡單文字和二進位制資訊。API 的簡單性也使得開發人員可以快速入門。
當然，功能豐富的應用擁有更復雜的需求，因此需要支援對最基礎的網路協議進行控制和自定義，而 WebSocket API 正好能夠滿足以上需求。另外，WebSocket 利用現有 Web 容器的安全特性，開發人員只需付出較少的代價就可以建立良好的保密通訊。
簡化應用資料分析和處理：Java API for JSON Processing 1.0
JSON 作為一個輕量級的資料交換格式被應用在許多流行的 Web 服務中用來呼叫和返回資料。許多流行的線上服務都是使用基於 JSON 的 RESTful 服務。在 Java EE 7 之前，Java 應用程式使用了不同的類庫去生成和解析 RESTful 服務中的 JSON 物件。然而，現在這個功能已被標準化。
通過 Java API 中的 JSON Processing 1.0，JSON 處理過程標準化為一個單一的 API，應用程式不需要使用第三方的類庫。這樣使得應用程式更小更簡便。同時 API 包括了支援任何轉換器和生成器實現的外掛，使得開發人員可以選擇最好的實現方式去完成工作。
可擴充套件的RESTful服務：JAX-RS 2.0
JAX-RS 2.0 增加了非同步響應處理，這對於支援對資料有著高要求的 HTML5 客戶端的擴充套件是至關重要的。非同步處理是一種更好更有效利用執行緒處理的技術。在伺服器端，處理請求的執行緒在等待外部任務去完成時應該避免阻塞，從而保證在這一時間段內到達的其他請求能夠得到響應。
同樣的，在客戶端，一個發出請求的執行緒在等待響應的時候也會發生阻塞，這影響了應用程式的效能。新的 JAX-RS 2.0 非同步客戶端 API 使得客戶端呼叫 RESTful 可以和其他客戶端活動並行執行。非同步的好處是使得一個客戶端可以同時呼叫多個後臺服務，對於一個使用者來說減少了總體的延遲時間。
同時為了增強 RESTful 服務，JAX-RS 2.0 開發人員可以使用過濾器和實體攔截器。這樣開發人員就可以使用標準的 API 來實現過濾和攔截功能，使開發過程變得更加便捷和高效。
增強開發的易用性：JSF 2.2
JavaServer Faces (JSF) 是一種用於構建 Web 應用程式的 Java 新標準框架。它提供了一種以元件為中心來開發 Java Web 使用者介面的方法，從而簡化了開發。在這個版本中，JSF 增加了對 HTML5 的支援。JSF 2.2 增加了一個叫“pass-through elements”的新功能。併為現有的元素增加了一系列的新屬性，如輸入元素“tel”、“range”和“date”等。不幸的是，現有的 JSF 元件不能識別這些新的屬性，因此 JSF 應用程式會忽略這些屬性不能進行使用，直到建立專有的解決方案。對於“pass-through elements”，JSF 渲染器將會忽略這些元素，只是把它們傳給支援 HTML5 的瀏覽器，這使得可以利用現有的 JSF 元件來利用 HTML5 的特性來正常渲染。
JSF 引入了一個新的 pass-through 名稱空間 http://xmlns.jcp.org/jsf/passthrough 對映到“p:”，任何元件的 name/value 對都可以以“p:” 開始，然後傳給瀏覽器。如清單 2 所示，HTML 5 “type=color”不需要 JSF 元件的任何解析就可以傳遞給瀏覽器。
<h:inputText Value=”#{bean.color}” P:type=”color” />
HTML5 的動態性使得伺服器端處理資訊更新的請求不斷增多。在 Java EE 6，Servlet 非同步 I/O 通過移除“一個請求需要一個執行緒”的限制，使一個執行緒可以處理多個併發請求。這可以使 HTML5 客戶端快速得到響應。但是，如果伺服器端讀取資料的速度比客戶端傳送的速度要快，那麼可能會由於緩慢的客戶端連線而不能提供更多的資料導致執行緒阻塞，這樣就限制了擴充套件性。在 Java EE 7 中使用新的事件驅動 API Servlet 3.1 從客戶端讀取資料將不會造成阻塞。如果有資料可用時，Servlet 執行緒將會讀取和處理這些資料，否則就去處理其他請求。
滿足苛刻的企業需求
Java EE 十幾年來一直努力滿足企業的需求，使用 Java 聯結器連線到企業服務端、使用 Java 事務支援事務處理、使用 Java 訊息服務讓系統間可以進行相互通訊。現在企業希望利用開發人員的 Java 技能編寫基於標準的 API 並能夠跨平臺執行的批處理應用程式。企業也需構建高度可擴充套件的應用來滿足更高的服務要求並提高現有資產的利用率。Concurrency Utilities 使得 Java EE 開發人員編寫可擴充套件的應用程式成為可能。
在Java平臺中，提高批處理應用程式的效率使開發過程變得更加便捷和高效
絕大部分的 Java EE 應用都是線上使用者驅動的系統，但同時有一些需要進行批處理的伺服器端應用程式，尤其是離線分析和 ETL 等。這些面向批處理的應用程式是非互動式的、需要長時間執行，這些任務通常需要大量計算，同時可以按順序或者並行執行，並可以通過特定的事件啟動或者定時排程。批處理較適合選擇閒置的時間進行處理，這樣可以有效利用計算機資源。
以前，對於批處理程式沒有標準的 Java 程式設計模型。現在，批處理應用程式為 Java 平臺提供瞭如圖 2 非常容易理解的模型。批處理過程包括任務、步驟、儲存庫、讀取 - 處理 - 寫入模式和工作流等。
如圖 2 所示，一個任務 job 代表一系列執行離散業務流程但又密切相關的步驟。步驟可以按順序或者並行執行。同時，在同一個工作流，當前步驟是可選的，基於前一步驟的執行結果決定當前步驟將被執行或者跳過。另外，步驟可以根據實際的需要被重新執行。儲存庫 (repository) 儲存了當前任務的資訊，比如任務的最後執行時間。通過操作員 (operator) 可以對任務進行排序、開始、停止、暫停和取消操作。
圖2. 用步驟描述工作
