8184777: Factor out species generation logic from BoundMethodHandle

Christoph Dreis christoph.dreis at freenet.de
Tue Nov 14 14:29:27 UTC 2017

Hi Claes,

Thanks for incorporating this.

> > ClassSpecializer.java
> > L510: * For example, a concrete species for two reference and one integral
> bound values have a shape like the following:
> > Should be imho:
> > L510: * For example, a concrete species for two references and one
> integral bound value has a shape like the following:
> >
> > LambdaFormBuffer.java:
> > L333: if (oldFns.size() == 0)  return this; Could be:
> > L333: if (oldFns.isEmpty())  return this;
> nice catches! Fixed and updated webrev in-place.
> http://cr.openjdk.java.net/~redestad/8184777/open.00/

I still think it should be called "one integral bound value" instead of "values" and "has" instead of "have" (at least in case a singular species is meant).
You seem to have fixed the singular "reference" typo only in ClassSpecializer.java.

While looking at ClassSpecializer again, I found two additional editorial things I wanted to raise:

364          * @return class name, which by default is {@code outer().topClass().getName() + "$Species_" + deriveTypeString(key)}
 365          */
 366         protected String deriveClassName() {
 367             return topClass.getName() + "$Species_" + deriveTypeString();
 368         }

The @return doesn't seem to match the implementation. This looks a bit weird at least.

328          * and produces a value of the required type.
Should be "produce a value" given that "supply" is used some lines above.

Again - I hope you don't mind these minor comments.


More information about the core-libs-dev mailing list