This is really low-level IO stuff so unless you are a Graph Provider you can probably largely ignore this. If you were following along on JIRA you probably already know what this post is about:
https://issues.apache.org/jira/browse/TINKERPOP-1402 Basically, there is no way for a Graph implementation to specify a ClassResolver to a GryoMapper. Up until now, we've relied on the user to make that specification themselves. Why did that happen? Well, ClassResolver came along after the IoRegistry work as an added customization to IO that providers could tack in. ClassResolver is a feature specific to Kryo and not so easily generalized to other IO packages that we have. It's not a terribly well known feature and you really need to know what you're doing when you write one, but basically it allows for some very fine grained control of how Kryo does its work. Of course, when you have one it would be much nicer if the Graph just handled that configuration for you and then the user wouldn't have to worry about it. In some discussion with Bryn on that ticket, we think our best approach is to just deprecate Io.Builder.registry() and include a new method called: public Builder<? extends Io> onMapper(final Consumer<Mapper.Builder> mapper); With that method a Graph provider could do whatever they liked to the Mapper.Builder which would include adding an IoRegistry, adding a ClassResolver, etc. Since we are just deprecating, this would be a non-breaking change. I think we would only look to make this change in master for the 3.2.x line of code. If there are no objections in the next 72 hours (Friday, August 12, 2016, 2:00pm EST), I'll assume lazy consensus and press forward with implementing that change. Thanks, Stephen
