A "RecursiveConstants" attribute

[Brian Goetz]

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