Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 401010 - [1.8][spec] Clarification required on computation of compile time declaration for a method reference
Summary: [1.8][spec] Clarification required on computation of compile time declaration...
Status: RESOLVED WORKSFORME
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 4.3   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: BETA J8   Edit
Assignee: Srikanth Sankaran CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 401003
  Show dependency tree
 
Reported: 2013-02-17 07:11 EST by Srikanth Sankaran CLA
Modified: 2013-12-18 20:38 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Srikanth Sankaran CLA 2013-02-17 07:11:33 EST
(1) 0.6.1, 15.28.1 reads: 

----------------------- 
Given a function descriptor with parameter types P1..Pn, the compile-time declaration for a method reference is determined as follows. 

If the method reference is qualified by a ReferenceType, two searches for a most-specific applicable method are performed, following the process outlined in 15.12.2. Each search may produce a method or, in the case of an error as specified in 15.12.2, no result. 
First, the reference is treated as if it were an invocation of a method named by Identifier with argument expressions of types P1..Pn; the type to search is the ReferenceType; the type arguments, if any, are given by the method reference. 

Second, if P1..Pn is not empty and P1 is a subtype of ReferenceType, the reference is treated as if it were an invocation of a method named by Identifier with argument expressions of types P2..Pn. If the ReferenceType is a raw type, and there exists a parameterization of this type, G, that is a supertype of P1, the type to search is G; otherwise, the type to search is the ReferenceType. Again, the type arguments, if any, are given by the method reference. 

If both of these searches match a method, the reference is considered ambiguous. 

Otherwise, if the first search matches an instance method or the second search matches a static method, no method is chosen. 

Otherwise, if one of the searches matches a method, that is the compile-time declaration. 
---------------------------- 

The first mention of static occurs in the penultimate sentence of the quoted text: Does that mean the following program 
should be declared ambiguous ? (8b74 compiles this fine, but at run time there is an NPE) - There is no real ambiguity here. 

// ---- 
interface I { 
  void zoo(Y y, String s); 
} 

class Y { 
        void zoo(String s) { 
                System.out.println("Y.zoo(String)"); 
        } 
        void zoo(Y y, String s) { 
                System.out.println("Y.zoo(Y, String)"); 
        } 
} 


public class X  { 
    public static void main(String[] args) { 
            I i = Y::zoo; 
            i.zoo(null,  null); 
        } 
} 
// ----------- 

I think this calls for a reordering of clauses and perhaps some rewording ? 
The sentence "Otherwise, if the first search matches an instance method or 
the second search matches a static method, no method is chosen." is a bit 
vague ? i.e does this mean "No method is chosen as the compile declaration 
of the method reference" or that "these matches are eliminated from further 
reckoning ?" 

Also the sentence "If both of these searches match a method, the reference 
is considered ambiguous." preceding the first utterance of 'static' would 
render the program above illegal. 

Or reword the passage "First, the reference is treated as if it were an 
invocation of a method" to "First, the reference is treated as if it were an 
invocation of a _static_ method" and likewise massage the second part too ? 

(2) Should the passage "Also note that static method invocations have the form TypeName.method(), 
while here we're using the more general ReferenceType; an error occurs if the reference ends up being a 
static method reference and the qualifier is a parameterized type." be relegated to the motivation box ?
Comment 1 Srikanth Sankaran CLA 2013-02-17 18:09:29 EST
I unsuccessfully searched through my old mails for the surveys we did a while ago and to see 
what we concluded on that - no luck there. I recall that we banned a bound reference targetting 
a static method, but not sure what was agreed to be done when a ReferenceType form "selects" an 
instance method. Ban on the former case had the point going for that with hindsight it is a 
known bad form. But in the latter case, the method is simply not applicable due to absence of 
receiver and is arguably best eliminated from reckoning rather than declare error.   

Perhaps the spec is consistent with the survey conclusions, but the reference compiler is 
not consistent with the spec ? 

Also point (2) in comment#0 *is* properly mentioned in the main text.
Comment 2 Srikanth Sankaran CLA 2013-12-18 20:38:07 EST
There are no open issues in this area. The latest spec is implemented.
Resolving.