[DISCUSS] Dropping support for Java 8

2024-07-15 Thread Abhishek Agarwal
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

Re: [DISCUSS] Dropping support for Java 8

2024-07-16 Thread Frank Chen
+1 On Tue, Jul 16, 2024 at 12:17 PM 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 th

Re: [DISCUSS] Dropping support for Java 8

2024-07-16 Thread Gian Merlino
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 suppor

Re: [DISCUSS] Dropping support for Java 8

2024-07-16 Thread Clint Wylie
+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 u

Re: [DISCUSS] Dropping support for Java 8

2024-07-16 Thread Maytas Monsereenusorn
+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 Nasho

Re: [DISCUSS] Dropping support for Java 8

2024-07-17 Thread Frank Chen
I also agree with Clint that we can move forward to JDK21 officially since the generational ZGC in JDK21 has been proved to be a great improvement. On Wed, Jul 17, 2024 at 8:32 AM Maytas Monsereenusorn wrote: > +1 from me too. > > Also not strictly related, but Javascript tiered broker/worker

Re: [DISCUSS] Dropping support for Java 8

2024-07-25 Thread Gian Merlino
It would make sense to me to add back Nashorn as an optional dependency, i.e. moving the Javascript stuff to an extension. On Tue, Jul 16, 2024 at 5:32 PM Maytas Monsereenusorn wrote: > +1 from me too. > > Also not strictly related, but Javascript tiered broker/worker selector > strategy and Jav

Re: [DISCUSS] Dropping support for Java 8

2024-07-26 Thread Maytas Monsereenusorn
I agree with adding back Nashorn as a dependency so that users can still use Javascript functionality. The standalone Nashorn (that we can add back as a dependency) does not work with Java 10 or less, it only works with Java 11 (see image below from https://github.com/szegedi/nashorn/wiki/Using-Nas