Upgrade production environment JDK 6 to JDK 8

Upgrade production environment JDK 6 to JDK 8

Since Oracle does not support JDK 6 and JDK 7, it also needs to use the G1 collector. Therefore, in the production environment, we upgraded the project from JDK 6 to JDK 8, and changed the garbage collector from CMS to G1. Next, let's make a summary of this upgrade and provide some resources that you may need.

Upgrade Guide

Before the upgrade, you need to know the time for Oracle to support JDK versions. JDK 6 and JDK 7 stopped public update (public update) in 2013,201, and JDK 8 will be released on December 8, 2017, or later, stop making public updates. For more information, see Oracle Java SE Support Roadmap.

Java versions have binary backward compatibility, that is, JDK8 virtual machines can run class files compiled by JDK7 and JDK6. If there are exceptions, Oracle will clearly explain in the upgrade. However, if JDK 8 is used and the code is compiled into a class file of the previous version, the new syntax features in JDK 8 cannot be used. Oracle provides Compatibility guidance for major version upgrades, such as Compatibility Guide for JDK 8, Java SE 7 and JDK 7 Compatibility. The Compatibility Guide includes:

• Binary Compatibility
• Source code compatibility
• Behavior compatibility
• Class file changes
• Java SE is incompatible with the previous version.
• The JDK is incompatible with the previous version.
• Features removed from Java SE
• Features removed from JDK
• APIS not recommended

Binary Compatibility

The Code Compiled by JDK 7 can be run in JDK 8, and the Code Compiled by JDK 8 cannot be run in JDK of previous versions.

Source code compatibility

The source code that uses the new JDK8 syntax features cannot be compiled on the previous Java platform. New APIs are not recommendedjavacWarning is given during compilation, unless-nowarnDisable.sum.*UnderAPISo remember not to useAPIOtherwise, the upgrade will be very painful.

Behavior compatibility

Behavior compatibility means that the same input has the same behavior. The Java platform has some intentionally unspecified behaviors, which may change in different JDK versions, so the Code should not rely on these behaviors. If the JDK version changes and the behavior changes, it may indicate a bug in the code.

Class File

The class file compiled by JDK 8. The version number is52.0.

Incompatibility between JDK and Java SE and the previous version

This part has many contents. If you want to upgrade from JDK 7 to JDK 8, you can refer to Compatibility Guide for JDK 8. If you want to upgrade from JDK 6 to JDK 8, for more information, see Compatibility Guide for JDK 8 and Java SE 7 and JDK 7 Compatibility.

This part contains source code incompatibility. For example, the code that can be compiled in JDK 7 cannot be compiled in JDK 8. This type of errors is still relatively easy to query. compile it and you will be able to produce such errors.

Or some GC options will be ignored, suchPermSize.

Or some new content is added to the class file, such as StackMapTable. during runtime, this field of the class file is verified. Some tools that may adjust the bytecode need to update this field. For example, code coverage statistical tools, if these tools adjust the bytecode, and do not update StackMapTable. In this case, JDK of a higher version cannot run the adjusted bytecode, which will fail during the bytecode verification phase.

Or the same code, different bytecode is generated due to the features introduced by JDK 8, and thus JDK8 cannot run normally. This type of errors are usually only displayed at runtime, which is hard to detect. For example, this type of situation is described in type inference and reload parsing in JDK 8. In this case, we should:

• Write more test cases at ordinary times
• Use tcpcopy to suppress incoming traffic

In this way, errors during running or incompatibility of behaviors can be exposed earlier.

GC

The garbage collector G1. The G1 garbage collector is released as an experimental feature in JDK6u14 and is officially released in JDK7. In the future, G1 will be used as the default Garbage Collector in JDK 9. It can be seen that G1 has reached a relatively mature stage. Therefore, G1 can be used in JDK 8.

Important features in G1 include:

• At the same time, two GC algorithms are implemented: the new generation and the old generation.
• There is no physical isolation between generations, and the memory managed by virtual machines is divided into multiple region
• You can set the desired GC pause time (-XX:MaxGCPauseMillis)

Suggestions include:

• Suitable for managing large memory
• Suitable for scenarios with latency requirements higher than Throughput
• The detailed GC logs are always recorded in the log.
• Always open-XX:+ParallelRefProcEnabledOption. In the actual environment, it is indeed time-consuming to process the reference.
• Avoid the Humongous region, that is, the size of a single object is greater than 50% of the size of the region zone.
• Try to avoid Full GC

Note:

• Do not set the new generation size. by adjusting the pause time, G1 will automatically adjust the new generation size.
• The pause time is only the expected time, and it is not guaranteed that STW will be completed within this time. Based on experience, if the pause time is set to x, 50% of GC will be completed within x MS

The most important information I have read during this upgrade is the presentation: G1 Garbage Collector Details and Tuning. The important features, principles, usage suggestions, and references in G1 are described. We strongly recommend that you read them.

In addition, there are several blogs related to G1 for reference:

• G1GC Concept and Performance Tuning
• Poonam's Weblog

Third-party library

During the upgrade of JDK 8, some third-party libraries also need to be updated synchronously. One of the most important reasons is that some libraries are dependent on the class file format. If you compile the code to the JDK 8 version, these libraries also need to be updated synchronously. For example:

• Code coverage tool: Emma does not support jdk8. you can use jacco
• JDK8 is fully supported in Spring: 4.x. Previous versions may not be able to read class files correctly. See How Spring achieves compatibility with Java 6, 7 and 8.

At the same time, you also need to note that the upgrade of third-party libraries will also bring about other problems. For example, we encountered a deadlock when upgrading Spring.

References

• Upgrading major Java versions
• Compatibility Guide for JDK 8
• Java SE 7 and JDK 7 Compatibility
• G1 Garbage Collector Details and Tuning
• Spring Framework 4.0 M1 & 3.2.3 available

Install JDK1.8 on CentOS7

Build a JDK environment using CentOS

CentOS6.3 install JDK and environment Configuration

This article permanently updates the link address: