Java推出了新的發佈計畫， 而Oracle也決定移除JRE中一些舊的和不建議使用的功能。 本文將據此介紹一下Java即將發生的變化。 由於部分移除的功能對於使用Java開發桌面應用的開發者有重大影響， 因此本文將深入討論桌面領域的變化。 影響許多公司和開發者的功能之一， 就是Java 11將移除Java Web Start。 據此， 本文將介紹以後Java Web Start的支援情況。
▌新的Java發佈計畫
幾個月之前， Oracle公佈了新的Java發佈計畫。 在新的計畫下， Java每六個月會發佈一個主版本， 所以Java生態環境將更加敏捷。 因此， 新的Java特性會更快地推出。 一個例子就是Java 10中引入的var。
大多數Java開發者還沒怎麼用過六個月前公佈的Java 9。 Java 9中引入了一些新的特性如模組化， 而現在Java 10也發佈了， 又引入了一些新特性。 因此， Java開發者要想跟上潮流， 就必須更快地學習新功能和新特性。 對於採用微服務架構的新專案來說， 升級到Java新版本很容易， 因此新的發佈計畫是個好消息，
因此， 雖然Java 9和Java 10的生命週期只有六個月， 但計畫2018年9月發佈的Java 11將稱為第一個LTS版。
因此， Oracle將為Java 11提供幾年的技術支援，
▌Oracle如何清理JRE
一年前， Oracle宣佈將刪除JRE的部分功能， 在Java社區引發了軒然大波。
在Java 8之前， Oracle刪除JRE中的舊代碼的唯一手段就是@Deprecated注解。 從Java 9開始， Oracle開始主動刪除Java中的舊代碼。 討論最激烈的就是sun.misc.Unsafe類。 該類不像其他java.*包中定義的類， 它不是JCP標準的一部分， 因此理論上開發者不應該使用該類。
但是， 即使一些標準的功能， 在Java 9中也被移除了， 如java.util.logging.LogManager類中的這些方法：
java.util.logging.LogManager.addPropertyChangeListener
java.util.logging.LogManager.removePropertyChangeListener
我完全理解， 為了以後的模組化Java， 部分代碼必須被移除。 LogManager方法使用得很少， 因此版本移植並不是很困難。
但從Java 9開始， Oracle開始不斷刪除不建議使用的部分， 導致JRE上的應用無法正常運行。 例如， Java 10中刪除了java.long.Runtime和java.lang.SecurityManager中的一些方法。 因此，
今天， Java開發者必須更積極地避免使用這些API， 並重構舊代碼使之不再使用這些API。 也許這些API下個版本就會被刪除了， 甚至不用等著看兩三個新版本之後的情況。
▌對於桌面應用開發者這意味著什麼？
如果你的團隊多年來一直使用Swing或JavaFX前端創建應用， 你也許會認為這些消息跟你沒什麼關係。 那就大錯特錯了。 從今年9月份即將發佈的Java 11開始， 一些與Java桌面開發緊密相關的重要功能將從JRE中移除：
Java Applets
Java Web Start
JavaFX
完整的描述可以參見Oracle三月份發佈的官方Java用戶端計畫：
http://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf
我不會討論Applet， 因為我的確希望它們在所有舊有項目中消失。 流覽器廠商早已不再支持Applet、Flash或Silverlight等外掛程式， 或至少已經宣佈了不再支持的計畫。
▌對於基於Java Web Start的用戶端， 這意味著什麼？
對於那些使用基於Java Web Start的應用的公司來說， 這絕對是個壞消息。 如果不在運行用戶端的機器上控制Java版本， 就會有大麻煩了。
一旦9月份Java 11發佈， 用戶在任何機器上安裝了默認的JRE， Java Web Start就不能用了。
儘管近年來我在竭力避免使用Java Web Start， 但我知道許多公司依然在使用基於該技術的用戶端。 一些公司僅在內部使用Web Start， 因此可以控制JRE的版本。 另一些公司將基於Web Start的用戶端提供給客戶使用， 這樣幾乎不可能控制所有客戶的JRE版本。
可見，一些應用開發者會遇到麻煩：要麼找個辦法不再使用Web Start，要麼讓所有客戶繼續使用舊版本的Java。對於大型的應用，這將需要大量的修補工作，而一些公司已經預見到不可能在秋天之前停止使用Java Web Start。
因此對於基於Java Web Start的應用來說，合理的兩個方案包括：
管理客戶安裝的Java版本。這樣就能爭取到更多時間去重構應用；
儘快移除Java Web Start，為Java 11做好準備。
我們來討論下兩種方案，看看怎樣才能刪除Java Web Start。
▌Java Web Start和LTS
但是，如果你需要更多時間，那麼也有辦法。Oracle對Java 8的商業支持將持續到2025年。我認為絕大多數Java開發者從來沒有關心過Java的商業支援，因為之前的所有Java版本的免費生命週期已經足夠更新應用程式了。但是，從新的發行計畫開始，再加上移除Web Start等問題，一些公司將會面臨新的挑戰。因此，我將介紹下Java的商業支持。
▌Java的商業支援
我並不是Oralce的員工，而且商業支援的資訊很難找到，因此我只能談談我所瞭解的情況。所幸，Oracle的Wolfgang Weigend幫忙提供了一些關鍵的資訊。說起Java的商業支援，你可以選擇兩種不同的模型：
基於CPU的許可證（CPU-based license）
基於用戶的許可證（Named User Plus license）
基於CPU的許可證適合在伺服器上運行Java的人。這種情況下，伺服器上的每個CPU將單獨收費。但這並不適用於桌面應用程式。桌面應用程式必須使用NUP（Named User Plus）許可證。使用該許可證，需要為每個使用Java應用的用戶付費。實際上，這意味著每台運行用戶端的機器都要付費。
假設你的Web Start應用程式有100個客戶使用。即使只有20個客戶同時使用，你也要為100台機器付費。好消息是許可證並不貴。具體的價格取決於公司所在的國家，但一般來說差不多每年$30-40。有了這個許可證，支持的Java版本將獲得每年四次更新，包括bug修復、安全更新等。
說到Java的商業支援，我還想提一點，那就是Oracle並不是唯一一家提供商業支援的公司。例如，Azul提供Zulu發行版本的支援。Zulu是個經過認證的OpenJDK版本，可以很容易地替代Oracle的JRE。Zulu的最大優勢是他們未來的非LTS版的支持時間比Oracle長。
但很不幸，對於使用Java Web Start的公司來說，Zulu並不是個可行的選擇，因為它從來沒支持過Java Web Start。
即使你能控制所有客戶的JRE版本，並且願意為商業支持付費，你也應該立即做出計畫，以停止使用Java Web Start。如果Java的發行計畫沒有變化，2025年將發佈Java 23，到那時你肯定不想再使用Java 8了。因此，是時候討論下如何替代Web Start了。
▌停止使用Java Web Start
停止使用Java Web Start並沒有靈丹妙藥。目前，沒有任何工具或技術可以提供與Java Web Start相同的功能。Web Start的最大好處就是它很容易使用，因為Web Start部分集成在JRE的原生可執行檔中。
因此，流覽器會下載一個JNLP檔，然後Java會自動運行並解釋該檔。Web Start被移除後，這就不會再發生了。因此，任何Web Start技術的後繼者至少需要在客戶機器上安裝軟體。另一個方法是通過許多公司都在使用的作業系統原生工具在客戶的機器上安裝並管理軟體。一個例子就是Active Directory Group Policy Objects，可以用於在Windows用戶端上安裝並管理軟體。
我並不是管理員，因此我對這方面沒什麼經驗。但一些客戶已經在這麼做了，並且在通過這種方式分發原生Java應用。這種原生應用可以很容易地利用javapackager創建。該工具是Java的一部分，可以把應用程式和JRE打包，以創建原生應用程式。這樣，開發者很容易就可以定義運行軟體所需的JRE版本，而無需事先安裝Java。
這種方法很容易使用，而且是個移除Web Start的好辦法，但我們還不知道Java 11會不會包含javapackager。之前說過，Java 11不會包含Applet，Web Start和JavaFX。javapackger是JavaFX的一部分，它是和JavaFX一起開發的。
儘管該工具並不依賴於JavaFX，而且可以用來為Swing、AWT或命令列應用創建原生應用程式，它的歷史可能會導致它在Java 11中被移除。因此目前還不知道javapackager能不能用。
有時候Oracle會提到“jlink”，這是Java 9引入的一個工具，可以提取應用程式需要的模組，以創建一個僅包含應用程式所需的功能的JVM。目前還不能通過jlink創建真正的原生應用程式。因此如果想要使用jlink，就要寫一個批次處理腳本來啟動應用程式。關於jlink的例子可以參考這裡：https://github.com/steve-perkins/jlink-demo。
還有一些協力廠商工具可以把Java應用程式打包成原生應用程式，如install4J、JWrapper、IzPack。如果你的客戶有自己的分發軟體和更新的方法，這些工具就都能派上用場。
如果需要為Web Start應用程式提供通用的解決方案，從而不依賴于客戶的軟體管理方式，可以考慮一些提供類似於Web Start的開源專案，如UpdateFX 或GetDown。當然，這些工具並不能提供完整的Web Start的功能，而且一些項目的維護並不是很好。我的觀點是，目前還沒有能完美替代Web Start的方案。我認為，這種工具應該提供以下功能：
小型、原生的用戶端工具，只需安裝一次
該工具應該能夠管理多個應用程式
該工具應該能自動下載應用程式的更新
該工具應該支持Java security manager
該工具應該支持檢查JAR簽名
該工具應該能夠管理安裝的JRE，並安裝指定版本的JRE，或安裝額外的JRE
該工具應該能從指定的下載點下載JRE
應用程式應該能指定所需的JRE版本範圍，或指定特定的JRE版本
應用程式應該可以指定由jlink為該應用程式創建的定制JRE
該工具應該可以在作業系統中安裝應用程式快捷方式
據我來看，目前沒有任何工具支持以上所有功能。希望有人能抓住這個機會，提供並維護一個工具。
否則，Java桌面應用程式的開發者社區將分裂到無盡的定制方案中。
▌明朗的未來？
如前所述，關於Java桌面API的未來的一些觀點仍在討論中，我真誠希望未來幾個月內能成立一個基金會，來管理JavaFX、Swing和AWT的未來。也許，該組織能建立並維護一個工具來替代Java Web Start。
但是，像Jakarta EE一樣，建立這種組織需要花費很多時間，因此社區應該立即開始為未來做準備。
▌結論
如你所見，目前還有一些點並不明朗，Java桌面API的未來需要進一步討論。目前唯一確定的就是未來幾年內Oracle JRE的結構和發佈計畫。其結論就是，對於Oracle來說，Java桌面API已不那麼重要。
但即使我們能成立一個強力的開源基金會，以繼續發展Java的桌面框架，而且就算我們在未來幾年內比Oracle做得更好，Java Web Start也總是要消亡的。
因此，如果你正在開發的應用程式中用到了Java Web Start，那麼應該立即尋找其他解決方案，或者直接將其替換掉，或者考慮長期的Java商業支持。
原文：https://dzone.com/articles/what-the-future-java-releases-will-mean-for-legacy
譯者：彎月，編輯：言則
這樣幾乎不可能控制所有客戶的JRE版本。可見，一些應用開發者會遇到麻煩：要麼找個辦法不再使用Web Start，要麼讓所有客戶繼續使用舊版本的Java。對於大型的應用，這將需要大量的修補工作，而一些公司已經預見到不可能在秋天之前停止使用Java Web Start。
因此對於基於Java Web Start的應用來說，合理的兩個方案包括：
管理客戶安裝的Java版本。這樣就能爭取到更多時間去重構應用；
儘快移除Java Web Start，為Java 11做好準備。
我們來討論下兩種方案，看看怎樣才能刪除Java Web Start。
▌Java Web Start和LTS
但是，如果你需要更多時間，那麼也有辦法。Oracle對Java 8的商業支持將持續到2025年。我認為絕大多數Java開發者從來沒有關心過Java的商業支援，因為之前的所有Java版本的免費生命週期已經足夠更新應用程式了。但是，從新的發行計畫開始，再加上移除Web Start等問題，一些公司將會面臨新的挑戰。因此，我將介紹下Java的商業支持。
▌Java的商業支援
我並不是Oralce的員工，而且商業支援的資訊很難找到，因此我只能談談我所瞭解的情況。所幸，Oracle的Wolfgang Weigend幫忙提供了一些關鍵的資訊。說起Java的商業支援，你可以選擇兩種不同的模型：
基於CPU的許可證（CPU-based license）
基於用戶的許可證（Named User Plus license）
基於CPU的許可證適合在伺服器上運行Java的人。這種情況下，伺服器上的每個CPU將單獨收費。但這並不適用於桌面應用程式。桌面應用程式必須使用NUP（Named User Plus）許可證。使用該許可證，需要為每個使用Java應用的用戶付費。實際上，這意味著每台運行用戶端的機器都要付費。
假設你的Web Start應用程式有100個客戶使用。即使只有20個客戶同時使用，你也要為100台機器付費。好消息是許可證並不貴。具體的價格取決於公司所在的國家，但一般來說差不多每年$30-40。有了這個許可證，支持的Java版本將獲得每年四次更新，包括bug修復、安全更新等。
說到Java的商業支援，我還想提一點，那就是Oracle並不是唯一一家提供商業支援的公司。例如，Azul提供Zulu發行版本的支援。Zulu是個經過認證的OpenJDK版本，可以很容易地替代Oracle的JRE。Zulu的最大優勢是他們未來的非LTS版的支持時間比Oracle長。
但很不幸，對於使用Java Web Start的公司來說，Zulu並不是個可行的選擇，因為它從來沒支持過Java Web Start。
即使你能控制所有客戶的JRE版本，並且願意為商業支持付費，你也應該立即做出計畫，以停止使用Java Web Start。如果Java的發行計畫沒有變化，2025年將發佈Java 23，到那時你肯定不想再使用Java 8了。因此，是時候討論下如何替代Web Start了。
▌停止使用Java Web Start
停止使用Java Web Start並沒有靈丹妙藥。目前，沒有任何工具或技術可以提供與Java Web Start相同的功能。Web Start的最大好處就是它很容易使用，因為Web Start部分集成在JRE的原生可執行檔中。
因此，流覽器會下載一個JNLP檔，然後Java會自動運行並解釋該檔。Web Start被移除後，這就不會再發生了。因此，任何Web Start技術的後繼者至少需要在客戶機器上安裝軟體。另一個方法是通過許多公司都在使用的作業系統原生工具在客戶的機器上安裝並管理軟體。一個例子就是Active Directory Group Policy Objects，可以用於在Windows用戶端上安裝並管理軟體。
我並不是管理員，因此我對這方面沒什麼經驗。但一些客戶已經在這麼做了，並且在通過這種方式分發原生Java應用。這種原生應用可以很容易地利用javapackager創建。該工具是Java的一部分，可以把應用程式和JRE打包，以創建原生應用程式。這樣，開發者很容易就可以定義運行軟體所需的JRE版本，而無需事先安裝Java。
這種方法很容易使用，而且是個移除Web Start的好辦法，但我們還不知道Java 11會不會包含javapackager。之前說過，Java 11不會包含Applet，Web Start和JavaFX。javapackger是JavaFX的一部分，它是和JavaFX一起開發的。
儘管該工具並不依賴於JavaFX，而且可以用來為Swing、AWT或命令列應用創建原生應用程式，它的歷史可能會導致它在Java 11中被移除。因此目前還不知道javapackager能不能用。
有時候Oracle會提到“jlink”，這是Java 9引入的一個工具，可以提取應用程式需要的模組，以創建一個僅包含應用程式所需的功能的JVM。目前還不能通過jlink創建真正的原生應用程式。因此如果想要使用jlink，就要寫一個批次處理腳本來啟動應用程式。關於jlink的例子可以參考這裡：https://github.com/steve-perkins/jlink-demo。
還有一些協力廠商工具可以把Java應用程式打包成原生應用程式，如install4J、JWrapper、IzPack。如果你的客戶有自己的分發軟體和更新的方法，這些工具就都能派上用場。
如果需要為Web Start應用程式提供通用的解決方案，從而不依賴于客戶的軟體管理方式，可以考慮一些提供類似於Web Start的開源專案，如UpdateFX 或GetDown。當然，這些工具並不能提供完整的Web Start的功能，而且一些項目的維護並不是很好。我的觀點是，目前還沒有能完美替代Web Start的方案。我認為，這種工具應該提供以下功能：
小型、原生的用戶端工具，只需安裝一次
該工具應該能夠管理多個應用程式
該工具應該能自動下載應用程式的更新
該工具應該支持Java security manager
該工具應該支持檢查JAR簽名
該工具應該能夠管理安裝的JRE，並安裝指定版本的JRE，或安裝額外的JRE
該工具應該能從指定的下載點下載JRE
應用程式應該能指定所需的JRE版本範圍，或指定特定的JRE版本
應用程式應該可以指定由jlink為該應用程式創建的定制JRE
該工具應該可以在作業系統中安裝應用程式快捷方式
據我來看，目前沒有任何工具支持以上所有功能。希望有人能抓住這個機會，提供並維護一個工具。
否則，Java桌面應用程式的開發者社區將分裂到無盡的定制方案中。
▌明朗的未來？
如前所述，關於Java桌面API的未來的一些觀點仍在討論中，我真誠希望未來幾個月內能成立一個基金會，來管理JavaFX、Swing和AWT的未來。也許，該組織能建立並維護一個工具來替代Java Web Start。
但是，像Jakarta EE一樣，建立這種組織需要花費很多時間，因此社區應該立即開始為未來做準備。
▌結論
如你所見，目前還有一些點並不明朗，Java桌面API的未來需要進一步討論。目前唯一確定的就是未來幾年內Oracle JRE的結構和發佈計畫。其結論就是，對於Oracle來說，Java桌面API已不那麼重要。
但即使我們能成立一個強力的開源基金會，以繼續發展Java的桌面框架，而且就算我們在未來幾年內比Oracle做得更好，Java Web Start也總是要消亡的。
因此，如果你正在開發的應用程式中用到了Java Web Start，那麼應該立即尋找其他解決方案，或者直接將其替換掉，或者考慮長期的Java商業支持。
原文：https://dzone.com/articles/what-the-future-java-releases-will-mean-for-legacy
譯者：彎月，編輯：言則