[ https://issues.apache.org/jira/browse/TINKERPOP-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stephen mallette closed TINKERPOP-1957. --------------------------------------- Resolution: Not A Problem I can't isolate exactly why there is a discrepancy in behavior between the two versions, but I sense that the behavior you are seeing is the correct one in 3.3.2 (which i still see in 3.3.3-SNAPSHOT). Your child traversal of {{outE().count()}} returns a {{Long}} which means that the {{is()}} is going to expect either {{P<Long>}} or {{Object}} given the available signatures. Your traversal gives it a {{P<Integer>}} and Groovy makes a best guess between the two options and ends up with a generics problem. Note that you can either specify the {{Long}} to get by this issue or cast to {{P}}: {code} g.V().where(outE().count().is((P) lt(50))) {code} which I guess forces Groovy down the right path. Again, I'm not clear what the discrepancy is between the two versions, but my guess is either/both of the following: 1. There is some method signature difference between 3.2.x and 3.3.x (that i can't seem to locate) that subtly allows Groovy to be happy to type check in your favor for 3.3.2. 2. I've known Groovy's approach to method invocation to be somewhat non-deterministic (seemingly) in the ScriptEngine. Anyway, my general thinking is that when faced with these kinds of situations with type checking I'd tend to assume that a more strict interpretation from Groovy is the "correct" application of that function. Also, issues like this would likely not be issues with TinkerPop as we rely completely on Groovy for this functionality. > Static Groovy script compilation requires long literals in predicates > --------------------------------------------------------------------- > > Key: TINKERPOP-1957 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1957 > Project: TinkerPop > Issue Type: Bug > Components: groovy > Affects Versions: 3.3.2 > Environment: GremlinGroovyScriptEngine with > GroovyCompilerGremlinPlugin and COMPILE_STATIC > Reporter: Konstantin Müller > Priority: Major > > When using the GremlinGroovyScriptEngine together with > GroovyCompilerGremlinPlugin and compilation option COMPILE_STATIC it is > required to use long literals instead of integer literals in predicates. For > example the following query fails during compilation: > {noformat} > g.V().where(outE().count().is(lt(50))){noformat} > This gives the following error message: > {noformat} > Script1.groovy: 1: [Static type checking] - Cannot call > org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal > <org.apache.tinkerpop.gremlin.structure.Vertex, > java.lang.Long>#is(org.apache.tinkerpop.gremlin.process.traversal.P > <java.lang.Long>) with arguments > [org.apache.tinkerpop.gremlin.process.traversal.P <java.lang.Integer>] > @ line 1, column 13. > g.V().where(outE().count().is(lt(50))) > ^ > Script1.groovy: 1: [Static type checking] - Cannot find matching method > org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#where(java.lang.Object). > Please check if the declared type is correct and if the method exists. > @ line 1, column 1. > g.V().where(outE().count().is(lt(50))){noformat} > Changing the query to use long literals makes the query work: > {noformat} > g.V().where(outE().count().is(lt(50L))){noformat} > The original query works with version 3.2.8 or if COMPILE_STATIC is NOT used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)