Nashorn engine being deprecated

[venkag]

Nashorn being deprecated in future JDK releases. Is there a plan to replace the expression evaluation going forward.

I get the following warning:

Warning: Nashorn engine is planned to be removed from a future JDK release

[aravindanr]

@venkag Thanks for bringing it up. We have plans to replace it, but it's not a high priority.

[kishorebanala]

@venkag Sure thing! We've considering migrating over to GraalVM (relevant Issue), but please feel free to post your ideas here.

[venkag]

@kishorebanala @aravindanr @apanicker-nflx

The following is my proposal:

Conductor supports two types of evaluations:

1. caseValueParam which is just a value picked up from the task's input.
2. caseExpression which is the javascript expression that is evaluated to any object but eventually converted to a string.

This is a bit rigid in the sense that the caseExpression has to be a javascript and complex conditions cannot be constructed easily. For example, custom logic has to be written in javascript for the match$.store.books[?(@.author=='Author Name')].title[0].
A different type of evaluation requires additional properties to the decision task.

The decision evaluation process can be made flexible with the following attributes:

• Any type of evaluator can be plugged in
• The condition evaluation happens in the code in stead of any interpreter engine.

Two variables will be introduced called caseEvaluatorType and caseEvaluationExpression.

For each caseEvaluatorType that conductor supports an evaluator is registered. Expression is any expression (String) that the evaluator understands (formats, patterns etc.). Conductor's decision mapper passes the expression and inputs to the appropriate evaluator to get the evaluated result.

If we were to implement caseValueParam and caseExpression with this framework the input to the decision task would look something like this:

• For caseValueParam:

            "caseEvaluatorType": "param-value",
            "caseEvaluationExpression": "number3",

The evaluator of type param-value will be looked up from a map of evaluators and just plugs in the value from task's input.

• For caseExpression:

            "caseEvaluatorType": "javascript",
            "caseEvaluationExpression": "typeof $.number3 == \"number\" && $.number3 == 100",

The evaluator of type javascript will be looked up from a map of evaluators and evaluates the javascript expression using Nashorn (or in future GraalVM).

The above examples will only provide feature parity but provides a framework to expand to any type of evaluation. JSONPath based evaluation (exampled mentioned above for array search) can be a different evaluator.

For backward compatibility, caseValueParam and caseExpression can be left un-modified. The two evaluators equivalent to caseValueParam and caseExpression to make it easy to deprecate in future. Any new evaluators do not need additional properties to the decision task. It will just be a matter of adding new evaluator to the map of evaluators.

I have tested this and works as described above. I can make it formal (add test cases etc.) and submit a PR if you are ok with this approach.

[apanicker-nflx]

@venkag Thanks for the detailed proposal. The idea to make the evaluator choice as a plugin makes it extensible and allows for more implementations in the future.

The evaluator/evaluation engine is used by the LAMBDA task in addition to the DECISION task and this could also benefit from this change. Please consider making a similar change to this task as well.

For backward compatibility, caseValueParam and caseExpression can be left un-modified. The two evaluators equivalent to caseValueParam and caseExpression to make it easy to deprecate in future.

It might be better to introduce a new task type (for example: SWITCH) as a replacement for DECISION and (example: INLINE) as a replacement for LAMBDA task going forward. It would be easier to deprecate and remove task types as compared to deprecating fields within a task type. The new names would also help to make these tasks more intuitive. Please feel free to suggest/use different names for these tasks as you may seem fit and please continue with a PR.

[venkag]

Thank you @apanicker-nflx. I like the idea of separate tasks. Will raise a PR.

[venkag]

PR Submitted. Please take a look @apanicker-nflx @kishorebanala @aravindanr

#2403

[Jiehong]

Alternatively, nashorn is now release independently, so it can just be re-added as an external dependency (https://github.com/openjdk/nashorn).

As long as it gets maintained, this should be an invisible change for a while longer.