Proactive Empirical Assessment of New Language Feature Adoption via Automated Refactoring: The Case of Java 8 Default Methods
1 like540 views
This document describes an empirical study assessing the adoption of default methods in Java 8. The study involved issuing pull requests to 19 open source Java projects on GitHub that contained refactorings migrating interface method implementations to default methods. The study found that developers adopted default methods when the implementation was localized to the interface or parameters, provided optional behavior, or allowed static methods to be called as instance methods. Developers rejected default methods when compatibility with older JDK versions was required to support legacy clients. The study presents a novel proactive technique for assessing new language features by introducing them to developers via automated refactoring rather than relying on postmortem analysis.
Proactive Empirical Assessment of New Language Feature Adoption via Automated Refactoring: The Case of Java 8 Default Methods
- 1. Proactive Empirical Assessment of New Language Feature Adoption via Automated Refactoring: The Case of Java 8 Default Methods Raffi Khatchadourian1,2 Hidehiko Masuhara3 International Conference on the Art, Science, and Engineering of Programming April 2018, Nice, France 1 Computer Science, Hunter College, City University of New York, USA 2 Computer Science, The Graduate Center, City University of New York, USA 3 Mathematical and Computing Science, Tokyo Institute of Technology, Japan
- 2. Outline Introduction Background Contributions Methodology Research Questions and Results Conclusion 1
- 3. Introduction
- 4. New Programming Languages Features • Programming languages change for a variety of reasons. 2
- 5. New Programming Languages Features • Programming languages change for a variety of reasons. • To benefit from new language features, developers must be willing to adopt them. 2
- 6. Empirical Study on Usage of Default Methods • An empirical study assessing the adoption of a new language feature: default methods. 3
- 7. Empirical Study on Usage of Default Methods • An empirical study assessing the adoption of a new language feature: default methods. • Default methods are part of Java 8’s enhanced interfaces. 3
- 8. Background
- 9. Java 8 Default Methods • Allow both method declarations and definitions. interface Collection<E> { default void add(E elem) { // optional. throw new UnsupportedOperationException();}} 4
- 10. Java 8 Default Methods • Allow both method declarations and definitions. • Implementers inherit the (default) implementation if none provided. interface Collection<E> { default void add(E elem) { // optional. throw new UnsupportedOperationException();}} class ImmutableList<E> implements Collection<E> {} 4
- 11. Java 8 Default Methods • Allow both method declarations and definitions. • Implementers inherit the (default) implementation if none provided. • Original motivation to facilitate interface evolution. interface Collection<E> { default void add(E elem) { // optional. throw new UnsupportedOperationException();}} class ImmutableList<E> implements Collection<E> {} 4
- 12. Java 8 Default Methods • Allow both method declarations and definitions. • Implementers inherit the (default) implementation if none provided. • Original motivation to facilitate interface evolution. • Can also be used as a replacement of the skeletal implementation pattern (Goetz 2011). interface Collection<E> { default void add(E elem) { // optional. throw new UnsupportedOperationException();}} class ImmutableList<E> implements Collection<E> {} abstract class AbstractImmutableList<E> implements Collection<E> { @Override public void add(E elem) { throw new UnsupportedOperationException();}} 4
- 13. Java 8 Default Methods • Allow both method declarations and definitions. • Implementers inherit the (default) implementation if none provided. • Original motivation to facilitate interface evolution. • Can also be used as a replacement of the skeletal implementation pattern (Goetz 2011). • Uses abstract class that interface implementers extend. interface Collection<E> { default void add(E elem) { // optional. throw new UnsupportedOperationException();}} class ImmutableList<E> implements Collection<E> {} abstract class AbstractImmutableList<E> implements Collection<E> { @Override public void add(E elem) { throw new UnsupportedOperationException();}} 4
- 14. Java 8 Default Methods • Allow both method declarations and definitions. • Implementers inherit the (default) implementation if none provided. • Original motivation to facilitate interface evolution. • Can also be used as a replacement of the skeletal implementation pattern (Goetz 2011). • Uses abstract class that interface implementers extend. • Makes interfaces easier to implement (Bloch 2008, Item 18). interface Collection<E> { default void add(E elem) { // optional. throw new UnsupportedOperationException();}} class ImmutableList<E> implements Collection<E> {} abstract class AbstractImmutableList<E> implements Collection<E> { @Override public void add(E elem) { throw new UnsupportedOperationException();}} 4
- 15. Contributions
- 16. Our Study • Performed empirical study on 19 real-world, open source Java projects hosted on GitHub. 5
- 17. Our Study • Performed empirical study on 19 real-world, open source Java projects hosted on GitHub. • Pull requests (patches) issued that contained particular interface method implementations migrated to interfaces as default methods in a semantics-preserving fashion. 5
- 18. Our Study • Performed empirical study on 19 real-world, open source Java projects hosted on GitHub. • Pull requests (patches) issued that contained particular interface method implementations migrated to interfaces as default methods in a semantics-preserving fashion. • Found that there are non-obvious trade-offs to using default methods. 5
- 19. Our Study • Performed empirical study on 19 real-world, open source Java projects hosted on GitHub. • Pull requests (patches) issued that contained particular interface method implementations migrated to interfaces as default methods in a semantics-preserving fashion. • Found that there are non-obvious trade-offs to using default methods. • Detail reactions of developers in adopting default methods in their projects. 5
- 20. Our Study • Performed empirical study on 19 real-world, open source Java projects hosted on GitHub. • Pull requests (patches) issued that contained particular interface method implementations migrated to interfaces as default methods in a semantics-preserving fashion. • Found that there are non-obvious trade-offs to using default methods. • Detail reactions of developers in adopting default methods in their projects. • Extract best practices of their uses. 5
- 21. Our Study • Performed empirical study on 19 real-world, open source Java projects hosted on GitHub. • Pull requests (patches) issued that contained particular interface method implementations migrated to interfaces as default methods in a semantics-preserving fashion. • Found that there are non-obvious trade-offs to using default methods. • Detail reactions of developers in adopting default methods in their projects. • Extract best practices of their uses. • Situations where these new constructs work well and where trade-offs must be made. 5
- 22. Traditional Approaches to Assessing New Languages Features • A popular approach for assessing language features involves a postmortem analysis. 6
- 23. Traditional Approaches to Assessing New Languages Features • A popular approach for assessing language features involves a postmortem analysis. • Past data of source repositories are analyzed 6
- 24. Traditional Approaches to Assessing New Languages Features • A popular approach for assessing language features involves a postmortem analysis. • Past data of source repositories are analyzed • Surveys of previous coding activities are taken. 6
- 25. Traditional Approaches to Assessing New Languages Features • A popular approach for assessing language features involves a postmortem analysis. • Past data of source repositories are analyzed • Surveys of previous coding activities are taken. • Developers must discover new language features and integrate them themselves before any analysis of the construct can be done. 6
- 26. Traditional Approaches to Assessing New Languages Features • A popular approach for assessing language features involves a postmortem analysis. • Past data of source repositories are analyzed • Surveys of previous coding activities are taken. • Developers must discover new language features and integrate them themselves before any analysis of the construct can be done. • Best practices and patterns that can normally be extracted from these studies are delayed. 6
- 27. Traditional Approaches to Assessing New Languages Features • A popular approach for assessing language features involves a postmortem analysis. • Past data of source repositories are analyzed • Surveys of previous coding activities are taken. • Developers must discover new language features and integrate them themselves before any analysis of the construct can be done. • Best practices and patterns that can normally be extracted from these studies are delayed. • Developers may be unable to manually identify all opportunities where the new language construct can be utilized. 6
- 28. Traditional Approaches to Assessing New Languages Features • A popular approach for assessing language features involves a postmortem analysis. • Past data of source repositories are analyzed • Surveys of previous coding activities are taken. • Developers must discover new language features and integrate them themselves before any analysis of the construct can be done. • Best practices and patterns that can normally be extracted from these studies are delayed. • Developers may be unable to manually identify all opportunities where the new language construct can be utilized. • Observing software histories may discover cases where new language features are adopted but may not easily identify those where they were rejected as these may not have been adequately documented. 6
- 29. Our Proactive Approach • A novel technique for assessing new language constructs proactively. 7
- 30. Our Proactive Approach • A novel technique for assessing new language constructs proactively. • The pull request changes in our study consist of transformations performed via an automated refactoring tool. 7
- 31. Our Proactive Approach • A novel technique for assessing new language constructs proactively. • The pull request changes in our study consist of transformations performed via an automated refactoring tool. • Developers are immediately introduced to the new construct via a semantically equivalent transformation that they can either accept or reject. 7
- 32. Our Proactive Approach • A novel technique for assessing new language constructs proactively. • The pull request changes in our study consist of transformations performed via an automated refactoring tool. • Developers are immediately introduced to the new construct via a semantically equivalent transformation that they can either accept or reject. • Their decisions can be studied early to assess the feature’s effectiveness, extracting best practices. 7
- 33. Methodology
- 34. Study Methodology • The use of conservative, theoretically sound, and minimally invasive refactoring automation is key in minimizing human bias. 8
- 35. Study Methodology • The use of conservative, theoretically sound, and minimally invasive refactoring automation is key in minimizing human bias. • We use the Migrate Skeletal Implementation to Interface refactoring tool (Khatchadourian and Masuhara 2017), based on type constraints (Palsberg and Schwartzbach 1994; Tip et al. 2011). 8
- 36. Study Methodology • The use of conservative, theoretically sound, and minimally invasive refactoring automation is key in minimizing human bias. • We use the Migrate Skeletal Implementation to Interface refactoring tool (Khatchadourian and Masuhara 2017), based on type constraints (Palsberg and Schwartzbach 1994; Tip et al. 2011). • Discover opportunities and semantics-preserving transformations for migrating methods possibly participating in the skeletal implementation pattern to interfaces as default methods. 8
- 37. Study Methodology • The use of conservative, theoretically sound, and minimally invasive refactoring automation is key in minimizing human bias. • We use the Migrate Skeletal Implementation to Interface refactoring tool (Khatchadourian and Masuhara 2017), based on type constraints (Palsberg and Schwartzbach 1994; Tip et al. 2011). • Discover opportunities and semantics-preserving transformations for migrating methods possibly participating in the skeletal implementation pattern to interfaces as default methods. • Assess the use of default methods in existing code. 8
- 38. Study Methodology • The use of conservative, theoretically sound, and minimally invasive refactoring automation is key in minimizing human bias. • We use the Migrate Skeletal Implementation to Interface refactoring tool (Khatchadourian and Masuhara 2017), based on type constraints (Palsberg and Schwartzbach 1994; Tip et al. 2011). • Discover opportunities and semantics-preserving transformations for migrating methods possibly participating in the skeletal implementation pattern to interfaces as default methods. • Assess the use of default methods in existing code. • Substituting the skeletal implementation pattern is the only sensible use of default methods when not introducing new functionality. 8
- 39. Study Methodology • The use of conservative, theoretically sound, and minimally invasive refactoring automation is key in minimizing human bias. • We use the Migrate Skeletal Implementation to Interface refactoring tool (Khatchadourian and Masuhara 2017), based on type constraints (Palsberg and Schwartzbach 1994; Tip et al. 2011). • Discover opportunities and semantics-preserving transformations for migrating methods possibly participating in the skeletal implementation pattern to interfaces as default methods. • Assess the use of default methods in existing code. • Substituting the skeletal implementation pattern is the only sensible use of default methods when not introducing new functionality. • An acceptance of the refactoring is equivalent to acceptance of using default methods as a programming construct for existing code and vice-versa. 8
- 40. subject pull ID KLOC * watches † stars † forks † contribs † +LOC -LOC δ files concrete?merged aalmiray/jsilhouette 1 2 2 4 1 2 147 294 4 false aol/cyclops-react 258 99 68 554 54 21 8 15 2 false eclipse/eclipse-collections 128 1,266 40 258 63 18 172 307 21 false nhl/bootique 79 5 103 744 183 5 22 31 4 true rejected iluwatar/java-design-patterns 472 20 1,783 17,234 5,808 71 24 38 6 false jOOQ/jOOQ 5469 136 127 1,614 411 40 93 187 22 false google/guava 2519 244 1,568 14,721 3,502 98 241 427 16 false google/binnavi 99 309 215 2,048 373 16 244 469 16 false eclipse/jetty.project 773 329 196 1,225 811 61 140 263 29 false spring-projects/spring-framework 1113 506 2,299 12,463 9,575 200 770 1,674 135 false elastic/elasticsearch 19168 1,266 1,928 21,063 7,275 784 297 544 51 false jenkinsci/blueocean-plugin 296 7 114 1,688 173 28 8 19 5 true junit-team/junit5 5365 25 146 865 215 41 4 18 1 true ReactiveX/RxJava 4143 154 1,677 21,792 3,819 142 29 131 23 true pending perfectsense/dari 218 66 111 48 31 28 39 58 7 false eclipse/jgit 34 172 57 429 247 121 35 127 10 false rinfield/java8-commons 81 2 1 0 2 1 26 48 3 true criscris/koral 1 7 1 1 1 1 169 197 6 true advantageous/qbit 767 52 82 534 115 12 80 202 29 true Totals: 4,665 10,518 97,285 32,659 1,690 2,548 5,049 390 * At time of analysis. † As of February 27, 2017. Table 1: Pull requests. More info at http://cuny.is/interefact. 9
- 41. Research Questions and Results
- 42. Default Method Adoption Question In which situations do developers adopt default methods in their projects? What are the reasons? 10
- 43. Default Method Adoption Question In which situations do developers adopt default methods in their projects? What are the reasons? Answers Interface Locality Default implementation was mostly in terms of both methods and constant fields declared either within the same interface or one up its hierarchy. 10
- 44. Default Method Adoption Question In which situations do developers adopt default methods in their projects? What are the reasons? Answers Interface Locality Default implementation was mostly in terms of both methods and constant fields declared either within the same interface or one up its hierarchy. Parameter Locality No new dependencies introduced by the default method by referencing only parameters. 10
- 45. Default Method Adoption Question In which situations do developers adopt default methods in their projects? What are the reasons? Answers Interface Locality Default implementation was mostly in terms of both methods and constant fields declared either within the same interface or one up its hierarchy. Parameter Locality No new dependencies introduced by the default method by referencing only parameters. Optional Methods Default implementation threw UnsupportedOperationExceptions (self-documenting). 10
- 46. Default Method Adoption Question In which situations do developers adopt default methods in their projects? What are the reasons? Answers Interface Locality Default implementation was mostly in terms of both methods and constant fields declared either within the same interface or one up its hierarchy. Parameter Locality No new dependencies introduced by the default method by referencing only parameters. Optional Methods Default implementation threw UnsupportedOperationExceptions (self-documenting). Static Methods as Instance Methods Allowed static methods to be called as instance methods via forwarding. 10
- 47. Default Method Rejection Question Are there situations where developers do not favor default methods? 11
- 48. Default Method Rejection Question Are there situations where developers do not favor default methods? Answers JDK Versions • Needed to maintain compatibility with legacy clients (e.g., Android). 11
- 49. Default Method Rejection Question Are there situations where developers do not favor default methods? Answers JDK Versions • Needed to maintain compatibility with legacy clients (e.g., Android). • Developers must not only consider the language construct itself but also substantial reliance on platform backwards compatibility. 11
- 50. Default Method Rejection Question Are there situations where developers do not favor default methods? Answers JDK Versions • Needed to maintain compatibility with legacy clients (e.g., Android). • Developers must not only consider the language construct itself but also substantial reliance on platform backwards compatibility. 11
- 51. Default Method Rejection Question Are there situations where developers do not favor default methods? Answers JDK Versions • Needed to maintain compatibility with legacy clients (e.g., Android). • Developers must not only consider the language construct itself but also substantial reliance on platform backwards compatibility. Architecture • Developers did not always want to introduce new external dependencies into interfaces as some default methods required. 11
- 52. Default Method Rejection Question Are there situations where developers do not favor default methods? Answers JDK Versions • Needed to maintain compatibility with legacy clients (e.g., Android). • Developers must not only consider the language construct itself but also substantial reliance on platform backwards compatibility. Architecture • Developers did not always want to introduce new external dependencies into interfaces as some default methods required. • Projects separated their APIs (interfaces) and an implementation of that API into separate modules. 11
- 53. Default Method Rejection Question Are there situations where developers do not favor default methods? 12
- 54. Default Method Rejection Question Are there situations where developers do not favor default methods? Answers Clients • Anxious about “inlining” skeletal implementations directly into interfaces, particular frameworks. 12
- 55. Default Method Rejection Question Are there situations where developers do not favor default methods? Answers Clients • Anxious about “inlining” skeletal implementations directly into interfaces, particular frameworks. • Desired forcing clients to implement interfaces directly despite providing skeletal implementations in a separate classes. 12
- 56. Default Method Rejection Question Are there situations where developers do not favor default methods? Answers Clients • Anxious about “inlining” skeletal implementations directly into interfaces, particular frameworks. • Desired forcing clients to implement interfaces directly despite providing skeletal implementations in a separate classes. 12
- 57. Default Method Rejection Question Are there situations where developers do not favor default methods? Answers Clients • Anxious about “inlining” skeletal implementations directly into interfaces, particular frameworks. • Desired forcing clients to implement interfaces directly despite providing skeletal implementations in a separate classes. Generality • Skeletal implementations too narrow to be the “de facto.” 12
- 58. Default Method Rejection Question Are there situations where developers do not favor default methods? Answers Clients • Anxious about “inlining” skeletal implementations directly into interfaces, particular frameworks. • Desired forcing clients to implement interfaces directly despite providing skeletal implementations in a separate classes. Generality • Skeletal implementations too narrow to be the “de facto.” • Pattern allows for multiple implementations per method, enhanced interfaces do not. 12
- 59. Default Method Rejection Question Are there situations where developers do not favor default methods? Answers Clients • Anxious about “inlining” skeletal implementations directly into interfaces, particular frameworks. • Desired forcing clients to implement interfaces directly despite providing skeletal implementations in a separate classes. Generality • Skeletal implementations too narrow to be the “de facto.” • Pattern allows for multiple implementations per method, enhanced interfaces do not. • Skeletal implementations from tests were too specific. 12
- 60. Default Method Trade-offs Question What are the trade-offs of using default methods over the skeletal implementation pattern? 13
- 61. Default Method Trade-offs Question What are the trade-offs of using default methods over the skeletal implementation pattern? Answers Control • Contrary to pattern, default methods are available to all interface implementers. 13
- 62. Default Method Trade-offs Question What are the trade-offs of using default methods over the skeletal implementation pattern? Answers Control • Contrary to pattern, default methods are available to all interface implementers. • Explicitly presents implementers with a skeletal implementation. 13
- 63. Default Method Trade-offs Question What are the trade-offs of using default methods over the skeletal implementation pattern? Answers Control • Contrary to pattern, default methods are available to all interface implementers. • Explicitly presents implementers with a skeletal implementation. • Implementers may or may not choose to override with their own. 13
- 64. Default Method Trade-offs Question What are the trade-offs of using default methods over the skeletal implementation pattern? Answers Control • Contrary to pattern, default methods are available to all interface implementers. • Explicitly presents implementers with a skeletal implementation. • Implementers may or may not choose to override with their own. • May have a negative effect if not applicable to implementer but choose not to override. 13
- 65. External Factors Question Which external factors, if any, influence developer’s decisions in adopting default methods? 14
- 66. External Factors Question Which external factors, if any, influence developer’s decisions in adopting default methods? Answers Java 8 Projects that previously used (other) Java 8 features were more likely to accept. 14
- 67. External Factors Question Which external factors, if any, influence developer’s decisions in adopting default methods? Answers Java 8 Projects that previously used (other) Java 8 features were more likely to accept. Size Smaller change sets were more likely to be accepted. 14
- 68. External Factors Question Which external factors, if any, influence developer’s decisions in adopting default methods? Answers Java 8 Projects that previously used (other) Java 8 features were more likely to accept. Size Smaller change sets were more likely to be accepted. Span Change sets spanning multiple files across module boundaries were less likely. 14
- 69. External Factors Question Which external factors, if any, influence developer’s decisions in adopting default methods? Answers Java 8 Projects that previously used (other) Java 8 features were more likely to accept. Size Smaller change sets were more likely to be accepted. Span Change sets spanning multiple files across module boundaries were less likely. Abstractness Implementations originating from abstract classes more likely (more general). 14
- 70. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? 15
- 71. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? Answers • Default methods should be simple. 15
- 72. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? Answers • Default methods should be simple. • Reduces likelihood of complex dependencies in interfaces. 15
- 73. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? Answers • Default methods should be simple. • Reduces likelihood of complex dependencies in interfaces. • Promote self-containment. 15
- 74. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? Answers • Default methods should be simple. • Reduces likelihood of complex dependencies in interfaces. • Promote self-containment. • Enhancement to the interface documentation. 15
- 75. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? Answers • Default methods should be simple. • Reduces likelihood of complex dependencies in interfaces. • Promote self-containment. • Enhancement to the interface documentation. • What optional methods do when called if they are not implemented? 15
- 76. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? Answers • Default methods should be simple. • Reduces likelihood of complex dependencies in interfaces. • Promote self-containment. • Enhancement to the interface documentation. • What optional methods do when called if they are not implemented? • Take care in using default methods for new methods that interface implementers should override. 15
- 77. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? Answers • Default methods should be simple. • Reduces likelihood of complex dependencies in interfaces. • Promote self-containment. • Enhancement to the interface documentation. • What optional methods do when called if they are not implemented? • Take care in using default methods for new methods that interface implementers should override. • May inadvertently mask interface evolution if the developers’ intention is to break existing implementers. 15
- 78. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? 16
- 79. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? Answers • Write default methods in terms of (other) methods and constants of the same or closely related interfaces and/or their parameters. 16
- 80. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? Answers • Write default methods in terms of (other) methods and constants of the same or closely related interfaces and/or their parameters. • Simplifies default method implementations. 16
- 81. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? Answers • Write default methods in terms of (other) methods and constants of the same or closely related interfaces and/or their parameters. • Simplifies default method implementations. • More self-contained. 16
- 82. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? Answers • Write default methods in terms of (other) methods and constants of the same or closely related interfaces and/or their parameters. • Simplifies default method implementations. • More self-contained. • Reduces external dependencies. 16
- 83. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? Answers • Write default methods in terms of (other) methods and constants of the same or closely related interfaces and/or their parameters. • Simplifies default method implementations. • More self-contained. • Reduces external dependencies. • Consider architectural implications. 16
- 84. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? Answers • Write default methods in terms of (other) methods and constants of the same or closely related interfaces and/or their parameters. • Simplifies default method implementations. • More self-contained. • Reduces external dependencies. • Consider architectural implications. • Rethink separating interface declarations and interface implementations into separate modules. 16
- 85. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? Answers • Write default methods in terms of (other) methods and constants of the same or closely related interfaces and/or their parameters. • Simplifies default method implementations. • More self-contained. • Reduces external dependencies. • Consider architectural implications. • Rethink separating interface declarations and interface implementations into separate modules. • Default methods may contain references to implementation modules. 16
- 86. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? Answers • Write default methods in terms of (other) methods and constants of the same or closely related interfaces and/or their parameters. • Simplifies default method implementations. • More self-contained. • Reduces external dependencies. • Consider architectural implications. • Rethink separating interface declarations and interface implementations into separate modules. • Default methods may contain references to implementation modules. • Typically not available to interface modules. 16
- 87. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? 17
- 88. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? Answers • Call forwarding for deprecated interface methods. 17
- 89. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? Answers • Call forwarding for deprecated interface methods. • Forward to replacement API, if applicable. 17
- 90. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? Answers • Call forwarding for deprecated interface methods. • Forward to replacement API, if applicable. • Self-documenting. 17
- 91. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? Answers • Call forwarding for deprecated interface methods. • Forward to replacement API, if applicable. • Self-documenting. • Eliminates any confusion over deprecation between interface and skeletal implementation class. 17
- 92. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? Answers • Call forwarding for deprecated interface methods. • Forward to replacement API, if applicable. • Self-documenting. • Eliminates any confusion over deprecation between interface and skeletal implementation class. • Choose general default implementations. 17
- 93. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? Answers • Call forwarding for deprecated interface methods. • Forward to replacement API, if applicable. • Self-documenting. • Eliminates any confusion over deprecation between interface and skeletal implementation class. • Choose general default implementations. • General enough for all potential implementers. 17
- 94. Best Practices for Default Methods Question Are there best practices and/or patterns that can be extracted from these situations? Answers • Call forwarding for deprecated interface methods. • Forward to replacement API, if applicable. • Self-documenting. • Eliminates any confusion over deprecation between interface and skeletal implementation class. • Choose general default implementations. • General enough for all potential implementers. • If too narrow, use skeletal implementation pattern instead. 17
- 95. Conclusion
- 96. Summary • Novel proactive approach, using automated refactoring, to empirically assess new programming language features early. 18
- 97. Summary • Novel proactive approach, using automated refactoring, to empirically assess new programming language features early. • New construct introduced to developers as refactorings that they decide whether to incorporate regardless of experience. 18
- 98. Summary • Novel proactive approach, using automated refactoring, to empirically assess new programming language features early. • New construct introduced to developers as refactorings that they decide whether to incorporate regardless of experience. • Developers provide insight into their decisions. 18
- 99. Summary • Novel proactive approach, using automated refactoring, to empirically assess new programming language features early. • New construct introduced to developers as refactorings that they decide whether to incorporate regardless of experience. • Developers provide insight into their decisions. • Facilitates reasons why new features are not adopted. 18
- 100. Summary • Novel proactive approach, using automated refactoring, to empirically assess new programming language features early. • New construct introduced to developers as refactorings that they decide whether to incorporate regardless of experience. • Developers provide insight into their decisions. • Facilitates reasons why new features are not adopted. • May not be explicitly documented. 18
- 101. Summary • Novel proactive approach, using automated refactoring, to empirically assess new programming language features early. • New construct introduced to developers as refactorings that they decide whether to incorporate regardless of experience. • Developers provide insight into their decisions. • Facilitates reasons why new features are not adopted. • May not be explicitly documented. • Can possibly allude traditional postmortem approaches. 18
- 102. Summary • Novel proactive approach, using automated refactoring, to empirically assess new programming language features early. • New construct introduced to developers as refactorings that they decide whether to incorporate regardless of experience. • Developers provide insight into their decisions. • Facilitates reasons why new features are not adopted. • May not be explicitly documented. • Can possibly allude traditional postmortem approaches. • Experienced project committers provide valuable feedback. 18
- 103. Summary • Novel proactive approach, using automated refactoring, to empirically assess new programming language features early. • New construct introduced to developers as refactorings that they decide whether to incorporate regardless of experience. • Developers provide insight into their decisions. • Facilitates reasons why new features are not adopted. • May not be explicitly documented. • Can possibly allude traditional postmortem approaches. • Experienced project committers provide valuable feedback. • Approach was applied to 19 open source projects to assess Java 8 default methods. 18
- 104. Summary • Novel proactive approach, using automated refactoring, to empirically assess new programming language features early. • New construct introduced to developers as refactorings that they decide whether to incorporate regardless of experience. • Developers provide insight into their decisions. • Facilitates reasons why new features are not adopted. • May not be explicitly documented. • Can possibly allude traditional postmortem approaches. • Experienced project committers provide valuable feedback. • Approach was applied to 19 open source projects to assess Java 8 default methods. • Scenarios where and reasons why default method migrations were either accepted or rejected by developers were put forth. 18
- 105. Summary • Novel proactive approach, using automated refactoring, to empirically assess new programming language features early. • New construct introduced to developers as refactorings that they decide whether to incorporate regardless of experience. • Developers provide insight into their decisions. • Facilitates reasons why new features are not adopted. • May not be explicitly documented. • Can possibly allude traditional postmortem approaches. • Experienced project committers provide valuable feedback. • Approach was applied to 19 open source projects to assess Java 8 default methods. • Scenarios where and reasons why default method migrations were either accepted or rejected by developers were put forth. • Best practices extracted. 18
- 106. Summary • Novel proactive approach, using automated refactoring, to empirically assess new programming language features early. • New construct introduced to developers as refactorings that they decide whether to incorporate regardless of experience. • Developers provide insight into their decisions. • Facilitates reasons why new features are not adopted. • May not be explicitly documented. • Can possibly allude traditional postmortem approaches. • Experienced project committers provide valuable feedback. • Approach was applied to 19 open source projects to assess Java 8 default methods. • Scenarios where and reasons why default method migrations were either accepted or rejected by developers were put forth. • Best practices extracted. • Can benefit developers and language designers, especially those considering similar constructs for other languages. 18
- 107. Summary • Novel proactive approach, using automated refactoring, to empirically assess new programming language features early. • New construct introduced to developers as refactorings that they decide whether to incorporate regardless of experience. • Developers provide insight into their decisions. • Facilitates reasons why new features are not adopted. • May not be explicitly documented. • Can possibly allude traditional postmortem approaches. • Experienced project committers provide valuable feedback. • Approach was applied to 19 open source projects to assess Java 8 default methods. • Scenarios where and reasons why default method migrations were either accepted or rejected by developers were put forth. • Best practices extracted. • Can benefit developers and language designers, especially those considering similar constructs for other languages. • More info at http://cuny.is/interefact. 18
- 108. For Further Reading Bloch, Joshua (2008). Effective Java. Prentice Hall. Goetz, Brian (June 2011). Interface evolution via virtual extensions methods. Tech. rep. Oracle Corporation. url: http://cr.openjdk.java.net/~briangoetz/lambda/ Defender%20Methods%20v4.pdf (visited on 08/03/2017). Khatchadourian, Raffi and Hidehiko Masuhara (2017). “Automated Refactoring of Legacy Java Software to Default Methods”. In: International Conference on Software Engineering. ICSE ’17. ACM/IEEE. Buenos Aires, Argentina: IEEE Press, pp. 82–93. isbn: 978-1-5386-3868-2. doi: 10.1109/ICSE.2017.16. Palsberg, Jens and Michael I. Schwartzbach (1994). Object-oriented type systems. John Wiley and Sons Ltd. isbn: 0-471-94128-X. Tip, Frank et al. (May 2011). “Refactoring Using Type Constraints”. In: ACM Transactions on Programming Languages and Systems 33.3, pp. 91–947. issn: 0164-0925. doi: 10.1145/1961204.1961205. 19