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