Hi, +1 for Java 21. I think Java 21 can open the door for Virtual Threads[1].
[1] https://openjdk.org/jeps/444 Thanks, Heesung On Wed, Oct 18, 2023 at 10:33 AM Lari Hotari <lhot...@apache.org> wrote: > Yes, I agree that we don't need to rush in making Java 21 the default > runtime in docker images and the default JVM to run tests on in CI. > > It seems that supporting Java 21 for build and tests in CI is not too far > away. My intention is to make the master code base compatible with Java 21 > as the first step. Currently, this effort seems to be close to completion > after submitting and merging a few PRs. The Mockito 5.6.0 upgrade PR is the > currently pending since I'd like to have more reviews or feedback on that > PR before merging. I started a separate email thread about it. > > I triggered a new experiment in my fork to run the CI builds and docker > images with Java 21 to find out if there are more known gaps: > https://github.com/lhotari/pulsar/actions/runs/6564345747?pr=155 > https://github.com/lhotari/pulsar/pull/155 > > We'll soon know if there are more incompatibilities in supporting Java 21 > for building and running tests. > > -Lari > > On 2023/10/18 12:26:42 tison wrote: > > It's different to > > > > 1. be compatible with JDK 21 > > 2. switch the runtime to JDK 21 > > > > The latter means we can break compatibility with early JRE. > > > > I totally support to be compatible with JDK 21 and saw your PRs to > upgrade > > mockito version for so. But perhaps it's better to wait a bit for users > > feedback of using JRE21. > > > > To ensure the compatibility, we can add a build CI job with JDK21 > > configured. > > > > mattison chao <mattisonc...@gmail.com>于2023年10月18日 周三19:37写道： > > > > > Thanks for your answer. > > > > > > > > > > We have the PIP, but that doesn't answer the question about the > current > > > schedule and plan for Pulsar 3.2 . There have been delays in past > release > > > schedules so the PIP document doesn't really provide a great answer to > > > timeline. When is it time to start discussing the 3.2 release? We have > the > > > goal of releasing every 3 months. > > > > > > 3.1.x first release on August 14. In my opinion, we can start 3.2.x now > > > because it’s the third month. Plus, The last three weeks of this month > will > > > be the code freeze period. > > > > > > > As mentioned before, it's possible to separately delivery Java 21 > > > support: > > > > - support Java 21 for running Pulsar (possibly already "works" > without > > > any changes in Pulsar, supporting this option is more effort) > > > > - support Java 21 for developing/compiling, running tests of Pulsar > > > > - switch from Java 17 language level to Java 21 in Pulsar server side > > > components > > > > > > +1 for your steps. > > > > > > > > > > > > Best, > > > Mattison > > > > > > > On 18 Oct 2023, at 19:16, Lari Hotari <lhot...@apache.org> wrote: > > > > > > > > > > > > Hi, > > > > > > > >> 1. What are the significant benefits of upgrading? > > > > > > > > There are 2 parts to how Java 21 could be supported. One level is > that > > > we simply add support for developing and running Pulsar on Java 21 > runtime > > > without switching the language level of the Pulsar components. This is > how > > > Java 11 was used in Pulsar in the past while all code in the Pulsar > code > > > base was kept at Java 8 language level. > > > > > > > > One clear benefit of upgrading is staying current and keeping Pulsar > > > relevant for the future and the years to come. > > > > > > > > The performance improvements of the Java runtime between 17 and 21 > don't > > > seem to be significant in most cases. We won't know exactly what the > > > improvement is for Pulsar until we run benchmarks and do a comparison. > I'd > > > expect it to be in the range of 1-5%. > > > > > > > > The benefits of the language changes in Java 21 (since Java 17) is a > > > different discussion and I won't go into that in this email. > > > > > > > >> 2. We should define some rules for using the new feature by JDK21 > > > before upgrading. Especially for the virtual thread. We can't make > thread > > > management worse. > > > > > > > > Sure, that's a valid question to discuss if we were to switch the > > > language level from Java 17 to Java 21. We had similar discussions > about > > > the tradeoffs when we switched the language level from Java 8 to Java > 17 in > > > Pulsar server side components. > > > > > > > >>> Could anyone update me on the current schedule for Pulsar 3.2? > > > >> > > > >> The community has already followed the LTS release process. You can > > > check the PIP[0] to get more information. > > > > > > > > We have the PIP, but that doesn't answer the question about the > current > > > schedule and plan for Pulsar 3.2 . There have been delays in past > release > > > schedules so the PIP document doesn't really provide a great answer to > > > timeline. When is it time to start discussing the 3.2 release? We have > the > > > goal of releasing every 3 months. > > > > > > > > I don't think that it makes sense to do a Java 21 upgrade until we > are > > > preparing the next Pulsar LTS release. It's better to do it earlier if > we'd > > > like to target Java 21 support for the next Pulsar LTS release since > that's > > > a way to make sure that it's really hardened for the LTS release. > > > > > > > > As mentioned before, it's possible to separately delivery Java 21 > > > support: > > > > - support Java 21 for running Pulsar (possibly already "works" > without > > > any changes in Pulsar, supporting this option is more effort) > > > > - support Java 21 for developing/compiling, running tests of Pulsar > > > > - switch from Java 17 language level to Java 21 in Pulsar server side > > > components > > > > > > > > I hope we could continue the discussion and come up with some > consensus > > > about the coarse timelines. The time horizon could be in multiple > years if > > > that's what makes sense. > > > > Oracle's Java 17 LTS premier support ends in Sep 2026, so I assume > that > > > we would make the decision before that. :) > > > > > > > > -Lari > > > > > > > > > > > > On 2023/10/18 02:30:26 mattison chao wrote: > > > >> Hi, Lari > > > >> > > > >>> Do you think we can target the switch from Java 17 to Java 21 for > the > > > Pulsar 3.2 release? > > > >> > > > >> I think we should consider some things: > > > >> > > > >> 1. What are the significant benefits of upgrading? > > > >> 2. We should define some rules for using the new feature by JDK21 > > > before upgrading. Especially for the virtual thread. We can't make > thread > > > management worse. > > > >> > > > >>> Could anyone update me on the current schedule for Pulsar 3.2? > > > >> > > > >> The community has already followed the LTS release process. You can > > > check the PIP[0] to get more information. > > > >> > > > >> > > > >> > > > >> [0] - > https://lists.apache.org/thread/rg1g083c06ozm5go6zo1jophg9y9zl2f > > > >> > > > >> Best, > > > >> Mattison > > > >> > > > >>> On 18 Oct 2023, at 06:02, Lari Hotari <lhot...@apache.org> wrote: > > > >>> > > > >>> Dear Pulsar community, > > > >>> > > > >>> Java 21 was released on September 19th and has now become the > current > > > Java LTS release. > > > >>> > > > >>> I've begun preparations in the Pulsar code base to allow for Java > 21 > > > to be used as the development runtime for compiling the code and > running > > > tests in the master branch. This is a proactive measure to gear up for > Java > > > 21 without committing to the switch just yet. It will help us > understand > > > the necessary changes when we are able to compile the code and run all > > > tests with Java 21. > > > >>> > > > >>> For instance, I initiated the process with the following PRs: > > > >>> - Upgrade Mockito to 5.6.0 to support Java 21 [1] > > > >>> - Upgrade Gradle Enterprise Maven Extension to support Java 21 [2] > > > >>> After these are merged, it should be possible to start running > tests > > > with Java 21 to see what is possibly broken and continue iterating. > > > >>> Moreover, the upgrade to Lombok 1.18.30 for Java 21 support has > > > already been merged [3]. > > > >>> > > > >>> Java 17 has been the recommended runtime for Pulsar server > components > > > since the Pulsar 2.11 release [4]. Meanwhile, the Pulsar client > continues > > > to be supported on Java 8+. > > > >>> > > > >>> I would like to initiate discussions about making Java 21 the > > > recommended and default runtime for Pulsar server components. Note that > > > there will be no change to the Pulsar client, which will remain on > Java 8+. > > > >>> > > > >>> I guess we could come up with a PIP to document the decision once > we > > > have had this discussion. > > > >>> > > > >>> Do you think we can target the switch from Java 17 to Java 21 for > the > > > Pulsar 3.2 release? > > > >>> Could anyone update me on the current schedule for Pulsar 3.2? > > > >>> > > > >>> -Lari > > > >>> > > > >>> [1] - https://github.com/apache/pulsar/pull/21385 > > > >>> [2] - https://github.com/apache/pulsar/pull/21384 > > > >>> [3] - https://github.com/apache/pulsar/pull/21278 > > > >>> [4] - > > > > https://github.com/apache/pulsar#pulsar-runtime-java-version-recommendation > > > >> > > > >> > > > > > > > > >
