java 调用类的参数,与Java方法调用中的类型参数相关的问题

The Java Language Specification for Java 8 provides an example of a method call with a type argument in "Example 4.11-1. Usage of a Type":

void loop(S s) {

this.loop(s); // is the the type argument for the method call.

}

In that example the supplied type argument is meaningful, but apparently type arguments for method calls can also be redundant and completely meaningless, and generics need not even be involved. For example:

void m() { }

void test() {

m();

this.m();

this.m(); // Compiles and runs OK!

this.m(); // Compiles and runs OK!

m(); // Won't compile: "illegal start of expression"

}

I have a couple of questions arising:

Can anyone suggest a valid reason for Java allowing these redundant type parameters? Accepting that they do no harm, it still seems to me like something that the compiler could and should catch.

That code only compiles if the method calls with type arguments are prefixed with "this.". Otherwise you get "illegal start of expression" errors. Is that a bug? Shouldn't any unambiguous method call that works with "this." also work without "this."?

(The catalyst for these questions is Oracle's response to a bug report I created for an interesting Java problem someone raised here on SO.)

UPDATE Sep 18, 2015

I raised bug JDK-8098556 for this issue with Oracle. Here is their response:

This is not an issue; method references are checked using same rules as plain methods - note that for ordinary methods you can always supply redundant type-arguments:

void m() { }

this.m(); //legal

Method (and constructor) references simply inherit this behavior, as per 15.13:

""If the method reference expression has the form ReferenceType :: [TypeArguments] Identifier, the potentially applicable methods are the member methods of the type to search that have an appropriate name (given by Identifier), accessibility, arity (n or n-1), and type argument arity (derived from [TypeArguments]), as specified in §15.12.2.1."

Since that response confirms the information TAsk had already provided below (including citing the relevant section of JLS), I have accepted that answer.

解决方案

Following are the ways of method invocation :

JLS 15.12 lists following ways for invocation of method,

MethodName ( [ArgumentList] ) (Note : This does not have type argument)

TypeName.[TypeArguments] Identifier ( [ArgumentList] )

ExpressionName.[TypeArguments] Identifier ( [ArgumentList] )

Primary.[TypeArguments] Identifier ( [ArgumentList] )

super.[TypeArguments] Identifier ( [ArgumentList] )

TypeName.super.[TypeArguments] Identifier ( [ArgumentList] )

So, it is there in Java language specification that method with expression or type name can have type arguments but note that in first method call you can not specify type argument as it's illegal.

Note that only this does not have allowed this but static call and super method calls can also have type arguments and those are totally legal.

static void m() { }

void test() {

ClassName.m();//Also compiles

}

Other than that you will have following warning,

Unused type arguments for the non generic method m() ...

Which stands for following statement of JLS 15.12.2.1,

This clause implies that a non-generic method may be potentially

applicable to an invocation that supplies explicit type arguments.

Indeed, it may turn out to be applicable. In such a case, the type

arguments will simply be ignored.

It says Indeed, it may turn out to be applicable (at run time)

Moreover,

This rule stems from issues of compatibility and principles of substitutability. Since interfaces or superclasses may be generified independently of their subtypes, we may override a generic method with a non-generic one. However, the overriding (non-generic) method must be applicable to calls to the generic method, including calls that explicitly pass type arguments. Otherwise the subtype would not be substitutable for its generified supertype.

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值