I agree about sun setting Gryo perhaps starting with the 3.6.x release. The reasons for removing it from the code base are as follows: 1. Gryo serilization of properties is not consistent with the GraphBinary or Graphson. As an example, Gryo tries to fetch the label of the parent element when serializing a property whereas other serializers only provide the ID of the parent element. 2. GraphBinary is a direct replacement with binary serialization support and better performance. GraphBinary support has also been expanded to Python and is the default serializer starting 3.5.x release train.
Divij Vaidya On Wed, Aug 26, 2020 at 10:28 AM Stephen Mallette <spmalle...@gmail.com> wrote: > I was just perusing JIRA a bit and came across an item to upgrade to Kryo > 4.0 for a performance enhancement: > > https://issues.apache.org/jira/browse/TINKERPOP-2398 > > As I commented on that issue, which has not yet gotten a response, I > believe that upgrading to Kryo 4.0 breaks binary compatibility with Kryo > 3.0 which would mean we would probably need to stamp out Gryo 4.0 as a > result. > > I'm not sure I see the need to produce another version of Gryo as we've > deprecated it in Gremlin Server already and are pushing for wider use of > GraphBinary as a replacement for Gryo and GraphSON for network > serialization. I'm not sure where that leaves us with disk serialization > but the limitation Gryo has in not working off the JVM hampers it a bit for > what I think of as our current usage these days. > > I'm inclined to continue us on a path to full deprecation of Gryo, even for > disk, in favor of GraphBinary, in which case, I don't think it's in our > interest to introduce Gryo 4.0. Does anyone have any thoughts on this > topic? >
