{"id":1351,"date":"2012-07-15T11:18:44","date_gmt":"2012-07-15T09:18:44","guid":{"rendered":"http:\/\/doanduyhai.wordpress.com\/?p=1351"},"modified":"2012-07-15T11:18:44","modified_gmt":"2012-07-15T09:18:44","slug":"java-8-lambda-in-details-part-iv-multiple-inheritance-resolution-for-defender-methods","status":"publish","type":"post","link":"https:\/\/www.doanduyhai.com\/blog\/?p=1351","title":{"rendered":"Java 8 Lambda in details part IV : Multiple inheritance resolution for defender methods"},"content":{"rendered":"

In this post we’ll look at conflict resolution rules for multiple inheritance introduced along with defender methods in JDK 8.<\/p>\n

<\/p>\n

DISCLAIMER: all the details exposed in this post were observed related to the JDK 8 demo version as of July 10th 2012<\/font>. Since the JDK is still in beta, some assertions may not hold in future<\/strong>\n<\/p><\/blockquote>\n

Please note that all the example code in this post can be found on my GitHub repository https:\/\/github.com\/doanduyhai\/Java8_Lambda_In_Details<\/a><\/p><\/blockquote>\n

 <\/p>\n

I Method lookup rules<\/h1>\n

With JDK 8 now we can provide a default implementation for declared abstract methods in an interface, a defender method<\/strong>.<\/p>\n

Since it is possible for a class to implement multiple interfaces it will lead de-facto to the possibility of multiple inheritance if more than 2 interfaces in the hierarchy are providing default implementation for the same abstract method.<\/p>\n

Please note that unlike a real multiple inheritance, defender method multiple inheritance is only behavioral, no state (field) is inherited.<\/strong> <\/p>\n

Below are the rules to lookup method implementation:<\/p>\n

1) First search for this method in the class (not interface) hierarchy <\/strong>from the current class up to the root Object class. <\/p>\n

1a) If a matching non abstract<\/strong> method is found, use it (even if matching defender methods are found<\/em>). <\/p>\n

\"Lambda_Defender_Inheritance_NonAbstractMethodInHierarchy\"<\/a><\/p>\n

1b) If a matching abstract<\/strong> class is found then force the current class to implement it (even if a matching defender method can be found in the hierarchy<\/em>) otherwise compilation error. <\/p>\n

\"Lambda_Defender_Inheritance_AbstractMethodInHierarchy\"<\/a><\/p>\n

The general rule of thumb is: method definition from class hierarchy, abstract or not, has priority over defender methods.<\/strong><\/p>\n

2) If no matching method is found in the class hierarchy, examine the interface hierarchy. Prune all the branches and only take “leaf” interfaces in the tree.<\/p>\n

\"\"<\/a><\/p>\n

2a) If a matching defender method is found in only one of those “leaf” interfaces, use it<\/p>\n

2b) If more than one “leaf” interfaces provide defender methods, raise a compilation error to force the user to explicitely define the defender method to be used.<\/p>\n

The above rules are simplifications from the more formal rules defined in http:\/\/cr.openjdk.java.net\/~briangoetz\/lambda\/Defender%20Methods%20v4.pdf<\/a><\/p>\n

 <\/p>\n

II Resolution examples<\/h1>\n

In this chapter, we present some concrete example of method resolution<\/p>\n

A From SuperInterface<\/h3>\n

In this scenario, the method implementation comes from a defender method defined in a SuperInterface<\/p>\n

\"\"<\/a><\/p>\n

The above scenario can be illustrated by a code example on GitHub at https:\/\/github.com\/doanduyhai\/Java8_Lambda_In_Details<\/a>. Just execute the SameSuperDefenderMethod.bat<\/strong>(SameSuperDefenderMethod.sh<\/strong>) script<\/p><\/blockquote>\n

 <\/p>\n

B From most specific interface<\/h3>\n

In this scenario, the method implementation comes from the defender method of the most specific inherited interface.<\/p>\n

\"Lambda_Defender_Inheritance_FromMostSpecificInterface\"<\/a><\/p>\n

The above scenario can be illustrated by a code example on GitHub at https:\/\/github.com\/doanduyhai\/Java8_Lambda_In_Details<\/a>. Just execute the MostSpecificDefender.bat<\/strong>(MostSpecificDefender.sh<\/strong>) script<\/p><\/blockquote>\n

 <\/p>\n

C Conflicting defenders<\/h3>\n

