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