javac should emit a lint warning in these cases to help API designers.
I have created 8080413 [1] to track that.
Rémi
[1] https://bugs.openjdk.java.net/browse/JDK-8080413
On 05/14/2015 04:04 PM, Brian Goetz wrote:
The static-instance asymmetry cancels that one out. If you have
class Foo {
void m(int x)
static void m(Foo f, int x)
}
Then Foo::x could either be an unbound mref to the instance method or a static
mref. Even with a perfect target type (Foo, int) -> void, compiler will still
report ambiguity.
On May 14, 2015, at 9:52 AM, Vitaly Davidovich <vita...@gmail.com> wrote:
Ambiguous in isolation, but within context they're quite different: one
takes an arg and the other is void.
sent from my phone
On May 14, 2015 9:25 AM, "Remi Forax" <fo...@univ-mlv.fr> wrote:
On 05/14/2015 03:05 PM, Brian Goetz wrote:
Not only is there a problem with modCount, but also with
equals/hashCode/toString. You can’t define these Object methods in an
interface.
They could be defined as static methods to delegate to. From API
consistency perspective, we have for example the following static methods
on primitive wrapper classes:
Right. We considered this during Lambda, but by the time we got here, we
concluded that this was mostly trading one downside for another. It seemed
overwhelmingly likely that people would forget to override
equals/hashCode/toString in this case, and create collections that violated
the contract.
The other problem is that it creates ambiguous method references,
if you have a class or an interface like:
class A {
public static int hashCode(A a) { ... }
}
A::hashCode is ambiguous.
cheers,
Rémi
