The proposal is to keep java 8 for client library and only move server side to 17 :)
On Wed, May 11, 2022 at 11:05 AM Rajan Dhabalia <rdhaba...@apache.org> wrote: > Hi, > > I do not agree to force client applications to use jdk-17 and that will not > be good Pulsar as a project because that will force users to find another > alternative of Pulsar for their messaging usecases. In large org where > Pulsar is being used as a managed service and used by a large number of > applications can upgrade Pulsar for their critical bug fixes but they can > not move to jdk-17 that easily. Forcing and asking users to switch to jdk17 > will be a disaster in the short term because messaging could be a small use > case component in their large application and it's not easy for them to > switch to jdk17 immediately to use the latest pulsar library. So, I > strongly discourage the Pulsar community to strictly move to jdk17 and > provide jdk-11 support for sometime. > > Thanks, > Rajan > > On Wed, May 11, 2022 at 6:40 AM Matteo Merli <matteo.me...@gmail.com> > wrote: > > > On Wed, May 11, 2022 at 1:10 AM Enrico Olivelli <eolive...@gmail.com> > > wrote: > > > I am sorry, I missed this discussion. > > > But until we cut a release we are in time to change our minds, if we > > > find out that we can do better. > > > > Yes, but the precise point of having a PIP process is to have > > discussions and formalize decisions. > > > > > > > > > > > > > It is not that the PR came out of the blue. Obviously every decision > > > > can be re-visited if there are additional details, though it would be > > > > better if we get the feedback at the time the proposal. > > > > > > > > To reiterate the rationale for going directly to 17: > > > > > > > > 1. Requiring Java 11 won't buy us anything new and will at the same > > > > time require changes from the part of the users. > > > > 2. 17 is a Java LTS release that will be out for 1 year from the > > > > moment in which we release Pulsar 2.11 > > > > 3. It is a stable release with widely available packages for every > > > > platform and from every Java vendor. > > > > 4. We are setting up for 4 years of active support of Java 17, > > > > compared to just 1 year of Java 11 > > > > 5. There are several source-level features introduced in 12+ that we > > > > can take advantage of in our codebase > > > > > > I understand your points, and I would be really excited to start using > > > Records and other features (and Valhalla, Loop and Panama as soon as > > > they are available) > > > > > > But on the other side now in the Pulsar ecosystem we have big > > > enterprises that are not keen on changing JDK so quickly. > > > > > > Up to version 2.10 Pulsar still worked well on JDK8. > > > > > > We cannot require users to switch from JDK8 to JDK17 while upgrading > > Pulsar. > > > > Why not? We can ask to upgrade to Java 11 but not 17? > > > > > > > > We have been running, building and testing Pulsar on JDK11 for many > > > major releases (from 2.7 onwards) (and the docker images in 2.10 are > > > with JDK11) > > > so it is time to require JDK11. > > > > Requiring Java 11 would be pointless as there are very few Java source > > level features we can take advantage of. > > > > > > > > I believe that the best plan, in the interest of our community and of > > > the enterprises who choose to switch to Pulsar, > > > is to still allow all Pulsar components to run on JDK11 (and the > > > client on JDK8) for 2.11. > > > > > > We can switch to requiring JDK17 in 2.12. > > > > I do not agree with this assessment and I think the best plan is to > > continue with the current decision of switching to Java 17. > > > -- -- Matteo Merli <matteo.me...@gmail.com>
