RFR 8187742 Minimal set of bootstrap methods for dynamic constants
paul.sandoz at oracle.com
Tue Nov 7 22:37:03 UTC 2017
> 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:
>>> 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
>>> 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
>>> 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.
More information about the core-libs-dev