Fix Javascript tiered broker selector strategy and Javascript filter for Java 17

[maytasm]

Fix Javascript tiered broker selector strategy and Javascript filter for Java 17

Description

Javascript tiered broker selector strategy and Javascript filter broke when running Druid on Java 17.
Javascript tiered broker selector strategy and Javascript filter depend on Nashorn JavaScript Engine (final ScriptEngine engine = new ScriptEngineManager().getEngineByName("javascript");). The Nashorn JavaScript Engine has been removed from Java. Deprecated in Java 11, removed in Java 15. (https://stackoverflow.com/questions/71481562/use-javascript-scripting-engine-in-java-17)

Some options I found:

• We can use different script engine, as GraalVM. (https://stackoverflow.com/a/71481633/4942837)
• We can add back the Nashorn JavaScript Engine as a dependency and continue to use it (https://github.com/openjdk/nashorn) See: https://github.com/szegedi/nashorn/wiki/Using-Nashorn-with-different-Java-versions

I chose the second option which is to add back the Nashorn JavaScript Engine as a dependency and continue to use it. Since Nashorn was the deprecated javascript engine that used to come with Java 8, I think it should be same/similar to what we had before (compare to using a new script engine like GraalVM). However, https://github.com/szegedi/nashorn/wiki/Using-Nashorn-with-different-Java-versions suggests that the standalone is not compatible with Java 8-10 and is only compatible with Java 11 and later

This PR has:

• been self-reviewed.
  • using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)
• added documentation for new or modified features or behaviors.
• a release note entry in the PR description.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• added or updated version, license, or notice information in licenses.yaml
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• added integration tests.
• been tested in a test Druid cluster.

[github-actions]

This pull request has been marked as stale due to 60 days of inactivity.
It will be closed in 4 weeks if no further activity occurs. If you think
that's incorrect or this pull request should instead be reviewed, please simply
write any comment. Even if closed, you can still revive the PR at any time or
discuss it on the dev@druid.apache.org list.
Thank you for your contributions.

[github-actions]

This pull request/issue has been closed due to lack of activity. If you think that
is incorrect, or the pull request requires review, you can revive the PR at any time.

[jakubmatyszewski]

Hey @maytasm, would you possibly revive this PR? Support for Java 8 was dropped with #17466
I think with this out of the way, it should be okay to implement the nashorn standalone.

[maytasm]

Reopening this PR as Java 8 was dropped. We have been using this patch running on Java 17 for the last year and found no issue.

[FrankChen021]

@maytasm I'm curious that what kind of javascript code you're using for the select strategy?

[maytasm]

@FrankChen021 Looking at query interval and certain key in the query context

[jakubmatyszewski]

I believe this should be merged and included in Druid 32.0.0 release #17677 since javascript strategies won't work on recommended JDK version, this might be braking change for some people!

[cryptoe]

@adarshsanjeev Lets mention this in the upgrade notes . We are too far along the process to do another RC now. Lets include it in druid 33.

[maytasm]

Actually, I think we can't use org.openjdk.nashor since it is under GNU General Public License v2.0 ?

[capistrant]

Actually, I think we can't use org.openjdk.nashor since it is under GNU General Public License v2.0 ?

I believe that assessment is correct, Maytas

via gen AI prompt:

No, it is not allowed to add a dependency that is licensed under the GNU General Public License v2.0 (GPL-2.0) to a project under the Apache License 2.0 (ALv2) if that dependency is being used in a way that would result in the combined work becoming subject to the GPL-2.0.