default methods in interfaces
Zhong Yu
zhong.j.yu at gmail.com
Tue Oct 29 12:27:54 PDT 2013
On Tue, Oct 29, 2013 at 4:05 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> Hi Mohan,
>
> The primary use-case for default methods is to evolve interfaces without breaking compatibility [*]. Without such a mechanism we would not have been able to evolve the Collections API and integrate it with the Streams API.
>
> See section 10 of:
>
> http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-final.html
>
> What you are asking may have been discussed before, search here:
>
> http://openjdk.markmail.org/search/?q=lambda-dev
>
> Default methods can be used as a limited form of traits to mix-in behaviour but not state, so they ain't like Scala's traits. Any state (or context) needs to be passed as parameters to those methods. Also note that because there is no state then there are no state-realted issues associated multiple
Usually an interface with default methods is stateful, e.g. List; it's
just a slightly extra work for subclass to provide the actual storage
space. We may traits like interfaces for example
interface Colored
abstract Color getColor();
abstract void setColor(Color color);
default void trasformColor(...)...
A default method can also access `this` to obtain useful information,
for example
interface Logger
default void log(String msg)
Class logCatetory = this.getClass();
Completely stateless interfaces and default methods could also prove
useful, for example
interface Math
default int max(int x, int y)...
inheritance (Java already has multiple inheritance of types; default
methods add some additional inheritance rules for resolving conflicts,
but fundamentally they are inherited like other methods).
>
> In terms of patterns for this kind of usage, i don't have a clear answer. I
Yes, we'll have to wait to see what people can come up with when they
exploit the combination of these new tools.
Zhong Yu
expect some may evolve over time as developers evolve and implement
new interfaces that provide certain mix-in behaviour. Note that we
have been careful not to add the @FunctionalInteface annotation to all
interfaces that could be used as the target type of lambda expressions
and method references. In certain cases such non-annotated interfaces
are more intended to provide mix-in behaviour, so there is clue where
to look and watch.
>
> Hth,
> Paul.
>
> [*] Note that there is still a small risk that the methods added will clash with methods on implementing classes or other interfaces.
>
> On Oct 29, 2013, at 8:15 AM, mohan.radhakrishnan at polarisft.com wrote:
>
>> Hi,
>> There is no user list and this is a basic question. The default
>> methods in interfaces are being used to implement 'MixIn' classes(AspectJ
>> does it by weaving classes ) and some references even mention multiple
>> inheritance. What is the general design pattern in application code that
>> this is intended for ? Is this related to functional programming styles
>> in some way ?
>>
>> Should I just search older threads for this type of discussion ?
>>
>> Thanks,
>> Mohan
>>
>>
>> This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited.
>>
>> Visit us at http://www.polarisFT.com
>>
>
>
>
>
More information about the lambda-dev
mailing list