Here you go. 
https://github.com/apache/iotdb/pull/18499

Haonan

On 2026/08/20 02:16:26 Haonan Hou wrote:
> Hi,
> 
> If no more questions about it, I'm going to prepare a PR.
> 
> BR,
> Haonan
> 
> On 2026/08/18 07:35:27 Yuan Tian wrote:
> > Hi haonan,
> > 
> > 1. I agree
> > 2. I think it's ok to do so
> > 3. same as above
> > 4. I think the next version? like 1.3.8
> > 5. Nothing from my perspective
> > 
> > 
> > 
> > 
> > On Tue, Aug 18, 2026 at 12:20 PM Haonan Hou <[email protected]> wrote:
> > 
> > > 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
> > >
> > 
> 

Reply via email to