Java推出了新的发布计划,而Oracle也决定移除JRE中一些旧的和不建议使用的功能。本文将据此介绍一下Java即将发生的变化。由于部分移除的功能对于使用Java开发桌面应用的开发者有重大影响,因此本文将深入讨论桌面领域的变化。影响许多公司和开发者的功能之一,就是Java 11将移除Java Web Start。据此,本文将介绍以后Java Web Start的支持情况。
几个月之前,Oracle公布了新的Java发布计划。在新的计划下,Java每六个月会发布一个主版本,所以Java生态环境将更加敏捷。因此,新的Java特性会更快地推出。一个例子就是Java 10中引入的var。
大多数Java开发者还没怎么用过六个月前公布的Java 9。Java 9中引入了一些新的特性如模块化,而现在Java 10也发布了,又引入了一些新特性。因此,Java开发者要想跟上潮流,就必须更快地学习新功能和新特性。对于采用微服务架构的新项目来说,升级到Java新版本很容易,因此新的发布计划是个好消息,但对于老式的大型项目来说升级依然很困难。不过,也许不需要为每个Java版本进行升级。Oracle提供了Java的LTS(Long-term support,长期技术支持)版本,其技术支持期限较长。
因此,虽然Java 9和Java 10的生命周期只有六个月,但计划2018年9月发布的Java 11将称为第一个LTS版。
因此,Oracle将为Java 11提供几年的技术支持,为其提供更新和安全补丁。稍后本文会讨论LTS版本的具体计划和限制。
一年前,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中的一些方法。因此,使用JRE中不建议使用的功能已经和五年前完全不同了。
今天,Java开发者必须更积极地避免使用这些API,并重构旧代码使之不再使用这些API。也许这些API下个版本就会被删除了,甚至不用等着看两三个新版本之后的情况。
如果你的团队多年来一直使用Swing或JavaFX前端创建应用,你也许会认为这些消息跟你没什么关系。那就大错特错了。从今年9月份即将发布的Java 11开始,一些与Java桌面开发紧密相关的重要功能将从JRE中移除:
Java Applets Java Web Start JavaFX
完整的描述可以参见Oracle三月份发布的官方Java客户端计划:
http://www.oracle.com/tech…te2018mar-4414431.pdf
我不会讨论Applet,因为我的确希望它们在所有旧有项目中消失。浏览器厂商早已不再支持Applet、Flash或Silverlight等插件,或至少已经宣布了不再支持的计划。然而另外两点却很重要。一些文章讨论了JavaFX和Java 11中UI工具链的缺失,而我在这篇文章中打算重点讨论Java Web Start。我打算等该领域的情况再明朗些,JavaFX的未来确定之后,再写一篇类似的文章讨论JavaFX(或许还有Swing/AWT)。现在讨论这些未免会夹杂许多假设。
对于那些使用基于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 Web Start。
之前说过,Java 11会移除Java Web Start。更不幸的是,Java 11是下一个提供LTS支持的版本。Java 9和Java 10都只提供六个月的更新和技术支持。就算愿意花钱从Oracle购买Java技术支持,这些版本以后也得不到任何更新补丁。
但即使是Java 11,其LTS跟以前的老版本Java如6、7或8的支持也完全不一样。未来几年内发布的所有LTS版,免费支持只提供六个月。因此,如果不从Oracle购买商业支持,那么为了获得Java的bug修复和安全补丁,就得每六个月升级一次Java版本。
对于LTS版本(如Java 11),Oracle将提供为期几年的商业支持。而旧版本Java则完全不同,它们即使在后继版本发布之后,也会提供相当长的免费支持。这些“旧”版本就是部分基于Web Start的应用的救命稻草。与仅提供六个月支持的Java 9和Java 10不同,Java 8的技术支持仍然有效。免费的Java 8支持将于2019年1月结束。因此,如果你的Web Start应用能在Java 8上运行,并且能控制客户的JRE版本,那么你可以在今年年底之前更新你的应用程序,而无需购买商业支持。
但是,如果你需要更多时间,那么也有办法。Oracle对Java 8的商业支持将持续到2025年。我认为绝大多数Java开发者从来没有关心过Java的商业支持,因为之前的所有Java版本的免费生命周期已经足够更新应用程序了。但是,从新的发行计划开始,再加上移除Web Start等问题,一些公司将会面临新的挑战。因此,我将介绍下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 Web Start应用有100个客户,并且不想放弃Java的安全更新,那么可以每年花大约$3500购买商业支持。
说到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相同的功能。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版本
应用程序应该可以指定由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
译者:弯月,编辑:言则