+1 from me too. Also not strictly related, but Javascript tiered broker/worker selector strategy and Javascript filter is broken if running Druid on Java 17. The Nashorn JavaScript Engine has been removed since Java 15 and hence, we would need to use a different script engine or add back the Nashorn Javascript Engine as a dependency. (more details at https://github.com/apache/druid/pull/14795)
On Tue, Jul 16, 2024 at 2:58 PM Clint Wylie <cwy...@apache.org> wrote: > +1 from me for deprecating first then removing. I'd also like to > officially support java 21 before we totally drop support, at least > experimentally, but preferably fully. We already run unit tests with > 21, so maybe we could transition the java 8 integration tests to use > 21 instead? I've also been using 21 for all of my debugging and > testing for quite some time now and it seems fine to me. > > I know this isn't strictly related, but with 8 still supported maybe > it just seems like we are kind of slow and cautious, but if we drop 8, > it seems like our java support is in a strange place of moderately old > versions if we only officially support 11 and 17, given 21 is also an > LTS (even 11 is starting to seem a bit old to me). > > On Tue, Jul 16, 2024 at 9:21 AM Gian Merlino <g...@apache.org> wrote: > > > > I think this is a good move. Let's give users some warning by > deprecating it first prior to removal. IMO, good timing would be to > deprecate Java 8 in the next major Druid release (Druid 31). That means a > doc update, release note update, and updating the start scripts to log a > warning that support for Java 8 will be removed soon (if Java 8 is > detected). > > > > When we do remove support for Java 8, we should update the "verify-java" > script to require DRUID_SKIP_JAVA_CHECK=1 when Java 8 is detected. > > > > Gian > > > > On 2024/07/16 04:17:06 Abhishek Agarwal wrote: > > > Hello everyone, > > > Starting this thread to discuss, if and when, we can drop Java 8 > support. > > > We have been fully supporting Java 11 and Java 17 for a while now. > Anyone, > > > who is looking to upgrade Druid, can safely select either of these LTS > Java > > > runtimes. There are a few important reasons to drop Java 8 support > > > > > > - It adds extra burden on build/test pipelines to test all these > different > > > runtimes. We want to shrink this matrix of Java runtime and test > suites. > > > - Being on Java 8 will block us from upgrading dependencies that have > > > dropped Java 8 support. We can get around it by building profiles and > shims > > > but it adds more complexity. One example is pac4j which is Java 11 > based > > > from 5.x. > > > - As we drop support for older Java releases, developers can use the > > > features offered by the more advanced Java versions. > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@druid.apache.org > > For additional commands, e-mail: dev-h...@druid.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@druid.apache.org > For additional commands, e-mail: dev-h...@druid.apache.org > >
