Upgrade to JDK 17 for ARM Architecture

[halibobo1205]

Background

Java-Tron currently only supports Oracle JDK 8. However, despite the wide usage of JDK 8, it is no longer the most preferable option for development for multiple reasons and limitations. For instance, the End of Public Updates process for legacy releases and the End of Commercial Use under the Oracle Technology Network License Agreement for Java SE both hold that. On the contrary, JDK 17 is the LTS (Long Term Support) version of Oracle announced for free commercial use in 2021. It has significant improvements in performance, stability, and security, with advantages as follows:

• Free Java License: Free Use License for All Users.

  [!CAUTION] Oracle JDK Development Kit 17.0.12 is the last planned update of JDK 17 under the NFTC. Updates after September 2024 will be licensed under the Java SE OTN License (OTN) and production use beyond the limited free grants of the OTN license will require a fee. I suggest moving to OpenJDK 17, see more distributions.

  • Java SE Universal Subscription Datasheet
  • Oracle Java SE Universal Subscription FAQ
  • Oracle Java SE Subscription Global Price List

• LTS: Long-Term-Support, Premier Support Until September 2026 or later.

• AArch64 Port

  [!IMPORTANT]

  • JEP 237: Linux/AArch64 Port(Release 9)
  • JEP 388: Windows/AArch64 Port(Release 16)
  • JEP 391: macOS/AArch64 Port(Release 17)

• Garbage Collectors

  [!IMPORTANT]

  • Shenandoah JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production)(Release 15)
  • ZGC JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production)(Release 15)

• Language

  [!IMPORTANT]

  • JEP 306: Restore Always-Strict Floating-Point Semantics(Release 17)
  • JEP 409: Sealed Classes(Release 17)
  • JEP 361: Switch Expressions(Release 14)

Related Issues and PRs

• 5954

• 5807

• 5338

• 4746

• 4498

• 4472

• 4524

• 4211

• 4133

• 3897

• 3604

• 3542

• 3540

• 3528

• 3514

• 3504

• 2379

• 2311

• 2164

• 1179

• 1105

• 339

• 295

Scope of Impact

• Build and deployment processes
• Core application codes
• Third-party dependencies
• Development and testing environments

[CarlChaoCarl]

@halibobo1205

As far as I know For besu, Java 21 or later is required to build Besu Will java-tron limit the java version, or is it still compatible with java8

[abn2357]

When do you plan to begin this upgrade?JDK 8 is unable to keep up with the times.

[thuthu24]

Background

Java-Tron currently only supports Oracle JDK 8. However, despite the wide usage of JDK 8, it is no longer the most preferable option for development for multiple reasons and limitations. For instance, the End of Public Updates process for legacy releases and the End of Commercial Use under the Oracle Technology Network License Agreement for Java SE both hold that. On the contrary, JDK 17 is the LTS (Long Term Support) version of Oracle announced for free commercial use in 2021. It has significant improvements in performance, stability, and security, with advantages as follows:

• Free Java License: Free Use License for All Users.

  [!CAUTION] Oracle JDK Development Kit 17.0.12 is the last planned update of JDK 17 under the NFTC. Updates after September 2024 will be licensed under the Java SE OTN License (OTN) and production use beyond the limited free grants of the OTN license will require a fee. I suggest moving to OpenJDK 17, see more distributions.

  • Java SE Universal Subscription Datasheet
  • Oracle Java SE Universal Subscription FAQ
  • Oracle Java SE Subscription Global Price List

• LTS: Long-Term-Support, Premier Support Until September 2026 or later.

• AArch64 Port

  [!IMPORTANT]

  • JEP 237: Linux/AArch64 Port(Release 9)
  • JEP 388: Windows/AArch64 Port(Release 16)
  • JEP 391: macOS/AArch64 Port(Release 17)

• Garbage Collectors

  [!IMPORTANT]

  • Shenandoah JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production)(Release 15)
  • ZGC JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production)(Release 15)

• Language

  [!IMPORTANT]

  • JEP 306: Restore Always-Strict Floating-Point Semantics(Release 17)
  • JEP 409: Sealed Classes(Release 17)
  • JEP 361: Switch Expressions(Release 14)

Related Issues and PRs

• 5954

• 5807

• 5338

• 4746

• 4498

• 4472

• 4524

• 4211

• 4133

• 3897

• 3604

• 3542

• 3540

• 3528

• 3514

• 3504

• 2379

• 2311

• 2164

• 1179

• 1105

• 339

• 295

Scope of Impact

• Build and deployment processes
• Core application codes
• Third-party dependencies
• Development and testing environments

[halibobo1205]

Java 21 or later is required to build

@CarlChaoCarl Java 17 or later is required to build Java-Tron.

[halibobo1205]

When do you plan to begin this upgrade?JDK 8 is unable to keep up with the times.

@abn2357 The current phase is under discussion, and the evaluation will be based on the workload.

[halibobo1205]

Try to work with both JDK8 and JDK17.

[halibobo1205]

Here are some common considerations:

