霍夫曼:我叫马克·霍夫曼。从第一个版本1.0开始,我就一直在使用Java。从那时起,我在每个版本中都做Java项目。作为背景,我想告诉你们我今天在做什么。这就是我白天做的事。正如您在这里看到的屏幕截图所示,这些系统管理铁路交通。铁路实际上是一块有150多年历史的土地。这听起来像是遗留系统。事实上,我们开发和维护此类系统已经超过15年。实际上,这些系统有一个真实的商业案例,并提供了真正的价值。他们确实工作。也许,你也处在类似的情况下,你不能只挑选最新最闪亮的软件工具和特性,每隔一天就开发一个新项目。您所使用的系统为您的客户、公司提供了一些价值,并且需要长期维护。事实上我对此很感兴趣。您当前使用的软件有多旧?您目前在生产中使用的Java版本是什么?这是我的一个例子。这个软件大约有15年的历史了。在生产中,我们有Java11。
我在晚上做什么
我做更多的事情。我把它叫做我晚上做的事。我参与了一些开源项目,可能最著名的是JaCoCo代码覆盖工具。使用该工具,您可以测量单元测试提供的覆盖率。我创建这样的报告。它在QA领域非常流行。它可以在最新的Java版本上工作,这看起来真的是一种很好的技术,可以适应JVM中的最新技术和最新特性。
让我们来看看新的和闪亮的开源项目的现实。我从事的项目已经有10多年的历史了。杰科科,我10年前开始的。Eclipse插件的代码覆盖率已经有15年了,它基本上是以前的另一个工具。这些工具已经发布了相当多的Java版本。实际上,这是JaCoCo的大矩阵。目前,我们支持Java5到Java17。所有这些JDK实际上都在我们的构建管道中使用。集成测试在这些管道上运行。这是开发库时出现的情况。
不同种类的软件
基本上有两种不同的软件项目。您可以使用产品或特定于项目的解决方案。在这里,您只需选择最能满足您的需求的运行时。您只能运行特定的运行时版本。如果您对一个工具或库更感自豪,那么您必须支持多个运行时,因为您不知道您的客户机,并且您的客户机可能会将您的应用程序用于不同的运行时。对于上下文,我将重点讨论第一个,假设您在生产中有一个大型应用程序,并且希望定期更新它们。
为什么要升级你的应用
这里的问题是,首先,为什么要更新应用程序?第二,如何?让我们看看为什么。通过新的Java版本,我们获得了新的有用的语言特性和新的API。这使您的工作效率更高,并且您希望使用它来获得更好的代码库、更干净的代码库,并在开发新功能和维护代码库方面更高效。第二,有很多错误修复和安全修复正在进行。您希望有一个维护版的Java,以获得这些错误修复和安全修复。有了新的平台。我这里有一个例子,这是目前非常流行的,ARM架构,新处理器。你可能从和你一起玩的树莓皮上就知道了。这是一个非常好的学习平台。此外,在生产方面,我们将看到更多,最值得注意的是,最新发布的用于新笔记本电脑的苹果M1处理器。我们现在有了基于ARM架构的Windows10。在Amazon上,A1实例类型也基于ARM,并且越来越公开,因为它们提供了非常好的功率和价格比。它们真的很划算。我们可能会看到更多的应用部署在ARM架构上。我们需要新的JVM和新的运行时,它们已经支持这种体系结构。对于Java5,您不会得到这样的结果。
我们可能非常依赖第三方库,我们需要不时地对它们进行升级。这些库还具有Java运行时的最低要求。我们需要不时地更新我们的运行时,然后我们还可以更新库。目前,我对Maven Central做了一些研究,大多数最新版本的库都以Java8为基准。没有恐慌,Java8已经存在了八年多了。至少有一点是很好的,那就是Java8,Java库不会很快地增加到Java11。它们运行运行时,但您不需要立即更新到Java11。请注意,大多数库现在都在Java8上。如果您的版本早于Java8,那么在更新它们时可能会遇到麻烦。当然,我们想成为快乐的开发者,而你想学习和使用最新的东西。在生产环境中的开发环境中拥有不止一个运行时是一个很好的动机。
如何升级
让我们看看主要部分,我们如何更新?这里是旧Java时代的发布时间表。我们在这里看到的是每两年发布一次,比如两年。Java6和Java7之间存在巨大的差距。这是甲骨文收购Sun的时候。这已经五年了。五年来,我们没有看到一个新的语言特性或一个新的API,所以您从Java6开始。在这些Release之间,什么都没有,只有沉默。您将无法获得一些预览功能。您将无法获得一些增量更新。只是你等了几年,突然间你得到了一个新版本。OpenJDK改变了这一点。在OpenJDK中,新的时间表是从Java9开始的。现在我们每六个月发布一次新版本。以固定周期每年发布两次。当我们查看发布的生命周期时,我们看到大多数发布只维护了六个月。其间,我们发布了长期支持版本。当前的长期支持版本是Java8、Java11,下面的下一个版本是Java17,将于今年秋天发布。实际上,时间表还是一样的。每隔几年,我们就会有一个主要的版本,有一个长期的发布计划,但在这期间,我们会有新的中间版本,我们已经可以测试和适应新的特性了。
可持续的更新战略
什么是可持续更新战略?首先,真正确保您在生产中有一个受支持的JDK。目前,我们使用的是Java8。Java8可能还要支持几年。如果您运行的是Java5或其他版本,那么没有理由不更新到至少Java8。这是一个非常笼统的建议。您应该有一个干净的代码库,但是对于Java运行时,请注意不推荐使用的API。在最新的Java版本中,弃用注释被一个新属性ForRemove扩展。如果ForRemove设置为true,这意味着有认真的计划来删除它。这已经发生了。如果您选择忽略不推荐的API,总有一天,您的代码库将不再编译,因为API将消失。注意这个。另一件事是内部API。依赖内部API、com.sun或sun包是一种不好的做法,它们现在被Java模块系统封装,访问它们变得更加困难。您将首先收到警告,然后在下一个版本中,您将无法再访问这些内部API。避开它们。实际上没有理由依赖内部API,只使用公共API和Java包。
如果JVM有运行时警告,打印到控制台,打印到日志文件,请认真对待。它们通常会提示您正在使用两个内部API,您正在使用不推荐的JVM参数。修好它们,因为总有一天它会坏的。更新你的工具。这些工具,比如说IDE,构建工具,它们在追赶最新的Java版本方面做得非常好。如果您更新您的IDE,您将很容易引入新的Java版本,因为这些工具很可能支持最新的Java版本。另外,更新您的依赖项。此外,您的第三方依赖项可能会使用内部API或不推荐使用的API,因此它们通常会不时发布更新,并清理其代码库。为避免您的第三方依赖关系出现问题,请随时更新它们。只需确保库不需要比当前更新的JDK版本。大多数Library都非常保守。就像我们在JaCoCo一样,我们仍然在使用Java5。Maven Central上的大多数库都可以使用Java8。
安全的更新战略
当涉及到在生产环境中实际更新运行时时时,比如说在大型系统中,您希望安全。你要确保不破坏生产。你想确保万一出了什么问题,你仍然可以以某种方式逃离这种情况。这是我的建议,我们在大型生产系统中多次采用的方法是分两步进行。第一步是更新运行时JDK。测试一下。把它投入生产。这方面的经验。它有用吗?它是否满足您的非功能性需求?你有什么问题吗?你觉得有什么问题吗?只有在成功的情况下,才能采取第二步,即更新您的开发目标。为新版本编译。使用新功能。为新版本编译字节码。
这看起来像这样。如果这些是您的发行版,您将始终首先更新运行时JDK。然后,对于软件的下一个版本,如果您成功地更新了运行时,您还将更新您的开发构建链。这给了你一个安全网。因为如果在运行时、测试期间,甚至在生产中出现故障,您总是可以返回到旧的运行时并花时间解决问题。如果您同时更改开发版本,或者从一开始就更改开发版本,那么您就打开了使用新API、使用新语言功能的大门。没有回头路了。如果出现问题,您不能直接切换回以前有效的旧版本。这是一种保守的方法,特别是对于大型系统,在这些系统中,您可以确保在生产环境中运行时是安全的。一旦您有了这种信心,您还可以将开发堆栈移动到新版本。我真的很推荐。
潜在的更新问题
更新的潜在问题是什么?JVM会不时发生变化。它有数百个命令行选项,这些选项会改变。他们被弃用了。他们走了。语义有时会有一些变化。Chris Newland的VM Option Explorer是一个很好的工具,所以请查看该站点。您可以探索每个Java版本的选项,并查看两个Java版本之间的差异。这有助于您理解在您的产品配置中可能会发生什么变化,以及您应该考虑哪些JVM选项替代其他东西。在清理JDK并使其现代化的过程中,OpenJDK团队决定删除一些Java企业API,主要是在javax包中。它们只是从JDK中消失了,比如javax.transaction或javax.xml.bind。例如,javax.xml.bind,我们对xml接口使用了很多,其中我们有用javax.xml.bind注释的接口Java类。你需要在Maven Central找到替代品。在Maven Central中,您将找到所有这些包的API和变体,并且您需要正确地声明对这些替换的依赖关系,以确保您的应用程序使用更新的版本运行,其中该包已被替换。这主要发生在Java11上。在Java11中,所有这些包都被删除了。
您可能已经使用的内部API将被封装。在像Java16这样的较新版本中,您至少会收到警告。默认情况下,它将不再工作,因此代码将爆炸。一旦你启动应用程序,你会得到一个异常,这个类不再可访问,你就完成了。为此采取措施。有两种选择。一种选择是,使用jdeps工具进行静态分析。jdeps工具可以查看您的类文件、char文件,并查找对内部类和报告的依赖关系,这样我们就可以完整地了解您的代码库,并查看可能隐藏的内容、一些内部访问。另一件事是,在运行时执行。有一个--非法访问开关,它有两个选项,其中一个选项是调试选项。调试选项将打印详细报告。在运行时,如果您的代码库遇到内部API,那么您可以尝试修复该问题。
对于非长期支持版本怎么办?
我之前已经告诉过您非LTS版本,所以在主要的长期支持版本之间只有六个月的可用版本。你应该怎么处理它们?我个人的建议是用它们实际测试您的软件,并尽早发现潜在的问题。您将准备好看到,我的软件将遇到什么问题,可能什么API将消失。重构需要什么?我现在在哪里使用不推荐的API?也许运行时本身也会遇到一些问题,比如崩溃,或者出现一些意外行为。这是一个向OpenJDK项目报告这一点的好机会,以便他们能够修复它。实际上,我不建议在生产中使用非LTS版本。因为这意味着您确实需要能够在六个月内将运行时升级到下一个LTS版本或下一个开发版本。除非你不能保证,否则我不会去非LTS版本,因为六个月后,你肯定是在一个未维护的版本上。这是测试它们为下一个LTS版本做准备的好机会。
预览的特性
还有一件事,您可能听说过预览功能。编译器和JVM的运行时都有一个新标志--enable preview。这将使您能够访问新的语言功能。您可以在新的JVM特性和新的API上尝试新语言特性的实验实现。只能使用--enable preview标志的API,否则会收到警告。研究新特性、跟踪OpenJDK项目中的实现以及报告反馈,这真的很好。同样,我并不建议您使用--enable preview来运行生产。这些功能尚未最终确定。他们会的,在过去,他们确实改变了。预览的想法是真正从社区获得反馈,实际处理反馈,并根据反馈修改实现或规范。如果您依赖预览功能,您将不得不很快调整代码库,因为它肯定会改变。
问答
Ruiz:当您依赖与最新JDK不兼容的第三方组件时,您对如何跟上最新JDK有何见解?你对此有什么建议或想法?
霍夫曼:首先,我的建议是早点考试。真正拿起开发版本并做好准备。通常,这些库也是以某种方式维护的,也许它们是开源的。如果您及早发现并确定问题,您就有机会提供适当的错误报告,甚至可能会提供一个宣传,或者如果这是一个商业问题,那么尽早通知供应商。然后您就有了一些时间框架和空间来修复和更新库。例如,直到您选择下一个长期发布版本。基本上,可能有一些变通办法。例如,如果库使用内部API,则可以在命令行上打开它。总的来说,我的建议是尽早测试并设法解决根本原因。我们每次都这样做。令人惊讶的是,有多少人实际使用开放源码库,并抱怨它们不能在特定的环境中工作。特别是,在商业环境中,人们实际贡献的回报似乎有一个巨大的障碍,说:“这是一个真正的问题。这是一个快速用户,你能看一下吗?”这很简单。我经常教人们,特别是在商业环境中,对开源环境尽可能少的贡献,只报告问题。这是你迈出的第一步。
鲁伊斯:是的,第一步,报告。你甚至不需要修复它,只需提供反馈。
霍夫曼:提供反馈。如果你是一个快速用户,这是你能做的最好的事情。你根本不必埋头于代码。
Ruiz:提交一个测试用例,比如一个小的可复制的例子。
为什么坚持使用Java?我想知道你的看法,为什么是Java?我们是爪哇人。
霍夫曼:说到科技,我总是尽量避开粉丝。这真的很危险。我总是试图挑战自己并理解,为什么它是一个好的选择,为什么不切换到另一种JVM语言,或者可能转到另一种运行时。首先,Java对我来说已经非常成熟了。它拥有一个真正稳定的运行时环境,这给了您很多好处。我们目前有一个非常积极的发展,并正在向现代语言发展。最后,是关于技术诀窍。你的团队有哪些技能?您的团队在未来10年内可能具备哪些技能?在这里,我认为Java是一个不错的选择。也许你在一家.NET公司工作,也许.NET是更好的选择。比如说,像随机技术一样,你经常会用到,比如,Scala几年来非常流行。现在我们有了一些遗留的Scala代码,没有人想再维护它了。对我来说,如果涉及到一个商业项目,而不仅仅是玩具项目,我真的会考虑哪些诀窍是可行的。
鲁伊斯:我们必须在成熟度、功能和支持之间找到平衡。没有多少语言能满足这些要求。人们抱怨Java的一个问题是,有时我们的行动不够快,或者我们没有足够快地摆脱过去。
霍夫曼:老实说,我认为Java实际上发展得太快了。
鲁伊斯:我们不需要迁移或更新。Java 8将在2030年之前得到支持。
您是否计划从Java1.5升级JaCoCo源代码?这样做的好理由是什么?
霍夫曼:目前,我们没有令人信服的理由这样做。JaCoCo是一种工具,用于各种平台上的许多项目。当然,拥有Java8并在所有API中拥有更多的语言特性会更有趣,但这对于像我们这样的库的维护人员来说才是有趣的。对于目前可能在Java6环境中使用它的用户来说,这并不有趣。就功能而言,我们还没有看到任何令人信服的理由这样做。JaCoCo在Java17上工作,只是JaCoCo的实现仍然与Java1.5兼容。它可以完美地使用Java17处理类文件。
鲁伊斯:它仍然做得很好。
您期待在下一个Java版本中有哪些即将推出的功能?
霍夫曼:记录是一种东西,它是语言的补充,就像switch语句一样。这是我非常期待的事情,尤其是记录。这就是问题所在,因为如果你曾经编写过企业软件,getter和setter真的很可怕。我真的希望我们能尽快解决这个问题。
鲁伊斯:对于桌面图形用户界面,你还有其他建议吗?他们从JavaFX开始。
霍夫曼:事实上,我在领导一个为一家大型公司工作的团队,该公司正在研究UI策略。我们决定改用web界面,Java将不再是该特定企业未来用户界面的首选工具。在这个方向上有很强的趋势。在这方面有很多专门技术和工具。我个人的观点,特别是对于商业软件,是我们在未来不会再看到很多JavaGUI了。我认为网络将扮演这一角色。
鲁伊斯:我发现一件事是很难说服人们升级Java版本,这从来都不值得。有什么建议,去和管理员说,我们应该升级?为什么?
霍夫曼:这是一个商业决定。我问了一个问题,你想让这个软件运行多久?您希望让开发人员维护软件多长时间?如果你认真地问这个问题,如果你看看旧Java版本的许可证模型,那么如果你低于Java8,你有两个选择。您需要为许可证、更新或至少更新到Java11支付大量费用,以获得可在生产中使用的免费替代方案。归根结底,这取决于资金和执行能力。您所依赖的大多数库,新版本将不再支持旧的JDK,因为它们升级到Java8甚至Java11。基本上,这是一个生命周期问题。如果你为你的产品烦恼,如果你想在未来几年内维护它,请升级。如果你不在乎,不要要求我添加任何功能。
鲁伊斯:事实上,这更多的是关于,Library是什么?谁来维护它,维护多长时间?漏洞是什么?是否有什么东西可以让我们的软件更快,性能更好?它必须是一天结束时令人信服的理由,而不是因为它是新的。外面有些东西是新的,但这还不够好。
您是否期待下一个LTS中的任何特定功能?不?
霍夫曼:基本上是记录。
鲁伊斯:不是在LTS里。事实上,在cadence中,我们有很多从11到17的功能,所以很难确定一个。因为当他们问我一个特定的问题时,什么版本?我总是说,如果你想一想积累起来的东西,那真的很有趣。如果你想一想,就很难确定。
霍夫曼:当然。我在Java网站上工作,我试着跟踪并把它们都写下来。这也有助于我跟踪并了解最新的功能。其中一些很好,但是我不认为它们很重要,就像我不能在没有新功能的情况下编写软件。我不会那么做的。我不是技术迷。我真的想问,这有什么好处?
鲁伊斯:事实上,这是因为你在这个非常重要的系统中工作,说起来不那么容易,让我们再来一次。它很大。你在处理非常重要的事情。我认为你的失败率应该非常低。
霍夫曼:当然。另外,我们在铁路公司工作。他们习惯了一个完全不同的生命周期。这种列车的生命周期为20或30年。如果你作为一名软件开发人员告诉《铁路人》:“我们去年刚刚开发了这个软件,但今年我们不得不重新编写它,因为有了新技术,等等。”没有人会买这个。
Ruiz:有没有插件工具可以用来分析从一个JDK版本升级到更高版本需要更改哪些内容?
霍夫曼:这是JDK附带的。有两种选择。一种选择是进行静态分析。您可以查看类文件和编译的类文件,并查找内部API使用情况。这是通过JDepend工具实现的。它是JDK的一部分。你不需要插件。您只需在类文件的命令行中运行它,就可以得到结果。另一个是动态部分。默认情况下,现代JDK将在控制台上打印警告。真的看看这个。如果有警告的话,寻找它为什么是警告的根本原因,因为有人认为这会有助于向你展示警告,不要忽视它们。你可以免费得到。你不需要工具。
鲁伊斯:实际上有一个问题,我应该注意措辞吗?是的,至少要看看他们在告诉你什么。如果你现在没有时间修复它,但至少要有意识。这将是我的零级建议。
霍夫曼:如果你决定无视警告,迟早它会咬你的。
Ruiz:在现实世界中,您是否遇到过Java升级或依赖库的系统的生产问题。生产问题,环境可能是活的,也可能是死的,这会让你们感到担忧吗?您对Java升级有任何问题吗?
霍夫曼:当然,我们在Java升级方面有问题,但在生产方面没有。这很重要。我们需要保障措施。这是一种保守的做法。我们首先在生产环境中升级运行时版本。如果我们根据旧的JDK进行构建,我们总是可以后退。如果你有一个生产系统,并且你升级到一个新版本,并且可能你已经测试了一段时间。即使您在生产中遇到问题,您仍然可以返回到旧的运行时,因为您的代码仍然是根据旧的运行时编译的。这就是为什么如果你有一个关键的系统,我真的建议你做这两个步骤,比如,让它在生产几个月。一旦您非常确定这是可行的,您还可以为您的开发人员提供新的JDK版本,并允许他们使用新特性和新API。那就没有回头路了。一旦您打开使用新API的大门,并使用新的语言特性,您就无法对整个热代码进行反向移植。
鲁伊斯:我完全同意你的看法。那张幻灯片是纯金的,因为它指出了重要的事情,比如一旦你打开瓶子,让精灵出来,就没有办法把它放进去。您需要足够的时间在所有可能的情况下测试您需要测试的任何内容。是的,非常重要。
您如何看待使用基于JVM的语言而不是使用Java?例如,科特林。Java需要对这种语言进行很多改进。
霍夫曼:当然。首先,如果您使用不同的JVM语言,您将获得JVM的所有好处。JVM是一个很好的运行时。对我来说,没有理由不使用另一种语言。然后是技术诀窍,以及团队的结构。如果你有一个好的Kotlin基地,同时也有很多好的工具,Kotlin在安全方面也会给你带来很多好处。选择这样一种不同的语言是个不错的选择。请再次扪心自问,你有能力做到这一点吗?你有诀窍吗?你有没有开发人员,或者只是你的个人玩具项目来学习一门新语言?
原文:https://www.infoq.com/presentations/java-update-versions/
- 登录 发表评论
- 24 次浏览
最新内容
- 7 seconds ago
- 7 minutes 16 seconds ago
- 22 minutes 6 seconds ago
- 29 minutes 37 seconds ago
- 40 minutes 21 seconds ago
- 5 hours ago
- 6 hours ago
- 6 hours ago
- 7 hours ago
- 1 week 1 day ago