> On 7 Nov 2017, at 14:18, fo...@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.
