-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ScriptTagger and Nashorn engine #89
Comments
Probably the best thing is to bow to the inevitable and to include Groovy with groovy as the default script engine implementation. |
Another option, although slower: And then there is GraalVM's JS engine, but that looks a little harder to add. |
Given GraalVM comes standard with JDK 11, and supports backward compatibility with Nashorn, it looks like a more than a suitable alternative (being a more complete implementation and being more efficient). That being said, it does not prevent from adding Groovy as an option. |
Does Graal come standard with OpenJDK 11? That means, I don't need to go through the jazz in: https://medium.com/graalvm/graalvms-javascript-engine-on-jdk11-with-high-performance-3e79f968a819 |
The OpenJDK 11 I have, from Azul.com, is a supported version we pay for, because Oracle will not offer support on JDK 11 long enough for us. This version at least does not include Graaljs. Another significant issue for performance, is that the ScriptEngine cannot compile the code ahead of time and then invoke an Invokable within the evaluation code as is done in the Maven repo. linked above. So, then, compilation is done for each invocation of the ScriptEngine. I guess that is OK. How I checked for Graal on my JDK:
|
I am updating my code to work under OpenJDK 11, as soon Oracle will stop supporting Java 8, and my institution, as government may be expected to do, is moving on.
After some adjustments, my tests mostly work, but I say the following error message"Warning: Nashorn engine is planned to be removed from a future JDK release" in a verify test that runs with the actual importer configuration I use in production. The problem I gather is the ScriptTagger.
JEP 335 states that the Nashorn engine will be removed from a future release. Long term, that's probably a good thing, but the ScriptTagger defaults to using the Nashorn engine, and so work should be done to find a better alternative default ECMA script implementation so that importer configurations similar to the following continue to work:
The text was updated successfully, but these errors were encountered: