We don't need no stinkin' Q descriptors

[Brian Goetz]

>
> 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).