Support for Java 21

[toco-cam]

Acceptance Criteria (Required on creation)

• Java 21 LTS is supported

Hints

Links

• https://github.com/camunda/team-infrastructure/issues/537
• https://github.com/camunda/camunda-bpm-platform/issues/4100
• https://github.com/camunda/team-automation-platform/issues/114

Breakdown

### Subtasks
- [ ] https://github.com/camunda/camunda-bpm-platform/issues/4058
- [ ] https://github.com/camunda/camunda-bpm-platform/issues/4077
- [ ] https://github.com/camunda/camunda-bpm-platform/issues/4078

Dev2QA handover

• [x] Does this ticket need a QA test and the testing goals are not clear from the description? Add a Dev2QA handover comment
  • All supported distributions / runtimes / application servers have to be tested with JDK 21
    • AS / Servlet Containers
    • Spring Boot Integration
    • Quarkus Integration
  • Any database vendor can be used during the tests besides h2
    • At least 2 different db vendors for more thorough testing
    • Example: PostgreSQL 13, Microsoft SQL Server 2017

[psavidis]

Java 21 is available as a build environment one Jenkins for the following repositories

• camunda-bpm-platform

• camunda-bpm-platform-ee

• camunda-spin

• camunda-connect

• camunda-commons

• camunda-template-engines-jsr223

[psavidis]

Kickoff

Context

JDK 21 has been available since 19 September 2023. The scope of this feature is to enable Camunda 7 to support* the new Java version.

What does support mean?

• The tests of all Camunda 7 Repositories should pass with JDK 21
• Java 21 should be available as a build environment in the CI
• camunda-bpm-platform & camunda-bpm-platform-ee builds should pass with JDK 21 on Jenkins under the ci:jdk label build
• JDBC Drivers should be be compatible with JDK 21

What is not in scope:

• Incorporating the new features of Java 21 in Camunda 7 codebases
  • This scope is much greater to assess
  • It would break backwards compatibility

Business Value

• Prolong the life of Camunda 7 Platform by keeping up with the Java Ecosystem
• Performance improvements done in the new JVM (e.g the new Z Garbage Colllector)
• This feature will enable our users to use Camunda 7 with Java 21 and benefit from:
  • Features that the new JDK supports (e.g switch pattern matching, text blocks, virtual threads just to name a few)
  • Security Updates
  • Use third party libraries that work with Java 21 together with Camunda 7 platform

Customer Requirements

As a user, i want to be able to use Camunda 7 with Java 21 (OpenJDK & Oracle JDK)

Backwards compatibility

• All Camunda 7 repositories will continue to work with the current supported JDKs
• Java 21 will be added as an extension

Documentation

• There is already a statement for Java 21 Support under the Supported Environment changes under Camunda Platform 7.21 section
• Add Java 21 under Supported Environments (java, java-runtime)

Backporting

Java 21 Support will be available from 7.21 onwards.

Technical Solution Proposal

Prerequisite

Java 21 is available as a build environment (infra ticket here)

What needs to be added

• Leverage all* Camunda 7 Components to use Java 21 in their CI stage configuration
  • Both Oracle and OpenJDK should be included

all*: camunda-bpm-rpa-bridge-ee will be considered out-of-scope of the needs of this feature.

Identified Issues

• [FELIX-6259] JDKs greater than 11 (17 & 21 in our case) require maven-bundle-plugin:5.1.1 to work
• The class name notation of lambdas in Java 21 changes ; e.g MyClass$$Lambda becomesMyClass$$Lambda$
  • Solution: Change any code that depends on Lambda Class names to consider the new notation conditionally (keep legacy behaviour for previous JDKs and apply new only for versions > JDK 21 )
• Mockito 4.3.1 does not work with Java 21
  • Side effect: ExternalTaskClientBuilderImplTest#testCustomizeHttpClientExposesInternalHttpClientBuilder fails due to Mockito incompatibility with Java 21.
  • Solution: Update to latest Mockito 5.10.0; Replace mockito-inline maven dependency with mockito-core; see thread here
• Starting with Mockito 5.0.0, there are discrepancies in the ArgumentMatcher capture expressions (See release notes here)
  • e.g The expressions activityInstanceIdIn(any()) will capture one argument. In the case of vararg calls, the new matching expressions becomes activityInstanceIdIn(any(String[].class))
  • Solution: Replace failing expressions with varargs with the respective expression as indicated in the example above.

