Method reference assignment compatibility

[Neal Gafter]

On Wed, Jul 9, 2008 at 7:17 AM, Mark Mahieu <mark at twistedbanana.demon.co.uk>
wrote:

> On 26 Jun 2008, at 23:20, Neal Gafter wrote:
>
>        final class Processor {
>>               // ...
>>               void process(Message msg) {
>>                       //...
>>               }
>>       }
>>
>> In Java 6, if I were to alter the process(Message) method to return a
>> value, such as a boolean indicating success or failure of the operation,
>> then I'd break binary compatibility but I think source compatibility would
>> be preserved.
>>
>> No, this breaks source compatibility.  Another class might extend
>> Processor and implement an interface, and use the inherited process(Message)
>> method as an inherited overrider.
>>
>>
> I can see how that might apply if only the process method were final, but
> not the Processor class, as in the example.


First, let me say that I expect to make this case (for method references)
work as you prefer.  But back to the Processor example regarding source and
binary compatibility...

We generally don't use the finalness of methods or classes to affect the
type system, so I've removed that from the discussion.  Here is how the
change to Processor breaks source compatibility:

=> Before.java <=
class Processor {
  public void process(Object o) { }
}
interface I {
  public void process(Object o);
}
class Mine extends Processor implements I {}

=> After.java <=
class Processor {
  public Object process(Object o) { return null; }
}
interface I {
  public void process(Object o);
}
class Mine extends Processor implements I {} // error

Regards,
Neal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20080709/69dbdb6d/attachment.html