I was also wondering about how this will be expressed in MethodHandles
if we don't differentiate Q from L any more.... It means we don't have
a java.lang.Class for the "Q" flavour so we can't use MethodTypes to
differentiate any more (and that includes losing asType /
castArguments to do casts). Would we need to add a new MH combinator
to handle RefinementType casts?
I'll let John speak to the classfile-encoding-of-refinements.
But yes, you have it right -- we'd add a MH combinator for refinement
type casts / anewarray. This aligns MHs with how bytecoded methods
work; we don't have restrictions for method parmeters/returns (yet)
either. Our experiments suggested that the cost of the extra null
channel for scalarizing LFoo vs QFoo was pretty much negligible (some
extra register pressure).
