[9] RFR (S) 8057656: Improve MethodType.isCastableTo() & MethodType.isConvertibleTo() checks

[Vladimir Ivanov]

 >> http://cr.openjdk.java.net/~vlivanov/8057656/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8057656
>>
>
>   854         if (!canConvert(returnType(), newType.returnType()))
>   855             return false;
>   856         Class<?>[] srcTypes = newType.ptypes;
>   857         Class<?>[] dstTypes = ptypes;
>
> Are the src and dst the wrong way around?
>
>     srcTypes = ptypes
>     dstTypes = newType.ptypes
No, they are right. Parameters and return type conversions have opposite 
directions.

>   896     private static boolean canCast(Class<?> src, Class<?> dst) {
>   897         if (src.isPrimitive() && !dst.isPrimitive()) {
>   898             if (dst == Object.class || dst.isInterface())  return true;
>
> How come if the src is primitive and the dst is an interface it returns true for any interface? I guess there are subtly different rules here for casting and conversion.
There are 2 types of converstions: MH.asType() and 
MHs.explicitCastArguemnts() with more relaxed semantics.
One of the differences is that interfaces are coerced to Object, since 
verifier allows any interface to be treated as Object.

Your questions reminded me about related changes waiting in the queue 
and I decided to include then here.

Updated webrev:
http://cr.openjdk.java.net/~vlivanov/8057656/webrev.01/

Got rid of MT.isCastableTo(). MHs.explicitCastEquivalentToAsType() is 
used instead. Also, it has detailed overview of differences between 
MT.asType() and MHs.explicitCastArguments().

Best regards,
Vladimir Ivanov

>
> Paul.
>
>> There are some corner cases which MT.isCastableTo() & MT.isConvertibleTo() don't treat right (e.g. int->String converstion of return type in MT.isCastableTo()).
>>
>> Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}.
>>
>> Reviewed-by: vlivanov, ?
>> Contributed-by: john.r.rose at oracle.com
>>
>> Thanks!
>>
>>
>> Best regards,
>> Vladimir Ivanov
>