> @Piotr I guess that could be investigated along with an update of
flink-benchmarks to run on Java 11 as well...
I would second Nico's idea to run our benchmarks on Java 11 to see what has
changed compared to Java 8.
Best,
Piotrek
śr., 1 gru 2021 o 11:23 wenlong.lwl napisał(a):
> Thanks for
Thanks for the explanation.
+1 for putting a bigger emphasis on performance on Java 11+. It would be
great if Flink is already well prepared when users want to do the upgrade.
Best,
Wenlong
On Wed, 1 Dec 2021 at 16:54, Chesnay Schepler wrote:
> That is correct, yes. During the deprecation
Thanks Chesnay for bringing this up for discussion. +1 for Java 8
deprecation. Every decision has pros and cons. All concerns mentioned
previously are fair enough. I think that the active support for Java 8
ending in 4 months will have an impact on the projects that still stick
with Java 8 and on
That is correct, yes. During the deprecation period we won't seen any
improvements on our end.
Something that I could envision is that the docker images will default
to Java 11 after a while, and that we put a bigger emphasis on
performance on Java 11+ than on Java 8.
On 01/12/2021 02:31,
hi, @Chesnay Schepler would you explain more about
what would happen when deprecating Java 8, but still support it. IMO, if we
still generate packages based on Java 8 which seems to be a consensus, we
still can not take the advantages you mentioned even if we announce that
Java 8 support is
+1 from me as well on the Java 8 deprecation!
It's important to make the users aware, and "force" them but also the
communities of other
related projects (like the aforementioned Hive) to start preparing for the
future drop of Java 8
support and the upgrade to the recent stable versions.
On Sun,
+1 for Java 8 deprecation. It's an important signal for users and we
need to give sufficient time to adopt. Thanks Chesnay for starting the
discussion! Maybe user@ can be included into this discussion?
Thomas
On Fri, Nov 26, 2021 at 6:49 AM Becket Qin wrote:
>
> Thanks for raising the
Thanks for raising the discussion, Chesnay.
I think it is OK to deprecate Java 8 to let the users know that Java 11
migration should be put into the schedule. However, According to some of
the statistics of the Java version adoption[1], a large number of users are
still using Java 8 in
+1 for the deprecation but let me raise one more point that we have discovered
in our training exercises:
All our training jobs that aim for high throughput run slower on Java 11 than
on Java 8! That may not be a general problem for the various applications in
the wild, but it could be and
+1 for the deprecation and reaching out to the user ML to ask for feedback
from our users. Thanks for driving this Chesnay!
Cheers,
Till
On Thu, Nov 25, 2021 at 10:15 AM Roman Khachatryan wrote:
> The situation is probably a bit different now compared to the previous
> upgrade: some users
The situation is probably a bit different now compared to the previous
upgrade: some users might be using Amazon Coretto (or other builds)
which have longer support.
Still +1 for deprecation to trigger migration, and thanks for bringing this up!
Regards,
Roman
On Thu, Nov 25, 2021 at 10:09 AM
+1 to deprecate Java 8, so we can hopefully incorporate the module concept
in Flink.
On Thu, Nov 25, 2021 at 9:49 AM Chesnay Schepler wrote:
> Users can already use APIs from Java 8/11.
>
> On 25/11/2021 09:35, Francesco Guardiani wrote:
> > +1 with what both Ingo and Matthias sad, personally,
Users can already use APIs from Java 8/11.
On 25/11/2021 09:35, Francesco Guardiani wrote:
+1 with what both Ingo and Matthias sad, personally, I cannot wait to start
using some of
the APIs introduced in Java 9. And I'm pretty sure that's the same for our
users as well.
On Tuesday, 23
+1 with what both Ingo and Matthias sad, personally, I cannot wait to start
using some of
the APIs introduced in Java 9. And I'm pretty sure that's the same for our
users as well.
On Tuesday, 23 November 2021 13:35:07 CET Ingo Bürk wrote:
> Hi everyone,
>
> continued support for Java 8 can
Hi everyone,
continued support for Java 8 can also create project risks, e.g. if a
vulnerability arises in Flink's dependencies and we cannot upgrade them
because they no longer support Java 8. Some projects already started
deprecating support as well, like Kafka, and other projects will likely
Thanks for constantly driving these maintenance topics, Chesnay. +1 from my
side for deprecating Java 8. I see the point Jingsong is raising. But I
agree with what David already said here. Deprecating the Java version is a
tool to make users aware of it (same as starting this discussion thread).
Thank you Chesnay for starting the discussion! This will generate bit of a
work for some users, but it's a good thing to keep moving the project
forward. Big +1 for this.
Jingsong:
Receiving this signal, the user may be unhappy because his application
> may be all on Java 8. Upgrading is a big
Hi Chesnay,
Thanks for bringing this for discussion.
We should dig deeper into the current Java version of Flink users. At
least make sure Java 8 is not a mainstream version.
Receiving this signal, the user may be unhappy because his application
may be all on Java 8. Upgrading is a big job,
Hi,
also a +1 from me because of everything Chesnay already said.
Ingo
On Mon, Nov 22, 2021 at 4:41 PM Martijn Visser
wrote:
> Hi Chesnay,
>
> Thanks for bringing this up for discussion. Big +1 for dropping Java 8 and
> deprecating it in 1.15, given that Java 8 support will end. We already
Hi Chesnay,
Thanks for bringing this up for discussion. Big +1 for dropping Java 8 and
deprecating it in 1.15, given that Java 8 support will end. We already see
other dependencies that Flink use either have dropped support for Java 8
(Trino) or are going to drop it (Kafka).
Best regards,
As with any Java version there comes a time when one needs to ask
themselves for how long one intends to stick with it.
With Java 17 being released 2 months ago, and the active support for
Java 8 ending in 4 months, it is time for us to think about that with
regard to Java 8.
As such I'd
21 matches
Mail list logo