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-Nashorn-with-different-Java-versions ). [image: image.png] I closed my PR https://github.com/apache/druid/pull/14795 since we are still supporting Java 8. Once we drop support for Java 8, we can switch to the standalone Nashorn dependency. The other option is we can have different extensions for Java 10 and below, vs Java 11 and above but that is kinda confusing and we will drop support for Java 8 anyway.
On Thu, Jul 25, 2024 at 3:01 PM Gian Merlino <g...@apache.org> wrote: > 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 <mayt...@apache.org> > wrote: > > > +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 > > > > > > > > >
