Currently, we are not generating all possible field lambda forms.

Field lambda forms have these dimensions:
- get/set
- instance/static/static+class init barrier
- plain/volatile
- 8 primitive types, no-cast object, object with cast

Bringing to a total of 2 × 3 × 2 × 10 = 120 lambda forms.

Previously, the ones with init barrier or object with cast types were not 
generated due to spamming the Kind enum. In retrospect, I believe skipping the 
object with cast form is a poor choice - tons of Java fields are using 
non-interface types. Also seems the volatile accessors were omitted in 
InvokerBytecodeGenerator, which made their pregen useless.

I have utilized erased method types to distinguish forms - get/set, 5 basic 
types, and instance/static can be distinguished by the types, so the Kind enums 
now only represent init, volatile, and non-basic types (byte, char, short, 
boolean, casts), bringing the total constants to 24 down from 40 previously.

In the long run, we should investigate update `Kind` to allow flexible 
representations - an enum is too restrictive especially with the erased types.

-------------

Commit messages:
 - Accidental name conflicts
 - 8355442: Reference field lambda forms with type casts are not generated

Changes: https://git.openjdk.org/jdk/pull/24887/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24887&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355442
  Stats: 159 lines in 4 files changed: 29 ins; 37 del; 93 mod
  Patch: https://git.openjdk.org/jdk/pull/24887.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24887/head:pull/24887

PR: https://git.openjdk.org/jdk/pull/24887

Reply via email to