RFR: 8265130: Make ConstantDesc class hierarchy sealed [v2]

[Brian Goetz]

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+Thihup at 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