15.12.2.1: Clarify potential compatibility of method references

Per the JLS, "A method reference expression is potentially compatible if <...> there exists at least one potentially applicable method for the method reference expression with arity n" but if method reference has the form ReferenceType :: [TypeArguments] Identifier, then non-static potentially applicable method should have arity n-1.

Does it mean that non-static potentially applicable method with arity n-1 is not enough for a method reference to be potentially compatible?

'non-static' (method reference) is somewhat confusing here. This is a request to further explain this portion of the JLS.

https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.1

The lack of clarity is causing customer confusion and mistakes when coding their applications, such as in the following problem description from a customer, reported by their end customer...

In the Java 8 language specification, potential compatibility of method references in forms other than ReferenceType ::[TypeArguments] Identifier is defined as ¿at least one potentially applicable method is not static.¿ (15.12.2.1 Identify Potentially Applicable Methods). Since no arity check is assumed, the following code should fail to compile because of ambiguity (method reference ¿this::query¿ is potentially compatible with both replyWith methods). However javac successfully compiles the code. Is it a problem in the compiler, or omission in the spec?

class Test {
 private List<String> query(String request) {return null;}
 private List<String> query(String request, Object context) {return null;}

 private static <Message, Reply> Set<Message> replyWith(Function<Message,
List<Reply>> fn){return null;}
 private static <Message, Reply> Set<Message> replyWith(Callable<List<Reply>>
call) {return null;}

 {
   Set<String> m = replyWith(this::query);
 }
}


Java versions/OSes tested: 1.8u11, 1.8u25, 1.8u40 beta 18 on Windows 7 / Linux / MacOSX 10.9 / 10.10.

As part of our product we are creating/improving our own java programs's syntax/semantic error validation according to Java Language Specification, so any undefined behavior or difference with reference implementation (javac) costs us maintenance issues and/or unsatisfied customers with bug reports.

This particular problem was reported us by the customer: javac compiles code but it shouldn't according to the specification (in fact Eclipse's Java 8 compiler rejects the code as well). So we need to clarify the java language specification or fix javac to be consistent with specification.

Suggest clarifying this section, such as in this article...

http://baddotrobot.com/blog/2014/02/18/method-references-in-java8/