Speaking for my own product we would like to see Java 11 support, we rely heavily on Arrow and have Java 11 as our minimum supported version. We’d like to keep doing that if possible. Our clients are big enterprises with notoriously sluggish update cycles, so we want to offer maximum compatibility. Once security patches are no longer available on the regular public channels then there is a compliance issue, so we generally follow the EOL schedule of our dependencies.
Corretto, Adoptium and Zulu all have recent public builds of both 8 and 11 and look set to support them with public builds for many years to come. Several organisations I have worked with switched away from Oracle when they made their licensing blunder with Java 8 and although that is rectified now, the change seems to have stuck in quite a few places (at least in my anecdotal experience). A major practical difference to me in Java 17 is the strong encapsulation of internals. Since that affects the majority of serious Java applications then perhaps most people have figured out by now to add the JVM params that let Java continue working. Still, it could be a consideration, if Java17 is the baseline supported version. Regards, Martin. - In case anyone is curious why we don’t support Java 8 per our own policy, it’s because of the “var” keyword - seriously, why did Java take so long with that, even C++ got there sooner! > On 30 Apr 2024, at 16:20, Jacob Wujciak <assignu...@apache.org> wrote: > > Hello everyone! > Great to see this move forward! > +1 on dropping both 8 and 11 unless there is very good reason to keep 11 > around. > Otherwise people will just move to 11 and then have the pain of migration > again when we drop that (which will happen soon regardless imo). > > Am Di., 30. Apr. 2024 um 16:18 Uhr schrieb Dane Pitkin > <d...@voltrondata.com.invalid>: > >> Thanks, JB. Are we aware of any downstream dependencies that would benefit >> from maintaining Java 11 support? Apache Spark jumped straight to Java 17. >> It seems other projects are dropping both 8 and 11 at the same time as >> mentioned by Fokko. From a maintenance perspective, it would be nice to >> drop both. >> >> On Mon, Apr 29, 2024 at 11:20 AM Jean-Baptiste Onofré <j...@nanthrax.net> >> wrote: >> >>> Hi >>> >>> I think it's time to drop JDK8 support. I would say that we should >>> keep Java11 (jumping directly to Java17 would be problematic >>> potentially for some users I guess). >>> >>> Regards >>> JB >>> >>> On Thu, Apr 25, 2024 at 10:21 PM James Duong >>> <james.du...@improving.com.invalid> wrote: >>>> >>>> If we dropped JDK 8, we could use the JDK to compile module-info.java >>> files. Then we could remove the custom maven plugin we’re using for >>> compiling module-info.java files for JPMS support and get better IDE >>> integration (as what we’re doing currently somewhat shoe-horns module >>> information alongside JDK8 bytecode). >>>> >>>> From: Dane Pitkin <d...@voltrondata.com.INVALID> >>>> Date: Thursday, April 25, 2024 at 1:02 PM >>>> To: dev@arrow.apache.org <dev@arrow.apache.org> >>>> Subject: [DISCUSS] Drop Java 8 support >>>> Hi all, >>>> >>>> I would like to revisit the discussion of dropping Java 8 (and maybe >> 11) >>>> from Arrow's Java implementation. See GH issue[1] below. This was also >>>> discussed in the last Arrow community sync meeting on 2024-04-24. >>>> >>>> For context, this was discussed[2] last year on this mailing list. We >>>> decided to revisit the discussion around the June 2024 release (Arrow >>> v17). >>>> The timing coincides with the initial release of Apache Spark 4.0.0, >>> which >>>> drops both Java 8 and 11 support. >>>> >>>> For background, we chose not to drop Java 8 support last year because >>> Arrow >>>> is seen as a low level library that should support as many environments >>> as >>>> possible. Nowadays, we see more enthusiasm for dropping Java 8 (and 11) >>> as >>>> exemplified by Apache Spark as well as Apache Iceberg[3]. >>>> >>>> Is it time to consider dropping Java 8? Should we drop Java 11 and skip >>>> straight to Java 17 as our minimum version? What implications do we >> need >>> to >>>> be aware of? >>>> >>>> Thanks, >>>> Dane >>>> >>>> [1]https://github.com/apache/arrow/issues/38051 >>>> [2]https://lists.apache.org/thread/s07jx58yw4mkl54t3bkggnyg0sftcrr8 >>>> [3]https://lists.apache.org/thread/ntrk2thvsg9tdccwd4flsdz9gg743368 >>> >>
