[BUG] Throw ExecutionException for E() syntax

[llooFlashooll]

We discovered a bug that Throw ExecutionException for E() syntax.

• OrientDB version: 3.2.14
• Operating system: macOS 13.2.1
• API/Driver: Java

I first randomly create a graph. Then when I run the following query: g.E().inV().inE('el1','el3').as('a').E().not(__.values('ep8')).as('b').select('a').where('a',eq('b')) is thrown with an exception. I think this query is syntactically correct, but I keep triggering this kind of problem. I generate the query based on the rule which can be refered from: https://stackoverflow.com/questions/48067834/gremlin-intersection-operation. Following this instruction, I think it's allowed to generate this kind of queries.

Expected behavior:

No exception should be expected to throw. Or futher messages or prompts should be thrown.

Actual behavior:

A java.util.concurrent.ExecutionException is thrown. And I'm not really sure whether this problem should happen so I report this. I succeed this kind of collection transition when replacing g.E() with g.V(). So I guess there's some problems of g.E() syntax. I report just in case

Orientdb exception :
java.util.concurrent.ExecutionException: org.apache.tinkerpop.gremlin.driver.exception.ResponseException: No signature of method: org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.DefaultGraphTraversal.E() is applicable for argument types: () values: []
Possible solutions: by(groovy.lang.Closure), is(java.lang.Object), use([Ljava.lang.Object;), use(java.util.List, groovy.lang.Closure), use(java.lang.Class, groovy.lang.Closure), any()

Steps to reproduce:

We create a graph with 10 nodes and 20 edges. We try to make it clear to reproduce the bugs, hope to not cause much inconvenience to your reviewing, but we believe the problem does exist.
Following the following graph data generation query, we can reproduce the bugs:

• Create data

Vertex:
g.addV('vl0').property('vp3','1673037296').property('vp5',''藰Yvq'').property(T.id,#257:254)
g.addV('vl0').property('vp3','1673037296').property('vp4','1673037296').property(T.id,#250:263)
g.addV('vl0').property('vp0','0.9215627').property('vp3','-1694718156').property('vp5',''晛bT*4'').property('vp4','-700646806').property(T.id,#251:262)
g.addV('vl0').property('vp3','-1771674021').property(T.id,#252:261)
g.addV('vl0').property('vp0','0.7261416').property('vp4','-1341409109').property(T.id,#253:261)
g.addV('vl0').property('vp3','-1694718156').property(T.id,#254:259)
g.addV('vl0').property('vp0','0.23608613').property('vp3','79154488').property('vp5',''z촸WOU'').property('vp4','-1158149286').property(T.id,#255:258)
g.addV('vl0').property('vp0','0.26868117').property('vp3','-1771674021').property('vp5',''晛bT*4'').property('vp4','-1771674021').property(T.id,#256:256)
g.addV('vl0').property('vp5',''J {hP'').property(T.id,#257:255)
g.addV('vl0').property('vp0','0.17523146').property('vp3','-605802681').property('vp5',''6Z,Ce'').property('vp4','-1069296977').property(T.id,#250:264)

Edge:
g.V(#254:259).as('#254:259').V(#256:256).as('#256:256').addE('el2').from('#254:259').to('#256:256')
g.V(#253:261).as('#253:261').V(#250:264).as('#250:264').addE('el3').from('#253:261').to('#250:264')
g.V(#256:256).as('#256:256').V(#257:254).as('#257:254').addE('el3').from('#256:256').to('#257:254')
g.V(#257:254).as('#257:254').V(#257:254).as('#257:254').addE('el3').from('#257:254').to('#257:254')
g.V(#251:262).as('#251:262').V(#255:258).as('#255:258').addE('el2').from('#251:262').to('#255:258')
g.V(#257:255).as('#257:255').V(#251:262).as('#251:262').addE('el1').from('#257:255').to('#251:262')
g.V(#252:261).as('#252:261').V(#255:258).as('#255:258').addE('el1').from('#252:261').to('#255:258')
g.V(#256:256).as('#256:256').V(#256:256).as('#256:256').addE('el2').from('#256:256').to('#256:256')
g.V(#257:254).as('#257:254').V(#257:255).as('#257:255').addE('el3').from('#257:254').to('#257:255')
g.V(#252:261).as('#252:261').V(#256:256).as('#256:256').addE('el0').from('#252:261').to('#256:256')
g.V(#250:264).as('#250:264').V(#250:263).as('#250:263').addE('el1').from('#250:264').to('#250:263')
g.V(#255:258).as('#255:258').V(#257:254).as('#257:254').addE('el3').from('#255:258').to('#257:254')
g.V(#252:261).as('#252:261').V(#250:264).as('#250:264').addE('el0').from('#252:261').to('#250:264')
g.V(#250:263).as('#250:263').V(#253:261).as('#253:261').addE('el1').from('#250:263').to('#253:261')
g.V(#256:256).as('#256:256').V(#250:263).as('#250:263').addE('el3').from('#256:256').to('#250:263')
g.V(#251:262).as('#251:262').V(#256:256).as('#256:256').addE('el2').from('#251:262').to('#256:256')
g.V(#250:264).as('#250:264').V(#257:254).as('#257:254').addE('el1').from('#250:264').to('#257:254')
g.V(#250:263).as('#250:263').V(#253:261).as('#253:261').addE('el2').from('#250:263').to('#253:261')
g.V(#252:261).as('#252:261').V(#250:264).as('#250:264').addE('el1').from('#252:261').to('#250:264')
g.V(#257:254).as('#257:254').V(#257:255).as('#257:255').addE('el1').from('#257:254').to('#257:255')

[tglman]

Hi,

This may be caused by the fact that orientdb 3.2.14 had a bit outdate gremling version, could you check with orientdb 3.2.18 or newer, we did update gremlin libraries in that version.

Regards