On Jan 19, 2018, at 1:40 PM, Dan Smith <daniel.sm...@oracle.com> wrote: > > The followup question is: when should we try to deliver it? > > - SE 11: get it in when condy is introduced, avoid allowing any cyclical > constant pools to escape into the wild > - Sometime soon after 11: address compatibility by easing into it, perhaps > following the path of StackMapTable (optional at first) > - Next time we introduce a cyclical attribute: let condy be, don't disrupt > anything until we need this check somewhere else > > The SE 11 option has the advantage of avoiding future historical baggage > (e.g., otherwise, to support 55.0 class files, the resolution-time check must > remain in place forever). It has the disadvantage that it's late in the game > to be introducing new JVM attributes.
I don't mind fitting it in soon, as long as it doesn't slow the next increment of condy. The link-time circularity check is (I think) cheap enough to disregard as a downside. It can probably just stay in there as a belt-and-suspenders check. We can surely tweak the check if it ever shows up on Claes's performance tests. So the main downside of delaying it is the (small!) risk of cyclic CPs sneaking into the ecosystem, and then being rejected in the future. As you suggest, it could be rolled into a template classes design, where circularity checking is much more urgent. — John
