隨著Java EE 8在2017年9月22日釋出,Servlet的版本也來到了4.0!什麼?Servlet?在前端工程當道的這些年來,這個依附在Java EE上的後端Web技術,還值得一提嗎?而且,還不是提JSP,而是Servlet?

其實,在Java EE的Web層這塊,也許Servlet才仍然值得一提!

JSP過時了?

這些年來前端工程興起,大量的新聞與文件集中於前端技術,後端開發則像是過氣的明星,在缺乏鎂光燈的舞臺默默地持續演出,加上Java重大版本延期已成固定戲碼,Oracle與Google的官司失利,傳出對Java失去了興趣,Java相關開發者、傳教士的離去,Java EE發展遲緩,這次不僅是Java已死,而是Java EE已死的論調也出現了。確實地,這些年來,我也花較多時間在其他開放原始碼專案上,而少於關注Java EE。

然而,Java EE 8釋出之後,我有一本被出版社編輯關切多次的Servlet著作,必須得好好確認一下,是否有改版的價值。書中現有的版本,是基於Java EE 6/Servlet 3.0/JSP 2.2,而Java EE 7的規格是Servlet 3.1/JSP 2.3,Java EE 8則是Servlet 4.0/JavaServer Pages 2.3?嗯?從版號上來看,JSP你還好嗎?

差不多自Java EE 5之後,發生了JavaScript的再興、行動裝置的普及,Web這部分一路走來,歷經了很大的變化,先不論前端工程,後端的Java Web框架本就不少,加上還有其他技術,像是Rails、Node.js的攻城掠地,JSP可以發揮的空間確實是變少了。對此,有一個指標性的代表,是Java官方網站上的Java EE Tutorial,從Java EE 6開始就沒有JSP的內容了,JSF的內容成了實作Web層呈現時的主角。

