As Nashorn is deprecated, I was wondering if Camunda has a plan on this topic.
I found this in the Forum, but the answer doesn’t say much in this regard:
Your best bet is probably: https://github.com/graalvm/graaljs
Has anyone actually replaced nashorn with the graaljs engine?
You can now bring the graal js engine into a normal jvm without graal. So a replacement should be more straightforward. Overall though if you have this level of requirement I would recommend you look at using the external task pattern.
Hi Stephen, not sure I understand your reference to the external task pattern. We have alot of workflows that use inline javascript. If the Jdk maintainers go ahead with the removal of Nashorn from the Jdk (without providing someone providing it as a separate dependency) would we be have to re-write all of our workflows to use the external task pattern to replace processing that currently happens inline in javascript?
I have tried using the graaljs engine to run a unit tests against a workflow and have run into some issues. I don’t understand the internals of how these engines work but the graal one seems to have the following problems:
-
can’t seem to access variables like execution, task and connector. (setting it up in Nashorn compatibility mode resolved this, but it doesn’t seem like a long term solution)
17:47:28.728 [] ERROR org.camunda.bpm.engine.context - ENGINE-16004 Exception while closing command context: Unable to evaluate script:org.graalvm.polyglot.PolyglotException: TypeError: invokeMember (getVariable) on JavaObject[org.camunda.connect.plugin.impl.ConnectorVariableScope@75507e68 (org.camunda.connect.plugin.impl.ConnectorVariableScope)] failed due to: Unknown identifier: getVariable -
Spin issue: ReferenceError: S is not defined
I was just wondering if anyone had actually got this to work or if Camunda has a plan/migration path for this at all.
You have to build and install/register a new script engine in the Camunda process engine config.
So if you have graal / a new js engine then you could create a new Camunda script engine wrapper and register it. When you create this wrapper you are setting up the injections of things like execution as Spin.
I have not done it.
For external task:
Where you are running your scripts you could run these are a External task where you scripts are executing on a worker server and returning the result over http. For listeners you can create a java delegate that executes a script somewhere similar to a lambda execution. You would have to add a additional wrapper to handle variable updates (if you need it).
The use of the external task is growing in usefulness as the orchestration scenarios scale: if you have scripts being created by many different groups, be aware that scripts execute just like java code: they can do anything and access everything.
External scripts also scale better because when your script executes locally it’s eating up the thread. So if your script takes 5 seconds then that’s blocking a Camunda thread for 5 seconds.
Hi Stephen, thanks for the additional info! It seems like the external task pattern is probably the better way to go long term. We will have to figure something out for our existing stuff, but anything new we should consider the external task pattern.
@Andrew_Henderson, I have recently created an incubator project to replace Nashorn with GraalVM for our Magnolia projects with success. I’m running it internally (just including the GraalVM SDK and GraalVM JS dependencies in Maven), and haven’t run into issues. I started off by looking at this project: https://github.com/graalvm/graal-js-jdk11-maven-demo.git
I chose not to use the Nashorn Compat mode, and went directly for using Context. It was pretty straight-forward from there.