> On Feb 12, 2018, at 6:51 PM, David Holmes <david.hol...@oracle.com> wrote: >>> But I, for one, prefer a "user pays" scheme over an "everyone pays" scheme >>> (which is what disallowing duplicates would also be). >> It’s an awkward situation, experience suggests this type of thing bites back >> later on, so my inclination is to take the hit in the JDK and not return >> dups. The implementation might be able to cache information on the internal >> ReflectionData class. > > Please see John's response on this: > > http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2017-December/000465.html >
Thanks for the context. You may be surprised to learn that i still don’t agree :-) so i will just state my objection more concisely and move on: I don’t think as specified the method serves developers very well for the common use-case of iterating over the nest mates and performing actions with side-effects. A developer will have to write defensive code or, more likely, write buggy code that will blow up in the rare case a classfile contain duplicates e.g. generated by something other than javac. That rare case may be hard to track down and expensive to fix. Paul.
