The motivation here is that we wanted to preserve the ability to
describe "special" indy sites with special objects. The standard
implementation can describe any indy site (bootstrap, static args,
invocation name and type), but some indy sites (e.g., lambda capture)
are "special". It would be reasonable for a classfile parser to
"uplevel" such sites, so that (a) parsers could provide implementations
that interpret the semantics of the bootstrap argument list relative to
the known bootstrap method, and (b) so that class generators (including
compilers) could provide higher-level descriptions of the indy. This
allows us to abstract away from the details of compiler translation, by
"unlowering" translation-by-indy for known bootstraps.
On 5/20/2021 7:43 PM, Mandy Chung wrote:
On Thu, 20 May 2021 22:35:38 GMT, Thiago Henrique Hüpner
<github.com+13357965+thi...@openjdk.org> wrote:
I should have made it clear. I was expecting `DynamicConstantDesc` should be
`sealed`. Do you expect non-JDK implementation class extending
`DynamicConstantDesc`?
From the ConstantDesc Javadoc:
* <p>Non-platform classes should not implement {@linkplain ConstantDesc}
directly.
* Instead, they should extend {@link DynamicConstantDesc} (as {@link EnumDesc}
* and {@link VarHandleDesc} do.)
Thanks. I missed this javadoc.
-------------
PR: https://git.openjdk.java.net/jdk/pull/4135
