defaultification refactoring: a tool for automatically converting java methods to default
Post on 28-Jan-2018
141 Views
Preview:
TRANSCRIPT
Defaultification Refactoring: A Tool forAutomatically Converting Java Methods toDefault
Raffi Khatchadourian1,2 Hidehiko Masuhara3
International Conference on Automated Software Engineering, 20171Computer Science, Hunter College, City University of New York, USA
2Computer Science, The Graduate Center, City University of New York, USA
3Mathematical and Computing Science, Tokyo Institute of Technology, Japan
Motivation
Interfaces Are Traditionally Lists of Method Declarations
• Traditionally, an interface is a Java type that lists methoddeclarations.
• Clients are guaranteed that concrete interface implementersprovide implementations for all listed methods.
interface Collection<E> {int size();void add(E elem);boolean isEmpty();int capacity();abstract boolean atCapacity();} 1
Interfaces Are Traditionally Lists of Method Declarations
• Traditionally, an interface is a Java type that lists methoddeclarations.
• Clients are guaranteed that concrete interface implementersprovide implementations for all listed methods.
interface Collection<E> {int size();void add(E elem);boolean isEmpty();int capacity();abstract boolean atCapacity();} 1
Some Interface Methods Are Optional
• Interface methods can be listed as optional operations.
• Implementers may choose to support them or not.• If operations are unsupported, they conventionally throw anUnsupportedOperationException.
interface Collection<E> {// ...void add(E elem); /* optional */ }}
2
Some Interface Methods Are Optional
• Interface methods can be listed as optional operations.• Implementers may choose to support them or not.
• If operations are unsupported, they conventionally throw anUnsupportedOperationException.
interface Collection<E> {// ...void add(E elem); /* optional */ }}
class ImmutableList<E> implements Collection<E> {// ...
}
2
Some Interface Methods Are Optional
• Interface methods can be listed as optional operations.• Implementers may choose to support them or not.• If operations are unsupported, they conventionally throw anUnsupportedOperationException.
interface Collection<E> {// ...void add(E elem); /* optional */ }}
class ImmutableList<E> implements Collection<E> {// ...@Override public void add(E elem) {throw new UnsupportedOperationException();}}
2
Skeletal Implementation Classes Help Implement Interfaces
• The skeletal implementation design pattern [Bloch, 2008] isused to make implementing interfaces easier.
• Abstract skeletal implementation class provides partialimplementations.
• Implementers extend the skeletal implementation class ratherthan directly implementing the interface.
abstract class AbstractImmutableList<E> implementsCollection<E> {
@Override public void add(E elem) {throw new UnsupportedOperationException();}}
class ImmutableList<E> extends AbstractImmutableList<E>{// ...@Override public void add(E elem) {throw new UnsupportedOperationException();}}}
3
Skeletal Implementation Classes Help Implement Interfaces
• The skeletal implementation design pattern [Bloch, 2008] isused to make implementing interfaces easier.
• Abstract skeletal implementation class provides partialimplementations.
• Implementers extend the skeletal implementation class ratherthan directly implementing the interface.
abstract class AbstractImmutableList<E> implementsCollection<E> {
@Override public void add(E elem) {throw new UnsupportedOperationException();}}
class ImmutableList<E> extends AbstractImmutableList<E>{// ...@Override public void add(E elem) {throw new UnsupportedOperationException();}}}
3
Skeletal Implementation Classes Help Implement Interfaces
• The skeletal implementation design pattern [Bloch, 2008] isused to make implementing interfaces easier.
• Abstract skeletal implementation class provides partialimplementations.
• Implementers extend the skeletal implementation class ratherthan directly implementing the interface.
abstract class AbstractImmutableList<E> implementsCollection<E> {
@Override public void add(E elem) {throw new UnsupportedOperationException();}}
class ImmutableList<E> extends AbstractImmutableList<E>{// ...@Override public void add(E elem) {throw new UnsupportedOperationException();}}}
3
The Skeletal Implementation Pattern Has Several Drawbacks
The skeletal implementation pattern has several drawbacks.
ExampleImmutableList cannot:
• Subclass another class.• Inherit skeletal implementations split over multipleclasses [Horstmann, 2014].
• Inherit skeletal implementations for multiple interfaces.
4
The Skeletal Implementation Pattern Has Several Drawbacks
The skeletal implementation pattern has several drawbacks.
ExampleImmutableList cannot:
• Subclass another class.• Inherit skeletal implementations split over multipleclasses [Horstmann, 2014].
• Inherit skeletal implementations for multiple interfaces.
4
The Skeletal Implementation Pattern Has Several Drawbacks
The skeletal implementation pattern has several drawbacks.
ExampleImmutableList cannot:
• Subclass another class.
• Inherit skeletal implementations split over multipleclasses [Horstmann, 2014].
• Inherit skeletal implementations for multiple interfaces.
4
The Skeletal Implementation Pattern Has Several Drawbacks
The skeletal implementation pattern has several drawbacks.
ExampleImmutableList cannot:
• Subclass another class.• Inherit skeletal implementations split over multipleclasses [Horstmann, 2014].
• Inherit skeletal implementations for multiple interfaces.
4
The Skeletal Implementation Pattern Has Several Drawbacks
The skeletal implementation pattern has several drawbacks.
ExampleImmutableList cannot:
• Subclass another class.• Inherit skeletal implementations split over multipleclasses [Horstmann, 2014].
• Inherit skeletal implementations for multiple interfaces.
4
Java 8 Default Methods Can Replace Skeletal Implementations
• Java 8 enhanced interfaces allow both method declarations anddefinitions.
• Implementers inherit the (default) implementation if noneprovided.
• Original motivation to facilitate interface evolution.• Can also be used as a replacement of the skeletalimplementation 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> implementsCollection<E> {
@Override public void add(E elem) {throw new UnsupportedOperationException();}}
5
Java 8 Default Methods Can Replace Skeletal Implementations
• Java 8 enhanced interfaces allow both method declarations anddefinitions.
• Implementers inherit the (default) implementation if noneprovided.
• Original motivation to facilitate interface evolution.• Can also be used as a replacement of the skeletalimplementation 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> implementsCollection<E> {
@Override public void add(E elem) {throw new UnsupportedOperationException();}}
5
Java 8 Default Methods Can Replace Skeletal Implementations
• Java 8 enhanced interfaces allow both method declarations anddefinitions.
• Implementers inherit the (default) implementation if noneprovided.
• Original motivation to facilitate interface evolution.
• Can also be used as a replacement of the skeletalimplementation 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> implementsCollection<E> {
@Override public void add(E elem) {throw new UnsupportedOperationException();}}
5
Java 8 Default Methods Can Replace Skeletal Implementations
• Java 8 enhanced interfaces allow both method declarations anddefinitions.
• Implementers inherit the (default) implementation if noneprovided.
• Original motivation to facilitate interface evolution.• Can also be used as a replacement of the skeletalimplementation 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> implementsCollection<E> {
@Override public void add(E elem) {throw new UnsupportedOperationException();}}
5
Implementation
• Implemented as an open source plug-in for the Eclipse IDE(available at http://cuny.is/interefact).
• Built on existing refactoring support in Eclipse.• Conceptual approach based on type-constraints [Palsberg andSchwartzbach, 1994; Tip et al., 2011].
• See ICSE 2017 paper [Khatchadourian and Masuhara, 2017] forapproach details.
• Implementation is in procedural-style, similar to Pull UpMethod refactoring.
6
• Implemented as an open source plug-in for the Eclipse IDE(available at http://cuny.is/interefact).
• Built on existing refactoring support in Eclipse.
• Conceptual approach based on type-constraints [Palsberg andSchwartzbach, 1994; Tip et al., 2011].
• See ICSE 2017 paper [Khatchadourian and Masuhara, 2017] forapproach details.
• Implementation is in procedural-style, similar to Pull UpMethod refactoring.
6
• Implemented as an open source plug-in for the Eclipse IDE(available at http://cuny.is/interefact).
• Built on existing refactoring support in Eclipse.• Conceptual approach based on type-constraints [Palsberg andSchwartzbach, 1994; Tip et al., 2011].
• See ICSE 2017 paper [Khatchadourian and Masuhara, 2017] forapproach details.
• Implementation is in procedural-style, similar to Pull UpMethod refactoring.
6
• Implemented as an open source plug-in for the Eclipse IDE(available at http://cuny.is/interefact).
• Built on existing refactoring support in Eclipse.• Conceptual approach based on type-constraints [Palsberg andSchwartzbach, 1994; Tip et al., 2011].
• See ICSE 2017 paper [Khatchadourian and Masuhara, 2017] forapproach details.
• Implementation is in procedural-style, similar to Pull UpMethod refactoring.
6
• Implemented as an open source plug-in for the Eclipse IDE(available at http://cuny.is/interefact).
• Built on existing refactoring support in Eclipse.• Conceptual approach based on type-constraints [Palsberg andSchwartzbach, 1994; Tip et al., 2011].
• See ICSE 2017 paper [Khatchadourian and Masuhara, 2017] forapproach details.
• Implementation is in procedural-style, similar to Pull UpMethod refactoring. 6
High-level System Workflow
2. Options control refactoring “invasiveness.”
• Remove or deprecate empty classes.• Consider non-standard annotation differences.
3. Simple initial checks, e.g., file writability.4. Bulk of processing in final check.
etween method declarations and definitions. an be useful forprojects not using annotation processing frameworks.
7
High-level System Workflow
2. Options control refactoring “invasiveness.”
• Remove or deprecate empty classes.• Consider non-standard annotation differences.
3. Simple initial checks, e.g., file writability.4. Bulk of processing in final check.
etween method declarations and definitions. an be useful forprojects not using annotation processing frameworks.
7
High-level System Workflow
2. Options control refactoring “invasiveness.”• Remove or deprecate empty classes.
• Consider non-standard annotation differences.3. Simple initial checks, e.g., file writability.4. Bulk of processing in final check.
etween method declarations and definitions. an be useful forprojects not using annotation processing frameworks.
7
High-level System Workflow
2. Options control refactoring “invasiveness.”• Remove or deprecate empty classes.• Consider non-standard annotation differences.
3. Simple initial checks, e.g., file writability.4. Bulk of processing in final check.
etween method declarations and definitions. an be useful forprojects not using annotation processing frameworks.
7
High-level System Workflow
2. Options control refactoring “invasiveness.”• Remove or deprecate empty classes.• Consider non-standard annotation differences.
3. Simple initial checks, e.g., file writability.
4. Bulk of processing in final check.
etween method declarations and definitions. an be useful forprojects not using annotation processing frameworks.
7
High-level System Workflow
2. Options control refactoring “invasiveness.”• Remove or deprecate empty classes.• Consider non-standard annotation differences.
3. Simple initial checks, e.g., file writability.4. Bulk of processing in final check.
etween method declarations and definitions. an be useful forprojects not using annotation processing frameworks.
7
Architecture and Plug-In Dependencies
• Four plugins: two internal and two with UIs.
• Internal plug-ins include core and test plug-ins.• 259 automated refactoring tests.• UI plug-ins include both end-user tool and evaluator.• Depends on Eclipse refactoring support.
8
Architecture and Plug-In Dependencies
• Four plugins: two internal and two with UIs.• Internal plug-ins include core and test plug-ins.
• 259 automated refactoring tests.• UI plug-ins include both end-user tool and evaluator.• Depends on Eclipse refactoring support.
8
Architecture and Plug-In Dependencies
• Four plugins: two internal and two with UIs.• Internal plug-ins include core and test plug-ins.• 259 automated refactoring tests.
• UI plug-ins include both end-user tool and evaluator.• Depends on Eclipse refactoring support.
8
Architecture and Plug-In Dependencies
• Four plugins: two internal and two with UIs.• Internal plug-ins include core and test plug-ins.• 259 automated refactoring tests.• UI plug-ins include both end-user tool and evaluator.
• Depends on Eclipse refactoring support.
8
Architecture and Plug-In Dependencies
• Four plugins: two internal and two with UIs.• Internal plug-ins include core and test plug-ins.• 259 automated refactoring tests.• UI plug-ins include both end-user tool and evaluator.• Depends on Eclipse refactoring support. 8
Evaluation
Useful?
• Successfully converted ∼20%of methods possiblyparticipating in the pattern todefault methods incorresponding interfaces(see [Khatchadourian andMasuhara, 2017] for details).
• Many failures related to:
• Inaccessibility of membersbetween skeletalimplementers andinterfaces.
• Access to instance fields.
9
Useful?
• Successfully converted ∼20%of methods possiblyparticipating in the pattern todefault methods incorresponding interfaces(see [Khatchadourian andMasuhara, 2017] for details).
• Many failures related to:
• Inaccessibility of membersbetween skeletalimplementers andinterfaces.
• Access to instance fields.
9
Useful?
• Successfully converted ∼20%of methods possiblyparticipating in the pattern todefault methods incorresponding interfaces(see [Khatchadourian andMasuhara, 2017] for details).
• Many failures related to:• Inaccessibility of membersbetween skeletalimplementers andinterfaces.
• Access to instance fields.
9
Useful?
• Successfully converted ∼20%of methods possiblyparticipating in the pattern todefault methods incorresponding interfaces(see [Khatchadourian andMasuhara, 2017] for details).
• Many failures related to:• Inaccessibility of membersbetween skeletalimplementers andinterfaces.
• Access to instance fields.
9
Correct?
• Ensured that no compilationerrors existed before andafter refactoring.
• Verified unit tests resultsidentical before and after therefactoring.
• Preliminary pull requeststudy ensures that theautomated results matchedwhat experienced developersmay have written.
• Four projects accepted ourpull requests so far.
10
Correct?
• Ensured that no compilationerrors existed before andafter refactoring.
• Verified unit tests resultsidentical before and after therefactoring.
• Preliminary pull requeststudy ensures that theautomated results matchedwhat experienced developersmay have written.
• Four projects accepted ourpull requests so far.
10
Correct?
• Ensured that no compilationerrors existed before andafter refactoring.
• Verified unit tests resultsidentical before and after therefactoring.
• Preliminary pull requeststudy ensures that theautomated results matchedwhat experienced developersmay have written.
• Four projects accepted ourpull requests so far.
10
Correct?
• Ensured that no compilationerrors existed before andafter refactoring.
• Verified unit tests resultsidentical before and after therefactoring.
• Preliminary pull requeststudy ensures that theautomated results matchedwhat experienced developersmay have written.
• Four projects accepted ourpull requests so far.
10
Summary
Summary & Future Work
• A refactoring tool that migrates the skeletal implementationpattern to instead use Java 8 default methods based ontype-constraints.
• Implemented as an Eclipse IDE plug-in (available athttp://cuny.is/interefact).
• Evaluated using several techniques.• In the future, composite refactorings (field encapsulation, etc.).
11
Summary & Future Work
• A refactoring tool that migrates the skeletal implementationpattern to instead use Java 8 default methods based ontype-constraints.
• Implemented as an Eclipse IDE plug-in (available athttp://cuny.is/interefact).
• Evaluated using several techniques.• In the future, composite refactorings (field encapsulation, etc.).
11
Summary & Future Work
• A refactoring tool that migrates the skeletal implementationpattern to instead use Java 8 default methods based ontype-constraints.
• Implemented as an Eclipse IDE plug-in (available athttp://cuny.is/interefact).
• Evaluated using several techniques.
• In the future, composite refactorings (field encapsulation, etc.).
11
Summary & Future Work
• A refactoring tool that migrates the skeletal implementationpattern to instead use Java 8 default methods based ontype-constraints.
• Implemented as an Eclipse IDE plug-in (available athttp://cuny.is/interefact).
• Evaluated using several techniques.• In the future, composite refactorings (field encapsulation, etc.).
11
For Further Reading
Joshua Bloch. Effective Java. Addison Wesley, 2 edition, 2008. ISBN 0321356683.Brian Goetz. Interface evolution via virtual extensions methods. Technical report,Oracle Corporation, June 2011. URL http://cr.openjdk.java.net/~briangoetz/lambda/Defender%20Methods%20v4.pdf.
Cay S. Horstmann. Java SE 8 for the Really Impatient. Addison-Wesley Professional,2014.
Raffi Khatchadourian and Hidehiko Masuhara. Automated refactoring of legacy Javasoftware to default methods. In International Conference on Software Engineering,2017.
Jens Palsberg and Michael I. Schwartzbach. Object-oriented type systems. John Wileyand Sons Ltd., 1994. ISBN 0-471-94128-X.
Frank Tip, Robert M. Fuhrer, Adam Kieżun, Michael D. Ernst, Ittai Balaban, and BjornDe Sutter. Refactoring using type constraints. ACM Transactions on ProgrammingLanguages and Systems, 2011. doi: 10.1145/1961204.1961205.
12
top related