如果真的想在Java EE Tutorial中,查看JSP的文件,Java EE 6之後的版本都會請你去看Java EE 5 Tutorial。國外鄉民的說法之一是,Oracle為了推動JSF而這麼做,說法之二是JSP已經過時,而拿來說嘴的根據,是《Java EE 6 Tutorial》第5章〈Introduction to Facelets(https://goo.gl/B3XFVw)〉的一段話:「對JSF來說,JSP被認為是不建議使用(deprecated)的呈現技術。」

雖然只是作為認識Java EE的起點文件(內容編排上還有點無聊),然而終究是官方文件,無論是拿掉了JSP的說明,或是在文件中明指不建議使用JSP(作為JSF的呈現技術),總是有一定的指標意義,所以,JSP真的過時了嗎?

Java EE規格怎麼說?

如果JSP真的過時了,那麼,Java EE規格應該會有什麼變化!實際上,一直到Java EE 8,JSP還是明列在Java EE規格之中,不過JSP 2.2、2.3之間沒什麼新功能——基本上,是進行維護方面的清理,或因應EL、JSF規範方面的新增,而作出必要的修改。若要說有什麼不同,JSP 2.3是有了新的明定,JSP容器必須針對HTTP的GET、POST、HEAD方法,做出對應的呈現(其他方法則未定義)(https://goo.gl/aq96A9)。

至於跟JSP相關的規格,一直都是獨立發展,像是EL、JSF。雖說JSF想拋棄JSP(而改基於Facelets),不過,在Java EE 8中,JSF 2.3仍使用JSP API,MVC 1.0也支援JSP,而JSP的基礎Servlet在Java EE 8中,也從3.1版跳到4.0,突顯規格有了很大的不同。

實際上,瞭解Servlet的開發者就會知道,JSP本身在應用上不需要太多著墨。畢竟,技術面上,多半是Servlet的對照,Servlet才是Web應用程式的入口,雖然開發者很少直接撰寫Servlet,然而許多框架技術都是以Servlet為核心而撰寫,若瞭解與掌握Servlet,也就能掌握JSP或相關框架。就現在的眼光來看,當年直接把JSP當PHP在介紹,完全不提或只提一丁點Servlet的書或文件,感覺才是魔道了。

也因此,Java EE一直在Servlet的規格上演進。從3.0支援標註等各方式的設定簡化,到3.1支援HTTP/1.1與非阻斷IO,4.0也在HTTP2上有更多的支援等,而且,就算是Java EE 8 Tutorial,也還是捨棄不了Servlet的相關說明。

就今日眼光來看,JSP確實在Web呈現有所不足,然而基於JSP的舊東西也不少(包括許多Web框架),國外有許多鄉民也表示,還捨棄不了JSP,只是有些鄉民會建議,如果可以的話(像是新專案,而使用的框架支援JSP以外的呈現技術),想考慮使用其他呈現技術來取代JSP。

基於Java 8的Servlet 4.0

既然Servlet依舊重要,因為Java EE 8正式釋出了,那麼,就來關切一下Servlet 4.0到底有什麼變化吧!

首先,Java EE 8是基於Java SE 8,這就代表了在撰寫Servlet時,可以使用到Lambda表示式、Stream之類的函數式風格程式庫,而在非同步處理時,也可以考慮改用CompletableFuture之類的API。

在Servlet 4.0,一些介面實作時,使用了Java SE 8新增的預設方法語法,像是ServletContextListener、HttpSessionListener、Filter等介面,在實作時,也就只需要針對感興趣的方法重新定義,而不需要實作全部的方法,或者自行寫個Adapter了。

談到Servlet 4.0,許多文件上都會談到對HTTP/2的支援,而在API層面上,開發人員可以使用HttpServletRequest的newPushBuilder方法,來建立PushBuilder以支援HTTP/2的Server Push(Tomcat等容器必須基於HTTPS連線才能支援);Servlet 4.0也支援HTTP Trailer標頭,在API上,可使用HttpServletRequest、HttpServletResponse的getTrailerFields、setTrailerFields等方法。

其他,還有一些瑣碎改進,也值得一提。例如:HttpServletRequest新增getHttpServletMapping方法,可以取得HttpServletMapping實作物件,以便在執行時期偵測執行中的Servlet,是透過哪個URL模式對應而來。類別上,也新增加了HttpFilter,父類別為GenericFilter,並且實作了Filter介面。顯然地,實作概念上,類似HttpServlet繼承GenericServlet實作Servlet介面,開發者現在可以繼承HttpFilter,重新定義HttpServletRequest、HttpServletResponse版本的doFilter(而不是ServletRequest、ServletResponse版本)來實作過濾器。

在部署設定上,現在可以在web.xml中,設定<default-context-path>(容器實作廠商的context path設定可以覆蓋此預設);可以透過<request-character-encoding>、<response-character-encoding>,設定預設的請求回應編碼,以往這類編碼設定,必須自行透過過濾器的實現來達成。

如果在應用程式初始階段,須用ServletContext,來進行<request-character-encoding>之類的設定,目前,在ServletContext上,也新增了setRequestCharacterEncoding等對應的方法。

微服務基礎的Servlet?

可以確認的是,現今JSP在呈現技術的角色上,已經沒那麼重要了,然而,若仍然得基於Java EE,在Web層這塊難免都會碰到Servlet相關議題,要擔心的也許是Java EE的發展。

許多社群成員都曾砲轟Oracle無心Java EE,然而,問題也不是馬上捨棄Java EE就能簡單解決。對社群來說,可能是個好消息的部分是,Oracle將Java EE技術,重新授權給Eclipse基金會,並預計在Java EE 9改良Java EE,以便於實現微服務(Microservices)。

在這樣的藍圖,Servlet也許更形重要,在〈Servlet 4.0 JavaOne 2017(https://goo.gl/dfaU8G)〉的一開始,就談到了Servlet作為微服務基礎的初步概念。當然,Java EE的主導權才剛釋出,一切尚在未定數,然而Java開發者應是樂見有所成果。

若是如此,在Java EE 8釋出後,看一眼Servlet 4.0、瞭解進展,仍有意義,就可能性來說,Servlet規格(以及相關的Java EE規格)仍持續演進下去!

作者簡介


Advertisement

更多 iThome相關內容