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

[Paul Sandoz]

On Sep 5, 2014, at 6:42 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> >> 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.
> 

Doh! of course, silly me.


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

Much clearer IMO.

+1

Paul.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20140909/016a0c13/signature.asc>