Github user jorgebay commented on the issue:
https://github.com/apache/tinkerpop/pull/695
I've removed support for Nashorn as part of #626 (see first comment).
JavaScript engines don't provide a standard way to deal with and import
modules, so supporting with multiple runtimes is usually a pain (unlike other
languages like Python that has the `import` system built-in).
If to support `GremlinJavaScriptScriptEngine` we need to support Nashorn on
the GLV, we should try to split the GLV and the JS script engine in 2 separate
tickets and try to tackle those separately.
Having a JavaScript GLV would enable users to write their traversals in js,
making it easier for users from the js community to use Gremlin. On the other
side, supporting js lambdas is a more marginal use case.
> I think the need to figure out the language agnostic way to test GLVs is
becoming more important
I think testing a GLV (bytecode generation, websocket connection, type
mapping, ...) can't be implemented in a runtime agnostic way because the whole
concepts are defined by the runtime. I think we can define a set of behaviours
that the GLV must adhere. We can define a set of given-when-then statements (in
doc), which we can make sure each GLV implements in actual tests.
On the other hand, I think testing a script engine can be generalized into
a common suite (like ScriptEngineLambdaTest) plus specialized behaviour tests
per language.
---
