> How can difference in client and server JVM compiler versions affect bytecode evaluation by a server?
JVM versions won't matter. Gremlin bytecode is evaluated by Gremlin so, if there were versioning issues they would be specific to TinkerPop versioning. A client on TinkerPop 3.2.5 sending bytecode to TinkerPop 3.2.4 could potentially have a problem if the it used some new feature of 3.2.5 that wasn't available at the time of 3.2.4. As we look forward with bytecode and serialization/protocol issues we will need to do more with our versioning of it so that 3.2.5 could communicate without hassles to older versions. This is a problem more generalized to remoting than just something specific to bytecode. On Thu, Apr 27, 2017 at 4:04 PM, Vladyslav Kosulin <[email protected]> wrote: > I love the idea, but here are my concerns: > How can difference in client and server JVM compiler versions affect > bytecode evaluation by a server? What if client was compiled with newer > compiler, and the server does not recognize the version of bytecode sent by > the client? I would assume it will fail. And what will happen when > serialVersionUID differs if client and server are on different versions of > application (not the tinkerpop version)? There will be no problem with > groovy string in either case, but the java bytecode evaluation may fail, > right? > > -- > You received this message because you are subscribed to the Google Groups > "Gremlin-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/gremlin-users/22b8b005-1101-4c5c-bdb4-942a4cff585f% > 40googlegroups.com > <https://groups.google.com/d/msgid/gremlin-users/22b8b005-1101-4c5c-bdb4-942a4cff585f%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. >
