When using the structural equality comparer on an object graph that contains reference loops (e.g. JsonNode), the comparer throws StackOverflowException. This limitation is not documented.
We could do document the limitation and keep strict structural equality.
But if we think about two object graphs and we want to know if they are structurally equal, is it fair to say that reference equality within each graph should be preserved? If so, we can perhaps add support for loops. What I mean by that is that although the two graphs share absolutely no object references, if one graph refers to the same object at multiple points, the second graph must also refer to its own copy of the same object at exactly those same structural points.
That would probably defeat serializer/deserializer round-trip tests unless that serializer could also preserve reference equality. So this behavior should be under a switch. But if we had it, then we could safely test for reference equality where a loop would otherwise cause us to crash by blowing the stack.
Another, simpler option would be to simply detect reference loops and throw a NotSupportedException instead of blowing the stack.
When using the structural equality comparer on an object graph that contains reference loops (e.g.
JsonNode), the comparer throwsStackOverflowException. This limitation is not documented.We could do document the limitation and keep strict structural equality.
But if we think about two object graphs and we want to know if they are structurally equal, is it fair to say that reference equality within each graph should be preserved? If so, we can perhaps add support for loops. What I mean by that is that although the two graphs share absolutely no object references, if one graph refers to the same object at multiple points, the second graph must also refer to its own copy of the same object at exactly those same structural points.
That would probably defeat serializer/deserializer round-trip tests unless that serializer could also preserve reference equality. So this behavior should be under a switch. But if we had it, then we could safely test for reference equality where a loop would otherwise cause us to crash by blowing the stack.
Another, simpler option would be to simply detect reference loops and throw a
NotSupportedExceptioninstead of blowing the stack.