RFR 8187742 Minimal set of bootstrap methods for dynamic constants

[Paul Sandoz]

> On 7 Nov 2017, at 14:18, forax at univ-mlv.fr wrote:
>> 
>> Try passing Class.class to it. To be honest this is somewhat motivated by
>> testing when called explicitly.
> 
> see my answer to John.
> 

Fair point, i’ll go with Class<?>. It’s the less smelly option.

Updated along with other changes:

  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/> 


>> 
>> 
>>> If you have invoke(), you do not need enumConstant because you can cook a
>>> constant method handle Enum.valueOf and send it to invoke.
>> 
>> It’s also possible to support via getStatic as well, as is the case for
>> primitive class.
>> 
>> We went back and forth on the generic and specific axis. For cases where we
>> considered constants are “honorary" members of the constant pool we provide
>> explicit BSMs.
>> 
>> 
>>> The methods that returns VarHandles are trickier because you need a Lookup
>>> object.
>>> 
>>> getstatic should be renamed to getConstant because this is what it does.
>> 
>> No, we want to stick closely with the notion of what the BSM does, there is a
>> close connection also with MethodHandle getStatic, it’s performing a static
>> field access. “getConstant” is too vague, notionally all the BSMs return
>> constants.
>> 
>> 
>>> wrapping the Throwable in a LinkageError seems wrong to me given that a calls to
>>> a BSM already does that, so getstatic can just declare "throws Throawble" like
>>> invoke and you have the same semantics.
>>> 
>> 
>> We don’t want to declare Throwable for the API in this case. This try/catch is
>> just ceremony since a getstatic MH in the implementation can only throw a VM
>> error e.g. related to out of memory or stack overflow. I can add some comments
>> in the code.
> 
> but you do that in invoke().
> 

There is no choice when Invoking a method handle that is passed to us.

In the case of getStatic the use of a MH can be considered an implementation detail (we could use reflection) and we know what the j.l.invoke implementation does. In this case i believe only VM errors can be produced.

Paul.