Require Java 17 or Java 21 for building Bookkeeper

[lhotari]

Motivation

There doesn't seem to be a need to retain support for Java 8 and Java 11 in new releases of Bookkeeper.
Java 11 is EOL in October.
Please see mailing list discussion https://lists.apache.org/thread/gtp4j5y9txzlz0pfgfhy3gz4q4ptnlo8

Changes

• Enforce Java 17 or Java 21 for building Bookkeeper
• Set <release>17</release> for maven-compiler-plugin by default
  • keep Java 8 compatibility in cpu-affinity and circe-checksum since Pulsar's Java client uses them.
• Replace Java 11 usage with Java 17 in CI
• Remove CI jobs using Java 8 or Java 11

[dlg99]

I think we should first refactor BK client into a separate module that will be built with JDK 8, then we can move BK server to JDK 17

#617

[lhotari]

I think we should first refactor BK client into a separate module that will be built with JDK 8, then we can move BK server to JDK 17

#617

Refactoring BK client into a separate module isn't a trivial task.
Who really cares about Java 8 for the Bookkeeper client? Java 8 has been end-of-life for a long time. Why should we care about supporting it if nobody needs it?

[hezhangjian]

@lhotari As far as I know, Pravega uses BookKeeper and their minimum jdk is jdk11.
IMHO, even we decide to require jdk17 for BookKeeper client, we need to prepare a mjor version update.

[lhotari]

@lhotari As far as I know, Pravega uses BookKeeper and their minimum jdk is jdk11.
IMHO, even we decide to require jdk17 for BookKeeper client, we need to prepare a mjor version update.

@shoothzj they won't be staying on jdk11 forever. Java 11 is EOL very soon. Current maintenance branches will be maintained for some time. It doesn't mean that we cut support for Java 8 or Java 11 when we decide to switch to Java 17 in the master branch.

[XuQianJin-Stars]

I think upgrading to jdk17 or jdk21 would be more mainstream.

[nodece]

Maintaining compatibility with lower versions of Java is a good idea, but more and more libraries are constantly upgrading Java versions, which also forces us to force upgrades.

Using Java 17 or 21 is a goo idea, +1.

I think we should first refactor BK client into a separate module that will be built with JDK 8, then we can move BK server to JDK 17

It seems that we need to do that first.

[liangyuanpeng]

I think we should first refactor BK client into a separate module that will be built with JDK 8, then we can move BK server to JDK 17

My two cents
working for java11 and not java8 if we want to refactor BK client into a separate module,java8 is becoming a liability.

[lhotari]

I think we should first refactor BK client into a separate module that will be built with JDK 8, then we can move BK server to JDK 17

My two cents working for java11 and not java8 if we want to refactor BK client into a separate module,java8 is becoming a liability.

There's also maintenance branches with Java 8 support, I don't see a point keeping support for JDK 8 in the future versions of Bookkeeper. Existing Java 8 users can continue to use maintenance branches until they have migrated to newer JDK versions. I think that master branch should set the minimum JDK version to either Java 17 or Java 21 and leave the previous JDK versions to be handled by maintenance branches.

Can we even find a single BK users that runs a recent BK version on Java 8? It's definitely a completely unnecessary liability to keep supporting Java 8 in the master branch and future BK versions.

[liangyepianzhou]

I agree to update jdk version in 4.18.0. Generally, we should align major JDK upgrades with a major version bump like 5.0.0 for the client. However, considering the imminent EOL of Java 11 and Java 8, it might still be acceptable to perform the JDK upgrade in a feature release like 4.18.0. After all, users who are reluctant to upgrade their JDKs are likely less interested in new features—as long as we continue providing bug fixes for the older JDK 8/11 branches, the impact would be minimal.

[StevenLuMT]

PRs that have not been processed for a long time will be closed first. Please open them yourself if necessary.

I guess, it's better to keep jdk-11 support for sometime as some legacy systems are still running old bookkeeper version, and upgrading bookie is also upgrades rocksDB version where I saw some incompatibility between rocksDB-5.x and rocksDB-7.x where it doesn't allow to downgrade bookkeeper because rocksDB-7.x introduced unknown tags in MANIFEST file which is not recoverable by rocksDB-5.x if one wants to downgrade bookie.

[merlimat]

I guess, it's better to keep jdk-11 support for sometime as some legacy systems are still running old bookkeeper version, and upgrading bookie is also upgrades rocksDB version where I saw some incompatibility between rocksDB-5.x and rocksDB-7.x where it doesn't allow to downgrade bookkeeper because rocksDB-7.x introduced unknown tags in MANIFEST file which is not recoverable by rocksDB-5.x if one wants to downgrade bookie.

There's no requirement to upgrade the bookies.