OK, so the goal is clearly to *prohibit* cyclic constants by enforcing a
depth constraint on condy-in-condy nesting. I like this goal much
better, and I see how the solution addresses it.
Still, I have to wonder whether its worth the complexity of capturing it
explicitly with a new (stackmap-like) attribute, which must be
specified, and gives us more chances for the classfile to be out of sync
with itself, for the goal of preventing something that can't usefully
happen anyway -- as we discussed previously, trying to actually resolve
a cyclic constant will likely result in SOE, so such classfiles are
pretty much useless and therefore not likely to spread very far.
Sorry, I didn't provide enough context for those who weren't part of previous
discussions. You're misunderstanding the restriction.
A CONSTANT_Dynamic with recursion depth 0 would not be allowed to have a
CONSTANT_Dynamic as its static argument. Its static arguments could only be
strings, numbers, classes, etc.
A CONSTANT_Dynamic with recursion depth 1 would be allowed to have a
CONSTANT_Dynamic as its static argument, but only if the argument has a
recursion depth of 0.
A CONSTANT_Dynamic with recursion depth 2 would be allowed to have a
CONSTANT_Dynamic as its static argument, but only if the argument has a
recursion depth of 0 or 1.
Etc.
Under no circumstances would a CONSTANT_Dynamic be allowed to refer to
itself—because in order to do so, at some point in the cycle you'd have a
CONSTANT_Dynamic with a static argument of an illegal depth.
To restate my point about layering on this restriction after 11: when enforced,
this rule gives us the property that there are no structural cycles in a
well-formed (per 4.8) constant pool. So if, say, the symbolic reference API is
building a structure from a loaded constant pool, it can assume no cycles
exist. However, if we don't enforce the rule on version 55.0 class files, we
can't retroactively enforce it later, and downstream tools won't get strong
guarantees about CONSTANT_Dynamic (however, they will have strong guarantees
about future structures like CONSTANT_ArrayType).
—Dan