Breakdown

Add Java 21 support to sideprojects

• camunda-spin

• camunda-connect

• camunda-commons

• camunda-template-engines-jsr223

• feel-scala

• [ ] Upgrade maven-bundle-plugin to version 5.1.1 for all the above repositories

Add Java 21 Support to camunda-bpm-platform components

engine

• [ ] Lambdas in Java 21 change lambda class name notation changes; e.g from MyClass$$Lambda to MyClass$$Lambda$
  • TelemetryDynamicDataTest#shouldNotCollectLambdas fails on Java 21
  • Before Java 21 -> TelemetryDynamicDataTest$$Lambda/0x000000e801492478
  • In Java 21 -> TelemetryDynamicDataTest$$Lambda$202/0x000000012948dcc8
  • Solution: Apply the new check only for Java21 and keep the legacy behaviour for JDKs < 21 (conservative approach instead of checking only for "$$Lambda" suffixes)

Holistic Changes

• [ ] Side effect: ExternalTaskClientBuilderImplTest#testCustomizeHttpClientExposesInternalHttpClientBuilder fails due to Mockito incompatibility with Java 21
  • Solution: Remove mockito-inline from parent pom.xml, Update to version.mockito to 5.10.0
  • Use mockito-core instead
  • This update will fix any other mockito incompatibility problems for all the project
  • Affected modules: All Project Modules that reference mockito-inline
• [ ] Check JDBC Drivers for Java 21 Compatibility for all the Database Integrations

Add Java 21 Support to camunda-bpm-platform-ee

• [ ] ExportProcessInstancesRestServiceTest tests fail with Mockito 5.x.x & Java 21
  • The mock expressions in createVariableInstanceQuery contain varargs and ArgumentMatchers#any() expressions don't work anymore the same.
  • They need to be replaced with ArgumentMatchers#any(String[].class)
  • See the relevant change of the ArgumentMatcher in the release notes of Mockito 5 here

Investigate JDBC compatibility of all supported DBs with JDK 21

• [ ] Lookup in the documentation of the current JDBC Drivers for compatibility issues with the following DB providers:
  • [ ] MySQL - Verify latest supported JDBC Driver compatibility with Java 21
  • [ ] MariaDB- Verify latest supported JDBC Driver compatibility with Java 21
    • See related ticket with JDBC Driver 1.7.0
    • Attempt to bump the driver during Remove of Supported environments with 7.19 here
    • Issue reported in the forum that got resolved using the driver 1.7
    • MariaDB Connector
  • [ ] Oracle 19c- Verify latest supported JDBC Driver compatibility with Java 21
  • [ ] IBM DB2- Verify latest supported JDBC Driver compatibility with Java 21
  • [ ] PostgreSQL 13 / 14 / 15 / 16- Verify latest supported JDBC Driver compatibility with Java 21
  • [ ] Microsoft SQL Server 2017 / 2019- Verify latest supported JDBC Driver compatibility with Java 21
  • [ ] H2- Verify latest supported JDBC Driver compatibility with Java 21

[yanavasileva]

Note, don't forget to add the version label to the subtask tickets.

[psavidis]

Reopening the ticket due to the latest main pipeline failure after merging to master.

[yanavasileva]

There is another failure in: https://ci-pipeline.cambpm.camunda.cloud/job/7.21/job/cambpm-ce/job/cambpm-daily/job/master/54/ FilterRestServiceInteractionTest in platform-DISTRO-maven-central daily CE stage. (jdk 17 use and public Artifactory repo).

[psavidis]

After merging the changes for fixing the engine-rest and several build successes, the heap size has been increased to 2g as a safeguard in case Mockito 5 consumes more memory than before.

Any other flakiness can be tackled in another systemic scope. Closing this ticket.

[psavidis]

Assigning the ticket for manual testing to QA

[gbetances089]

Test run created : here

[psavidis]

Update

Opened a PR to adjust the docker-camunda-bpm-platform README phrasing to distinguish between

• the JDK used by the images and
• the latest supported JDK

[gbetances089]

Test run completed! 🔥