[!CAUTION]

1. Floating-point arithmetic Jdk17 may have subtle differences in floating-point precision and behavior. Comprehensive testing is necessary for applications that rely on precise floating-point calculations.
   • Math.pow different result

[!IMPORTANT]

2. Default Behavior Changes
   • JEP 358: Helpful NullPointerExceptions: Provides more detailed information for NullPointerExceptions(JDK 14+)
   • JSR 376: Java Platform Module System: Introduces the Java Module System(JDK 9+)
   • Default Garbage Collector: JDK 8: Uses Parallel GC by default, JDK 17: Uses G1 GC by default
   • ... ...

[!IMPORTANT]

3. JVM options Changes
   • log JVM options
   • Garbage options
   • ... ...

[!IMPORTANT]

4. Third-party dependencies Ensure all third-party libraries and dependencies support JDK17. Some incompatible dependencies may need to be updated or replaced.
   • springframework
   • lombok
   • javax
   • mockito
   • ... ...

[!IMPORTANT]

5. Gradle plugins Ensure all Gradle plugins support JDK17. Some incompatible plugins may need to be updated or replaced.
   • jacoco
   • checkstyle
   • ... ...

[!IMPORTANT]

6. Build and deployment process:
   • Update build scripts to support JDK17.
   • Ensure CI/CD pipelines can be built and tested in JDK17 environments.
   • Docker support

[!IMPORTANT]

7. Cross-JDK testing
   • Establish comprehensive test suites to ensure the functionality works correctly on JDK.
   • Conduct performance benchmarking to compare JKD8 and JDK17 performance differences.

[Murphytron]

This issue has been added to the core devs community call #23, welcome to share the latest progress @halibobo1205, and discuss together with @CarlChaoCarl @abn2357 @thuthu24.

[halibobo1205]

[!Caution]

8. Strong data consistency and finality Final data consistency is required for blockchain, and the world state usually guarantees it. Unfortunately, Java-Tron doesn't have a world state. We need to think about how to ensure final data consistency.

[halibobo1205]

[!CAUTION]

1. Floating-point arithmetic Jdk17 may have subtle differences in floating-point precision and behavior. Comprehensive testing is necessary for applications that rely on precise floating-point calculations.
   • Math.pow different result : Tron Should Use StrictMath to Avoid Cross-JDK Consistency Issues. To ensure Cross-JDK compatibility for Java-Tron, I suggest a new proposal to convert Mathto StrictMath, just like for cross-platform compatibility

[halibobo1205]

[!IMPORTANT]
Commercial Use under the Java SE OTN License (OTN), only free for: ( i) Personal Use, (ii) Development Use, (iii) Oracle Approved Product Use, and/or (iv) Oracle Cloud Infrastructure Use.

Tron's other behavior should be identified as Commercial Use.

[halibobo1205]

[!IMPORTANT]
JDK version compatibility

• Java 17 or later is required to build Java-Tron？
• Compatible with JDK8 and JDK17+?

[halibobo1205]

[!IMPORTANT]
JDK provider

• Oracle JDK？
• Open JDK?

[halibobo1205]

We'll be doing most of the compatibility upgrades in 4.8.1

[halibobo1205]

1. Historical Compatibility Considerations

   • All existing java-tron deployment base on x86 architecture, direct upgrade to JDK17 would affect currently stable running nodes.
   • Maintaining JDK8 on x86 ensures smooth operation of existing nodes, avoiding risks from forced upgrades

2. ARM Architecture Advantages

   • ARM is a new deployment without historical baggage.
   • JDK17 has better performance optimization on ARM architecture.
   • ARM architecture has higher power efficiency, new JDK version can fully leverage these advantages.

3. Technical Evolution Path

   • This dual-track approach allows experimenting with JDK17 on ARM platform first.
   • Can accumulate experience through ARM + JDK17 practice.
   • Provides reference for future x86 platform upgrade to JDK17.

4. Risk Control

   • Limiting changes to new platform (ARM) reduces impact on existing systems.
   • If ARM + JDK17 encounters issues, it won't affect main x86 nodes.
   • Phased approach makes risk control easier.

5. Resource Investment Considerations

   • Avoids handling both architecture migration and JDK upgrade simultaneously.
   • Can focus resources on ensuring smooth ARM platform support.
   • Accumulates experience and best practices for subsequent x86 upgrades.

6. Operational Complexity

   • Maintaining JDK8 on x86 platform temporarily reduces operational pressure.
   • ARM platform as new deployment allows ops team to plan best practices from scratch.

7. Performance Validation

   • Can conduct thorough performance testing in ARM + JDK17 environment.
   • Collect actual running data to inform future x86 upgrade decisions.

This strategy ensures both the stability of existing systems and explores paths for future technical upgrades, making it a practical solution. It's recommended to plan the x86 platform JDK upgrade timeline after gaining successful experience on the ARM platform.

Based on the above considerations, JDK17 is supported on ARM, x86 is not upgraded to JDK17 for the time being. Any suggestions are always welcome!