Method reference assignment compatibility

Neal Gafter neal at
Thu Jun 26 15:20:27 PDT 2008

On Thu, Jun 26, 2008 at 4:27 AM, Mark Mahieu <mark at>

> Neal,
> Given a method with the signature:
>        void subscribe(Topic topic, {Message=>void} processor)
> I might want to pass myPriorityQueue#offer(Message) as the second argument,
> but this isn't permitted since Queue<E>#offer(E) has a boolean rather than
> void result type.
> Obviously I can get around this using a closure literal {Message msg =>
> myPriorityQueue.offer(msg);}, however given:
>        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.

> Under BGGA, if I had used a method reference myProcessor#process(Message)
> as the argument to the subscribe() method above, then this API change will
> have broken source compatibility.
> So my question is: would it be problematic to allow a method reference with
> a non-void result type to be assignment compatible with an interface or
> function type with a void result type (all other conditions being
> satisfied)?

I don't really have strong feelings about this one way or another.
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the closures-dev mailing list