Hi all,
Thank you for your suggestion! Close this discussion now.
Thanks,
Zixuan
Enrico Olivelli 于2023年2月16日周四 18:19写道：
> -1
> We should still stick to JDK8 for a while on the client side (and
> shared modules).
>
> I see that slowly the ecosystem is moving di JDK11, but it is not yet our
> ti
-1
We should still stick to JDK8 for a while on the client side (and
shared modules).
I see that slowly the ecosystem is moving di JDK11, but it is not yet our time.
This year is Pulsar momentum, please do not add blockers to the adoption
Enrico
Il giorno gio 16 feb 2023 alle ore 09:39 Horizo
-1. We could know the user dependency. Maybe the user dependent the third lib
is not compatible with 11 or 17. It will introduce some problem for user. And
the user need to pay more effort to test the project compatibility after
upgrade the client.
>> Hi all,
>>
>> We are using JDK 17 to comp
-1
The reason is the same as Yunze mentioned. It's a kind of break for the user.
We can't force our user upgrade the application JDK version by pulsar's bug.
That will make our users frustrated.
Plus, the pulsar LTS is 3.0. I think it's better to keep the JDK 1.8 in this
version. as users will
-1
Upgrading the client is harder than upgrading the broker. Pulsar
usually acts as a service to serve many lines of business and only a
single team is responsible to maintain the server side. It would be
hard to push all the client sides to upgrade the JDK.
Instead of upgrading the minimum requi
Hi all,
We are using JDK 17 to compile all the components. For the main component,
the broker and proxy require JDK 17, and the client requires JDK 8.
In Pulsar 3.x, we should keep up with modern JDKS for all components, and
over time, I believe many users have adopted JDK 11/17, which provides
s
