I totally agree with Lari. We are not going to break compatibility with old clients in any case. If users want new client features, they will be forced to upgrade the jdk version, it's nothing new in software.
I suggest we migrate to Jetty, change the minimum runtime version to 21 and release 4.18.0. I don't think there's any reason to prefer 17 over 21 at this point. 4.17.x will be the latest maintenance versions supporting jdk8. We can still avoid using java11+ features to simplify cherry-picks without having to translate code into older java versions, until 4.17.x gets discontinued. Nicolò Boschi Il giorno mer 16 ott 2024 alle ore 20:53 Lari Hotari <lhot...@apache.org> ha scritto: > > Comparing Pulsar to BookKeeper doesn't make sense. Pulsar clients are broadly > deployed, which isn't the case for BookKeeper clients. > > If someone needs JDK 8 support for BookKeeper, they could continue to use a > maintenance branch version of BookKeeper. The master branch of BookKeeper > should move on and baseline to Java 17 as soon as possible. > > One of the reasons for the urgency of this is due to the Jetty 12 upgrade, > which requires Java 17 at runtime. Now there's the first case where Jetty > 9.4.x isn't getting a security upgrade: > https://github.com/jetty/jetty.project/pull/12012#issuecomment-2416450253 > It's about a low priority 3.7/10 CVE-2024-6763: > https://nvd.nist.gov/vuln/detail/CVE-2024-6763 > https://avd.aquasec.com/nvd/2024/cve-2024-6763/ > > This particular CVE isn't a problem, but critical CVEs targeting Jetty 9.4.x > are possible in the future. We need to either upgrade Jetty 9 to Jetty 12 or > eliminate the Jetty dependency in BookKeeper as soon as possible. > > We shouldn't slow down the progress of BookKeeper due to some theoretical > uses of BookKeeper on older Java versions. If someone needs an older Java > runtime for BookKeeper components, they should stick to a maintenance branch > version of BookKeeper. > Why would anyone need to run BookKeeper on anything older than Java 17? If > their corporate policy is preventing using Java 17, they need to revisit the > policy or choose to use an older version of BookKeeper that supports their > old Java runtime version. > > In Pulsar, Java 17 has been required on the server-side since Pulsar 2.11. > Since Pulsar 3.3.x, the default runtime in Docker images has been Java 21. > The Pulsar Java client continues to be compatible with Java 8+. > > -Lari > > On 2024/06/24 16:12:55 Andrey Yegorov wrote: > > I think we should start with refactoring the BK client into a separate > > module built with JDK 8 and then move BK to JDK 17. > > FWIW this is similar to the Pulsar's JDK support for client/server parts. > > > > On Mon, Jun 24, 2024 at 4:22 AM Lari Hotari <lhot...@apache.org> wrote: > > > > > For Pulsar 4.0 (scheduled for October), we need to migrate from Jetty 9 to > > > Jetty 12 since Jetty 9 is not supported any more ([1]). This also impacts > > > Bookkeeper since Pulsar bundles all dependencies in a single directory and > > > this doesn't allow library conflicts between Pulsar and Bookkeeper. This > > > is > > > why we would first need to migrate to Jetty 12 in Bookkeeper, asap. > > > > > > The minimum supported Java version for Jetty 12 is Java 17. That's why I'm > > > proposing that we resolve this problem by setting the minimum Java version > > > to Java 17 in Bookkeeper master branch asap. > > > > > > -Lari > > > > > > 1 - https://github.com/apache/pulsar/issues/22939 > > > > > > On 2024/05/27 01:17:14 ZhangJian He wrote: > > > > Hi, BookKeepers, I want to propose and clarify a new CI strategy based > > > > on > > > > our former practices. > > > > > > > > ## Current CI Jobs > > > > > > > > - **PR Validation Tests**: Currently, these jobs run on JDK 11 for every > > > > pull request to ensure all changes meet our quality standards before > > > > merging. > > > > - **Platform Build Tests**: We run Windows and macOS builds on JDK 11. > > > > - **Tests**: Major tests are currently only run on JDK 11 due to time > > > > constraints(I think, please point out if I were wrong). > > > > - **Compatibility Checks**: We perform basic compatibility checks across > > > a > > > > JDK matrix of 8, 11, 17, and 21, with JDK 21 added recently as per [this > > > > pull request](https://github.com/apache/bookkeeper/pull/4350). > > > > - **OWASP Check**: Run as part of our daily builds or pom file changes > > > > to > > > > ensure security vulnerabilities are identified and addressed swiftly. > > > > - **Daily Builds**: These are three types of job in daily builds: higher > > > > jdk linux, owasp, windows jdk(current running in jdk21, limited to some > > > > development jobs, there are still many tests failures to be solved), due > > > to > > > > its speed and the ability to expose issues. > > > > - **GitHub CodeQL, TYPOS**: These jobs are not related to JVM. > > > > > > > > ## Proposed JVM Strategy > > > > > > > > Given that JDK 11 will reach its end of life in October 2024 [1], I > > > suggest > > > > transitioning our main CI operations to **JDK 17**. This would include > > > the > > > > `PR Validation Tests`, `Platform Build Tests`, and `Tests`. > > > > > > > > For `Compatibility Checks`, we should consider maintaining checks only > > > for > > > > OpenJDK LTS versions that are not EOL. For instance, we can remove JDK > > > > 11 > > > > from the compatibility matrix after October 2024. > > > > > > > > For `Daily Builds` on Linux, I propose adding OpenJDK LTS versions > > > > beyond > > > > our main CI version. > > > > > > > > For `Daily Builds` on Windows and the `OWASP Check`, using the latest > > > > OpenJDK version will leverage the most advanced and supported JDK > > > features > > > > and help expose more problems. > > > > > > > > Thank you for considering this strategic update. I look forward to your > > > > feedback and further discussion. > > > > > > > > [1] [JDK 11 End of Life Update]( > > > https://access.redhat.com/articles/1299013) > > > > > > > > Thanks > > > > ZhangJian He > > > > Twitter: shoothzj > > > > Wechat: shoothzj > > > > > > > > >
