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