You might think this is an insignificant issue, but for developers who need to use Java in the JVM, or developers who value Java's new features, this is a very important decision. This article will be related to the analysis of this issue.
Java release plan
A new Java version is now released every six months, so even though Java 11 was released soon, the release of Java 12 is less than five months. As part of the release plan, some versions will be designated as Long Term Support Versions (LTS), which will receive four years or more of technical support and security patch updates. So these versions are often referred to as "major versions" -- not because they have more features, but because they have long-term technical support.
It is expected that the update patches for Java 11 (11.0.1, 11.0.2, 11.0.3, etc.) will be smaller and simpler than the Java 8 patches (8u20, 8u40, 8u60). Because Java 11 updates will be more focused on security patches, there will be no internal enhancements like the Java 8 update. Oracle wants to use Java 12, 13, 14 and other versions as a small update version, analogous to Java 8, which is Java 11u20, 11u40.
Oracle executives have repeatedly argued that updates like 8u20 and 8u40 often lead to devastating changes, but the authors say this is not their own experience, and the only destructive change he remembers is Javadoc.Added
--allow-script-in-comments, but it is not a core part of Java. Therefore, he never worried about the impact of upgrading to the latest version -- because this is the core strength of the Java platform.
Let's take a deeper look at why the upgraded version does not cause any problems in the old release mode. Let's take a look at the differences between the old and new release modes:
|mode||Old release mode||New release mode|
|Upgrade series||Major version of Java||Java update version||Java version series||Java patch version|
|frequency||Every 3 years or so||Once every 6 months||Once every 6 months||Once every 3 months|
|version||6 -> 7 -> 8||8 -> 8u20 -> 8u40||11 -> 12 -> 13||11 -> 11.0.1 -> 11.0.2|
|Main function enhancement||√||✘||√||✘|
|Internal function enhancement||√||√||√||✘|
|JDK tool changes||√||√||√||✘|
Oracle's official view: Java 9->10->11 is more similar to 8->8u20->8u40 than Java 7->8->9.
The table clearly shows that the Java release in the new mode will include many changes, including language changes and JVM changes, both of which will have a major impact on the IDE, bytecode library, and framework. In addition, not only will other APIs be added, but also APIs will be removed (this has not happened before Java 8).
Oracle's point of view is that because each version is only released six months after the release of the previous version, there won't be many new "things", so upgrading is not difficult. Even so, this is not the point. The important thing is whether the upgrade is likely to break the code. Obviously, starting with 11 -> 12 -> 13, the code is more likely to be corrupted than 8 -> 8u20 -> 8u40.
11 -> 12 -> 13 The main difference between such updates as 8u20 -> 8u40 is the change to the bytecode version and the changes to the specification. Changes to the bytecode version are often particularly destructive, most The framework uses a large number of libraries such as ASM or ByteBuddy that are closely related to each bytecode version. And 8u20 -> 8u40 still uses the same Java SE specification, with all the same classes and methods, unlike moving from Java 12 to 13.
In addition, another Oracle statement is worthy of our attention. The statement revealed that if you insist on using Java 11 and plan to upgrade when the next LTS version (ie Java 17) is released, developers may find that their project code cannot be compiled. So keep in mind that Java's new development rules now declare that you can deprecate an API method in one version and remove it in the next release.
Considerations for adopting the new version of Java
In this section, you will outline some of the considerations/risks that must be considered before adopting the new version of Java.
Being "bound" by the new version series
If Java 12 is used and new language features or new APIs are used, this means that you have actually bound your project to a new version of Java. Next you have to use Java 13, 14, 15, 16 and 17, andEach new version must be adopted within one month of the release of the next version.
A new version is used, each with a six-month lifespan and out of date just seven months after launch. This is because each version only provides security patches within six months, the first patch one month after release and the second patch four months after release. After 7 months, the next set of security patches will be released, but the old version will not get updates.
So, do you want to judge whether your development process allows you to upgrade the Java version, and the time window will be too narrow?
Upgraded stumbling block
There are a number of factors that prevent us from upgrading Java in actual use. Here are some common ones:
Insufficient development resources: Your team may be very busy or too small. Can you guarantee to upgrade from Java 15 to 16 development time in two years?
Build Tools and IDE: Will the IDE you use support every new release on the day of release? Maven? Gradle? If not, do you have a backup plan? Remember, you only have 1 month to complete the upgrade, test and publish it to the production environment. It also includes Checkstyle, JaCoCo, PMD, SpotBugs and more.
Dependencies: Are your dependencies ready for each new release? Keep in mind that it's not just a direct dependency, it's everything in the technology stack. The bytecode operations library is especially affected, such as ByteBuddy and ASM.
Framework: This is another dependency, but a big but important dependency. Will Spring release a new version every six months in a one-month narrow time window? Will Jakarta EE (formerly Java EE)? What if they don't do this?
Cloud / hosting / deployment
Can you control where and how the code will run in a production environment? For example, if you run code in AWS Lambda, you have no control. AWS Lambda does not use Java 9 or 10, or even Java 11. So unless AWS provides a public guarantee to support each new Java version, Java 12 cannot be used at all.
How to host your CI system? Will Jenkins, Travis, Circle, Shippable, GitLab update quickly? If not, what would you do?
Forecast for the future
If you have read the list above, and your code and process can handle it. This is very good, but it is more important to understand that you are also limiting the ability to make changes in the future. For example, your code might not be running on AWS Lambda today, but in the next three years?
Planning for the new version
If you are considering a new version of Java, it is recommended that you prepare a list of all the content that you are relying on now, or that you may be relying on for the next three years. You need to ensure that everything in the list works and is upgraded with the new version, or if the dependency is no longer updated, plan it. The author provides his list:
Maven plugins (compile, jar, source, javadoc, etc)
Checkstyle, and related IDE plugins and maven plugins
JaCoCo, and related IDE plugins and maven plugins
PMD and related maven plugins
SpotBugs and related maven plugins
OSGi bundle metadata tool
Bytecode tool (Byte buddy / ASM etc)
More than 100 jar package dependencies
Having said that, the author certainly does not encourage everyone to upgrade, the benefits of new language features and performance enhancements will benefit developers, but the risks behind the upgrade should also be taken into account.
Statement by other third-party manufacturers
The Spring framework is already therevideoThe strategy for Java 12 is expressed in . The key parts are:
"Java 8 and 11 will continue to receive our official support as an LTS version. For the transition version, we will do our best to support it. If you upgrade to Java 11, we are very willing to work with you, but they will not get formal production. Environmental support. Because the long-term support version is our focus, we will do our best for Java 12 and above."
As an example of a typical software vendor, Liferay states the following:
Liferay has decided not to certify every major release of the JDK. We will choose to follow Oracle's lead and only certify the version marked LTS. ——Liferay Blog
to sum up
I believe that the development team has adopted a new version of Java, but I hope they are the decision made after thinking and judging. In addition to the issues mentioned in the article, there are many other factors that need to be considered before upgrading. You are welcome to leave your opinion in the comments.
Original authorStephen ColebourneIs a Java developer and a well-known Java blogger and conference speaker.