Hi All,

As we move towards the next major version of TinkerPop, it may be time for
us to start thinking about removing support for bytecode and only allowing
script execution. One of the purposes that bytecode served was to provide a
universal way to translate a Traversal. However, with the introduction of
the gremlin-lang parser this need can be fulfilled differently. Any Gremlin
script can be converted into a Traversal in a uniform way which reduces the
need for bytecode. Now, we are left with two systems that serve a similar
purpose and it is probably time to remove one of them during a major
version upgrade. One issue with bytecode is the complexity needed in the
JavaTranslator to translate bytecode into a traversal. There are lots of
nested loops and lots of reflection needed to hold the system together. The
parser, on the hand, is a simpler system, however, it lacks some features
that will need to be implemented. For example, there are some types such as
UUID, Set, Edge and ByteBuffer that are missing from the gremlin-lang
grammar that need to be added. To clarify, the GLVs will still allow for
creating a Traversal in that particular language, however, it will turn
that Traversal into a script rather than bytecode to send to the server.
The server will then use one of the ScriptEngines to process the query.

If we can agree towards moving to script only queries then the next step is
to decide which should be the primary ScriptEngine to execute the queries.
I believe promoting gremlin-lang to be the default ScriptEngine instead of
gremlin-groovy is the better choice. While gremlin-groovy is extremely
flexible since it can execute any arbitrary Groovy code, that flexibility
comes at the cost of security as anything can be executed. Having such a
flexible system also makes it difficult to move towards supporting certain
features in standard steps as users will sometimes write partial
implementations with their own lambdas.

Are there any thoughts about removing bytecode and switching to
gremlin-lang?

Thanks,
Ken

Reply via email to