Proposal: Parallel maintenance branches for newer JDK versions (keep Java 8 baseline unchanged)

[GG-Feng]

We are exploring a parallel, separate maintenance model for newer JDK versions, which will not affect the upstream main branch policy at all.

The core idea is:
1：The upstream project continues normal development with Java 8 as baseline
2：We maintain independent adaptation branches for newer JDK versions (Java 17+, etc.)
3：These branches serve users who need to run or build under modern Java environments

We have noticed community demand for newer‑JDK compatibility, and have started JDK upgrade adaptations for several open‑source projects.

If there is ongoing community interest, we are willing to long‑term maintain 2–3 JDK‑upgraded variant branches independently.

The related PR is an exploration of this optional maintenance solution, rather than changing the official Java baseline policy of sqlite‑jdbc.

We welcome community discussion on this idea.

[gotson]

I don't understand what this would achieve, Java 8 libraries are already compatible with any newer version of Java.

We have noticed community demand for newer‑JDK compatibility, and have started JDK upgrade adaptations for several open‑source projects.

Can you provide details on this ? Where were those demands "noticed" ?

[GG-Feng]

Thanks for the clarification. I agree that Java 8 bytecode is generally compatible with newer Java runtimes, so my previous wording may have been too broad.

By “community demand”, I did not mean that there is a large or formal request from the sqlite-jdbc community to change the upstream Java baseline. A more accurate description would be that we noticed some compatibility questions and issue reports around newer JDK environments.

For example:

#729
This shows that some users are asking whether sqlite-jdbc supports Java 17 and above.

#572
This shows that users have asked about the supported Java versions and whether newer Java versions such as Java 11 work.

#1289
This shows that newer JDKs, such as Java 24, may introduce new runtime warnings or behavior changes, for example native access warnings.

#1365
These examples do not prove broad community demand for separate JDK-upgraded branches, and they do not imply that sqlite-jdbc should change its official Java 8 baseline. They only show that there are some user-facing compatibility questions and reports around newer JDK environments.

So I would like to clarify the proposal: this is not a request to change sqlite-jdbc’s upstream Java 8 baseline, nor to add maintenance burden to upstream maintainers. It is only an optional exploration of independently maintained downstream adaptation branches for users who specifically need newer-JDK-oriented builds or testing.

[gotson]

it seems you have no idea how java libraries work. There are no plans to change the baseline JDK for this project.