I'd really like to get our IO situation really solid in 3.3.0 and while we talk about GraphSON a lot I think Gryo still has an important place in our serialization story. Gryo covers an extended set of classes that goes beyond what we cover in GraphSON. I don't know if all those registered classes matter though - one would think that we just need parity with GraphSON defined classes.
https://github.com/apache/tinkerpop/blob/9f13e69853c03a2fde77efd40c6526b91a4b346a/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/gryo/GryoVersion.java#L192 I think that the reason this area of code has grown so much is from the basis of another issue with gryo which is that we don't always have a nice separation between implementations and serialized classes. In other words, if we have some complex class like DefaultTraversalMetrics, we just register all the classes that DefaultTraversalMetrics has as fields (and all the classes those classes use) until the serialization works. While this is really easy and, in a sense, convenient, it creates some problems: 1. We get this big long registration list which includes types we don't support in GraphSON (which typically aren't tested) 2. We have now bound the serialization of the complex class to its structure. If there is a problem with DefaultTraversalMetrics in the future and we have to change a field we essentially break all compatibility within gryo. (i'm facing this issue now actually). I would really like Gryo 3.0 to do a better job in this area, allowing for better forward and backward compatibility with a more limited class registration list that is more in line with the types defined for GraphSON support. I think we can get better forward/backward compatibility if (1) there is better separation between the object being serialized and the object used in application logic (think of the "detached" classes) and (2) gryo serializers for 3.0 have greater intelligence around internal compatibility handling. Anyway, I was mostly writing this as notes to myself in preparation for 3.3.0, but I'd be happy to hear any thoughts anyone might have on this.
