AbstractList etc. functionality as interfaces with default methods?

[Remi Forax]

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 <vitalyd at 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" <forax at 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
>>>
>>>