Hi Haonan, Thanks for starting this discussion.
I support raising the minimum Java version of the dev/1.3 branch to Java 17. I also support applying this change consistently to all Java artifacts, including the Session API, JDBC driver, and other client libraries. Keeping selected client artifacts compatible with Java 8 while moving the server-side modules to Java 17 could preserve some short-term compatibility, but it would also introduce additional toolchains, build profiles, test matrices, and release maintenance. Given the current security and dependency constraints, a single Java 17 baseline would be simpler and more sustainable. Users who still run Java 8 or Java 11 could continue using earlier releases. Since this is a breaking compatibility change, it should be introduced in a clearly announced release at the beginning of the affected release line, rather than being introduced silently in a maintenance release. The release notes and migration documentation should clearly describe the new runtime requirement, client compatibility impact, and deployment considerations. Before the release, we should update the Maven compiler and enforcer configurations, CI workflows, Docker images, documentation, scripts, and relevant dependencies. We should also run the unit, integration, compatibility, and upgrade test suites, and publish the supported JDK matrix. Overall, I am +1 on the proposal and on upgrading all Java artifacts to Java 17. Best regards, Xuan Wang Haonan Hou <[email protected]> 于2026年8月18日周二 12:20写道： > Hi all, > > I would like to start a discussion about raising the minimum Java version > of the dev/1.3 branch from Java 8 to Java 17. > > Background > > The dev/1.3 branch currently keeps Java 8 compatibility. However, some > dependencies can no longer be upgraded to versions containing security > fixes while retaining Java 8 support. This makes it increasingly difficult > to address dependency CVEs and maintain the branch safely. > > Proposal > > I propose raising the Java baseline of dev/1.3 to Java 17. The change would > include: > > 1. Requiring JDK 17 for building and running IoTDB. > 2. Updating the Maven compiler and enforcer configurations. > 3. Updating CI workflows, Docker images, documentation, and related > scripts. > 4. Upgrading dependencies that are currently blocked by the Java 8 > baseline, > prioritizing versions that address known CVEs. > 5. Running the relevant unit, integration, compatibility, and upgrade > tests. > > Compatibility impact > > This would be a breaking change for users who still run IoTDB with Java 8 > or Java 11, as they would need to upgrade their runtime to Java 17. > > Another point that needs discussion is client compatibility. If all Java > artifacts are compiled for Java 17, Java 8 and Java 11 applications will no > longer be able to use the Session or JDBC clients from subsequent 1.3.x > releases. An alternative would be to move the server-side modules to Java > 17 > while keeping selected client artifacts compatible with Java 8, although > this would increase build and maintenance complexity. > > I would like to collect feedback on the following questions: > > 1. Do we agree to use Java 17 as the new minimum version for dev/1.3? > 2. Should the change apply to all Java artifacts, including client > libraries? > 3. If client compatibility should be retained, which artifacts should > continue targeting Java 8? > 4. Which 1.3.x release should introduce this change? > 5. Are there any deployment, upgrade, or compatibility concerns that should > be addressed before proceeding? > > Please share your thoughts. > > Best regards, > Haonan Hou >
