Defaultification Refactoring: A Tool for Automatically Converting Java Methods to Default

Defaultiﬁcation Refactoring: A Tool for
Automatically Converting Java Methods to
Default
Rafﬁ Khatchadourian1,2
Hidehiko Masuhara3
International Conference on Automated Software Engineering, 2017
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

Interfaces Are Traditionally Lists of Method Declarations
• Traditionally, an interface is a Java type that lists method
declarations.
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 method
declarations.
• Clients are guaranteed that concrete interface implementers
provide implementations for all listed methods.
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.
// ...
void add(E elem); /* optional */ }}
2

• Implementers may choose to support them or not.
// ...
class ImmutableList<E> implements Collection<E> {
// ...
}
2

• Implementers may choose to support them or not.
• If operations are unsupported, they conventionally throw an
UnsupportedOperationException.
// ...
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] is
used to make implementing interfaces easier.
3

• Abstract skeletal implementation class provides partial
implementations.
abstract class AbstractImmutableList<E> implements
Collection<E> {
3

• Abstract skeletal implementation class provides partial
implementations.
• Implementers extend the skeletal implementation class rather
than directly implementing the interface.
Collection<E> {
class ImmutableList<E> extends AbstractImmutableList<E>{
// ...
throw new UnsupportedOperationException();}}}
3

The Skeletal Implementation Pattern Has Several Drawbacks
The skeletal implementation pattern has several drawbacks.
4

Example
ImmutableList cannot:
4

Example
• Subclass another class.
4

Example
• Inherit skeletal implementations split over multiple
classes [Horstmann, 2014].
4

Example
• Inherit skeletal implementations split over multiple
classes [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 and
deﬁnitions.
default void add(E elem) { // optional.
5

deﬁnitions.
• Implementers inherit the (default) implementation if none
provided.
class ImmutableList<E> implements Collection<E> {}
5

deﬁnitions.
provided.
• Original motivation to facilitate interface evolution.
5

deﬁnitions.
provided.
• Original motivation to facilitate interface evolution.
• Can also be used as a replacement of the skeletal
implementation pattern [Goetz, 2011].
Collection<E> {
5

• Implemented as an open source plug-in for the Eclipse IDE
(available at http://cuny.is/interefact).
6

• Built on existing refactoring support in Eclipse.
6

• Conceptual approach based on type-constraints [Palsberg and
Schwartzbach, 1994; Tip et al., 2011].
6

• See ICSE 2017 paper [Khatchadourian and Masuhara, 2017] for
approach details.
6

• See ICSE 2017 paper [Khatchadourian and Masuhara, 2017] for
approach details.
• Implementation is in procedural-style, similar to Pull Up
Method refactoring. 6

High-level System Workﬂow
2. Options control refactoring “invasiveness.”
7

• Remove or deprecate empty classes.
7

• Consider non-standard annotation differences.
7

3. Simple initial checks, e.g., ﬁle writability.
7

3. Simple initial checks, e.g., ﬁle writability.
4. Bulk of processing in ﬁnal check. 7

Architecture and Plug-In Dependencies
• Four plugins: two internal and two with UIs.
8

• Internal plug-ins include core and test plug-ins.
8

• 259 automated refactoring tests.
8

• UI plug-ins include both end-user tool and evaluator.
8

• UI plug-ins include both end-user tool and evaluator.
• Depends on Eclipse refactoring support. 8

Useful?
• Successfully converted ∼20%
of methods possibly
participating in the pattern to
default methods in
corresponding interfaces
(see [Khatchadourian and
Masuhara, 2017] for details).
9

Useful?
of methods possibly
default methods in
• Many failures related to:
9

Useful?
of methods possibly
default methods in
• Inaccessibility of members
between skeletal
implementers and
interfaces.
9

Useful?
of methods possibly
default methods in
• Inaccessibility of members
between skeletal
implementers and
interfaces.
• Access to instance ﬁelds.
9

Correct?
• Ensured that no compilation
errors existed before and
after refactoring.
10

Correct?
after refactoring.
• Veriﬁed unit tests results
identical before and after the
refactoring.
10

Correct?
after refactoring.
refactoring.
• Preliminary pull request
study ensures that the
automated results matched
what experienced developers
may have written.
10

Correct?
after refactoring.
refactoring.
• Preliminary pull request
study ensures that the
automated results matched
what experienced developers
may have written.
• Four projects accepted our
pull requests so far.
10

Summary & Future Work
• A refactoring tool that migrates the skeletal implementation
pattern to instead use Java 8 default methods based on
type-constraints.
11

type-constraints.
• Implemented as an Eclipse IDE plug-in (available at
http://cuny.is/interefact).
11

type-constraints.
• Evaluated using several techniques.
11

type-constraints.
• Evaluated using several techniques.
• In the future, composite refactorings (ﬁeld 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.
Rafﬁ Khatchadourian and Hidehiko Masuhara. Automated refactoring of legacy Java
software to default methods. In International Conference on Software Engineering,
2017.
Jens Palsberg and Michael I. Schwartzbach. Object-oriented type systems. John Wiley
and Sons Ltd., 1994. ISBN 0-471-94128-X.
Frank Tip, Robert M. Fuhrer, Adam Kieżun, Michael D. Ernst, Ittai Balaban, and Bjorn
De Sutter. Refactoring using type constraints. ACM Transactions on Programming
Languages and Systems, 2011. doi: 10.1145/1961204.1961205.
12

Defaultification Refactoring: A Tool for Automatically Converting Java Methods to Default

More Related Content

What's hot (20)

Similar to Defaultification Refactoring: A Tool for Automatically Converting Java Methods to Default (20)

More from Raffi Khatchadourian (20)

Recently uploaded (20)

Defaultification Refactoring: A Tool for Automatically Converting Java Methods to Default