+1 Xiangying Meng
On Thu, Jun 5, 2025 at 4:04 PM Nicolò Boschi <boschi1...@gmail.com> wrote: > > +1 > > Nicolò Boschi > > Il giorno gio 5 giu 2025 alle ore 09:02 Haiting Jiang > <jianghait...@gmail.com> ha scritto: > > > > +1 > > > > Haiting > > > > On Tue, Jun 3, 2025 at 2:00 PM PengHui Li <peng...@apache.org> wrote: > > > > > > +1 > > > > > > - Penghui > > > > > > On Fri, May 30, 2025 at 9:05 AM Tao Jiuming <dao...@apache.org> wrote: > > > > > > > great job, LGTM > > > > > > > > > > > > Lari Hotari <lhot...@apache.org>于2025年5月30日 周五23:14写道： > > > > > > > > > sounds good to me. As you mentioned, Java 8 users can stay on 4.0.x, > > > > > so > > > > > that support isn't going away anytime soon. (4.0.x security support > > > > > is in > > > > > our plans until 21 Oct 2027) > > > > > > > > > > -Lari > > > > > > > > > > On 2025/05/29 20:53:40 Matteo Merli wrote: > > > > > > https://github.com/apache/pulsar/pull/24364 > > > > > > > > > > > > --- > > > > > > > > > > > > # PIP-421: Require Java 17 as the minimum for Pulsar Java client SDK > > > > > > > > > > > > # Context > > > > > > > > > > > > Currently, Pulsar requires Java 17 for the server side components > > > > > > and > > > > > Java > > > > > > 8 for the client SDK and the > > > > > > client admin SDK. > > > > > > > > > > > > For the server side components the change was done in PIP-156 [1] in > > > > > April > > > > > > 2022. At the time it was > > > > > > deemed too early and not necessary to require Java 17 for client > > > > > > SDK as > > > > > > well. > > > > > > > > > > > > There has been a discussion in February 2023 as well [2] where the > > > > > > consensus still was to keep supporting Java 8. > > > > > > > > > > > > # Motivation > > > > > > > > > > > > Since the previous discussions, there have been several changes in > > > > > > the > > > > > Java > > > > > > & Pulsar world: > > > > > > > > > > > > 1. Java 8 has been out of premier support for 3 years already [3] > > > > > > and > > > > > its > > > > > > usage has been drastically decreasing > > > > > > over the years, from 85% in 2020, 40% in 2023 and 23% in 2024 > > > > > > [4]. > > > > > All > > > > > > indicate that by 2028, usage of Java 8 > > > > > > will be negligible. > > > > > > 2. Java 17 LTS was released ~4 years ago, and it's quite widely > > > > adopted > > > > > in > > > > > > Java production environments, > > > > > > along with Java 21 LTS. > > > > > > 3. Pulsar introduced the concept of LTS release which does get > > > > > > support > > > > > for > > > > > > 2-3 years. This means that a change > > > > > > we make now will not really affect users sooner than the current > > > > LTS > > > > > > goes out of the support window. > > > > > > > > > > > > > > > > > > ## Issues with dependencies > > > > > > > > > > > > Many popular Java libraries have started switching to requiring > > > > > > Java >= > > > > > 11 > > > > > > or >= 17. This is posing > > > > > > a real problem because we are stuck into old and unsupported > > > > > > versions. > > > > > When > > > > > > there is a CVE flagged > > > > > > in these dependencies, we don't have any way to upgrade to a patched > > > > > > version. > > > > > > > > > > > > Non-exhaustive set of libraries requiring Java >= 11: > > > > > > > > > > > > * Jetty 12 - We are currently using Jetty 9.x, which is completely > > > > > > unsupported at this point and > > > > > > there are active CVEs in the version we use. > > > > > > * Jersey 3.1 - In order to upgrade to Jetty 12, we'd need to > > > > > > upgrade > > > > > > Jersey as well. > > > > > > * Jakarta APIs - All new APIs for WS and Rest require Java 11. > > > > > > * AthenZ - This is an optional dependency for authentication, > > > > > > though > > > > all > > > > > > new versions require Java 17. > > > > > > > > > > > > There are certainly more dependencies we are using today that have > > > > > already > > > > > > switched new versions > > > > > > to Java 17. This will pose a growing risk for the near future. > > > > > > > > > > > > ### Why Java 17 instead of jumping to 11 > > > > > > > > > > > > The assumption is that the vast majority of Java users have made > > > > > migrations > > > > > > directly from 8 to 17. Java 11 > > > > > > has already stopped the premier support, so there would be no strong > > > > > reason > > > > > > to settle on 11. > > > > > > > > > > > > # Changes > > > > > > > > > > > > 1. From Pulsar 4.1, require Java >= 17 for all client modules > > > > > > 2. Pulsar 4.0 will continue with the current status of requiring > > > > > > Java > > > > 8 > > > > > > for clients. This will give an > > > > > > additional 3 years for users that are stuck on Java 8, up to > > > > > > 2028. > > > > > > 3. If there is still interest in supporting Java 8 client after > > > > > > 2028, > > > > we > > > > > > would still be able to have extra > > > > > > releases for the 4.0 branch to address issues, security fixes. > > > > > Although > > > > > > we need to be aware that it > > > > > > might be very hard to patch all vulnerabilities reported in > > > > > > dependencies at that point. > > > > > > > > > > > > ## Rejected alternatives > > > > > > > > > > > > Technically, we could upgrade these dependencies and only require > > > > > > Java > > > > 17 > > > > > > for `pulsar-client-admin` and Java 8 for > > > > > > `pulsar-client`. While this option might offer a wider compatibility > > > > > today, > > > > > > it would introduce further confusion > > > > > > on which Java is required for which component, which I don't > > > > > > believe is > > > > > > worth the effort. > > > > > > > > > > > > # Links > > > > > > > > > > > > * [1] PIP-156 (Build and Run Pulsar Server on Java 17) > > > > > > https://github.com/apache/pulsar/issues/15207 > > > > > > * [2] Mailing list discussion > > > > > > https://lists.apache.org/thread/cryoksz7n2066lzdcmhk9jy322lvh11t > > > > > > * [3] Java support and EOL timeline: > > > > https://endoflife.date/oracle-jdk > > > > > > * [4] NewRelic report on Java ecosystem > > > > > > https://newrelic.com/resources/report/2024-state-of-the-java-ecosystem > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Matteo Merli > > > > > > <mme...@apache.org> > > > > > > > > > > > > > > >
