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 > > >