When there are more than one matching defender method from “leaf” interfaces, we have a conflict and compilation issue<\/p>\n

\"Lambda_Defender_Inheritance_ConflictingDefenders\"<\/a><\/p>\n

The above scenario can be illustrated by a code example on GitHub at https:\/\/github.com\/doanduyhai\/Java8_Lambda_In_Details<\/a>. Just execute the ConflictingDefenders.bat<\/strong>(ConflictingDefenders.sh<\/strong>) script<\/p><\/blockquote>\n

 <\/p>\n

D Priority to class hierarchy<\/h3>\n

It a matching method is found in the class hierarchy, be it abstract, then it prevails over all defender methods.<\/p>\n

\"Lambda_Defender_Inheritance_PriorityToClassHierarchy\"<\/a><\/p>\n

The above scenario can be illustrated by a code example on GitHub at https:\/\/github.com\/doanduyhai\/Java8_Lambda_In_Details<\/a>. Just execute the PriorityToHierarchy.bat<\/strong>(PriorityToHierarchy.sh<\/strong>) script<\/p><\/blockquote>\n

 <\/p>\n

E Removed defender<\/h3>\n

Sometimes, an interface can “remove<\/strong>” the default implementation provided by one of its superinterfaces. Removal is done simply by overriding the defander method without providing any default implementation<\/p>\n

\npublic interface SuperDefender\n{\n\tString changeInput(String input) default\n\t{\n\t\treturn input.trim();\n\t}\n}\n\npublic interface RemovedDefenderInterface extends SuperDefender\n{\n\tString changeInput(String input); \/\/ Default removed here\n}\t\n<\/pre>\n
 In such case the class implementing the interface needs to override the method.<\/p>\n
\"Lambda_Defender_Inheritance_RemovedDefenderInterface\"<\/a><\/p>\n
 The above scenario can be illustrated by a code example on GitHub at https:\/\/github.com\/doanduyhai\/Java8_Lambda_In_Details<\/a>. Just execute the RemovedDefender.bat<\/strong>(RemovedDefender.sh<\/strong>) script<\/p><\/blockquote>\n
 <\/p>\n
F Resolving defender conflics at interface level<\/h3>\n
 Whenever a conflict occurs for a defender method inheritance at interface level, we can resolve it by specifying the version of the defender to be used.<\/p>\n
\"Lambda_Defender_Inheritance_ResolvedDefenderConflictAtInterface\"<\/a><\/p>\n
\npublic interface ResolvedDefenderConflictInterface extends Defender1, Defender2\n{\n\tString changeInput(String input) default\n\t{\n\t\treturn Defender2.super.changeInput(input);\n\t}\n}\n<\/pre>\n
 Please notice the introduction of the new syntax for the super<\/strong> keyword. With JDK 8 you can prefix it with the concrete interface to be used as “parent”.<\/p>\n
 The above scenario can be illustrated by a code example on GitHub at https:\/\/github.com\/doanduyhai\/Java8_Lambda_In_Details<\/a>. Just execute the ResolvedDefenderConflictsAtInterface.bat<\/strong>(ResolvedDefenderConflictsAtInterface.sh<\/strong>) script<\/p><\/blockquote>\n
 <\/p>\n
G Resolving defender conflics at class level<\/h3>\n
 Similarly the resolution for defender method conflict can be done at implementing class level.<\/p>\n
\npublic class ResolvedDefenderConflictsAtClass implements Defender1, Defender2\n{\n\tpublic String changeInput(String input)\n\t{\n\t\treturn Defender1.super.changeInput(input);\n\t}\n\t...\n\t...\n}\n<\/pre>\n
The syntax for indicating which super interface to be used is the same (line 5<\/strong>).<\/p>\n
 The above scenario can be illustrated by a code example on GitHub at https:\/\/github.com\/doanduyhai\/Java8_Lambda_In_Details<\/a>. Just execute the ResolvedDefenderConflictsAtClass.bat<\/strong>(ResolvedDefenderConflictsAtClass.sh<\/strong>) script<\/p><\/blockquote>\n
To be continued …
\n 
\n <\/p>\n","protected":false},"excerpt":{"rendered":"
In this post we’ll look at conflict resolution rules for multiple inheritance introduced along with defender methods in JDK 8.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[6,8],"tags":[],"_links":{"self":[{"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1351"}],"collection":[{"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1351"}],"version-history":[{"count":0,"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1351\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1351"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1351"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1351"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}