Towards Improving Interface Modularity in Legacy Java Software Through Automated Refactoring

Towards Improving InterfaceModularity in Legacy Java

Software through AutomatedRefactoring

Ra� Khatchadourian, Olivia MooreComputer Systems Technology, New York City College of Technology

City University of New York, USA

Hidehiko MasuharaMathematical and Computing Science, Tokyo Institute of Technology,

Japan

International Workshop on Language Modularity 2016 (LaMOD'16) atthe International Conference on Modularity (MODULARITY'16)

Málaga, Spain

March 15, 2016

New Features in Java 8

Largest change was in ~2005 with Java 5.10 years later, Java 8 is packed with new features.Java 9 is on the horizon (Project Jigsaw, i.e., "modular Java", etc.)Our focus is Java 8 enhanced interfaces that allow default methods.

Java InterfacesA list of public method declarations (no bodies) that

concrete implementers (classes) must de�ne.

The Java Interface Type

Cannot be instantiated (abstract).Cannot contain instance �elds.Can extend other interfaces.Can contain public static �elds and methods (new in Java 8).

Multiple classes can implement an interface and aninterface can be implemented by multiple classes.

ExampleList contains declarations of methods common to all lists.

interface List<E> { //... /** * Removes all of the elements from this list (optional operation). * @throws UnsupportedOperationException if the clear operation * is not supported by this list. */ void clear(); //... }

MyList is a particular kind of list.

class MyList<E> implements List<E> { //... @Override public void clear() { // not supported. throw new UnsupportedOperationException(); } //... }

A List can refer to MyList instances in clients.

List<E> list = new MyList<>();

The Skeletal ImplementationPattern

Default behavior for interface methods.

ProblemInterface implementers may share common functionality.Some interface methods may be optional (like List.clear()).

Skeletal ImplementationsProvide separate abstract class as a partial interface implementation[Bloch'08].Implementers extend the skeletal implementation instead.Inherit "default" and/or partial interface method de�ntions.Makes implementing the interface easier.

Exampleinterface List<E> { //... /** * Removes all of the elements from this list (optional operation). * @throws UnsupportedOperationException if the clear operation * is not supported by this list. */ void clear(); //... }

abstract class AbstractList<E> implements List<E> { //... @Override public void clear() { // not supported. throw new UnsupportedOperationException(); } //... }

class MyList<E> extends AbstractList<E> { //... // Inherits default implementation of clear(). }

IssuesFlexibility

Java has single class inheritance -> classes cannot extend classesother than the skeletal implementation (can use delegation instead[Bloch'08]).

EvolvabilityInterface modi�cations must be in sync with skeletalimplementions in separate classes.

ModularityNo syntatical path from the interface to its skeletal implementation.Developers wishing to implement an interface may need a globalanalysis to �nd corresponding skeletal implementers.

Default MethodsAdd default behaviors to interfaces

Default MethodsTraditionally, interfaces can't have method de�nitions (justdeclarations).Default methods supply default implementations of interfacemethods.By default, implementers will receive this implementation if they don'tprovide their own.

Examples

Example 1Basics

interface List<E> { //... default void clear() { throw new UnsupportedOperationException(); } } class MyList<E> implements List<E> { //... }

Client code

List<E> list = new MyList<>(); list.clear();

Result

An UnsupportedOperationException is thrown.

Example 2Getting messy

interface List<E> { //... default void clear (){ throw new UnsupportedOperationException(); } } interface Queue<E> { default void clear() { System.err.println("Unsupported operation."); } }

class MyList<E> implements List<E>, Queue<E> { }

Does this code compile?

Of course not (Java is not C++)!

class MyList inherits defaults for clear() from bothtypes List and Queue

How do we �x it?

Option A:

class MyList<E> implements List<E>, Queue<E> { @Override public void clear() {/* ... */} }

We resolve it manually by overriding the con�icting method.

Option B:

class MyList<E> implements List<E>, Queue<E> { @Override public void clear (){ List.super.clear(); // or Queue.super.clear() } }

We call the default implementation of method clear() from eitherinterface List or Queue instead of implementing our own.

Work in ProgressCan eliminate the need for skeletal implementations?

MotivationTwo cases:

1. Complete migration of skeletal implementation to interface.Makes type hierarchy less complicated.

One less type.Makes interfaces easier to implement.

No global analysis required to �nd skeletal implemention.Makes interfaces easier to maintain.

No simultaneous modi�cations between interface and skeletalimplementation required.

2. Partial migration of skeletal implementation to interface.Possibly makes interfaces easier to implement.

All implementations may not need to extend the skeletalimplementation.

Possibly makes interfaces easier to maintain.Possibily less simultaneous modi�cations between interface andskeletal implementation required.

Work in ProgressCan eliminate the need for skeletal implementations?

Can we automate this?1. How do we determine if an interface

implementor is "skeletal?"2. What is the criteria for an instance method to be

converted to a default method?3. What if there is a hierarchy of skeletal

implementors, e.g., AbstractCollection,AbstractList?

4. How do we preserve semantics?5. What client changes are necessary?

Skeletal ImplementatorsAbstract classes that provide skeletal

implementations for interfaces.

Let's take a look at the Java UML for : AbstractCollection

Why is this Complicated?Corresponds to converting and migrating a skeletal (instance) method

implementation to an interface.

From a class To an interfaceinstance method default method

Can we not simply use a "Pull Up Method" [Fowler'99] refactoring?

Not exactly. The inherent problem is that, unlikeclasses, interfaces may extend multiple interfaces. As

such, we now have a kind of multiple inheritanceproblem to deal with.

Some (perhaps) ObviousPreconditions

Source instance method must not access any instance �elds.Interfaces may not have instance �elds.

Can't currently have a default method in the target interface withthe same signature.Can't modify target method's visibility.

Some Obvious TasksMust replace the target method in the interface (add a body to it).Must add the default keyword.Must remove any @Override annotations (it's top-level now).If nothing left in abstract class, remove it?Need to deal with documentation.

Some Not-so-obviousPreconditions

Suppose we have the following situation:

interface I { void m(); } interface J { void m(); } abstract class A implements I, J { @Override void m() {...} }

Here, A provides a partial implementation of I.m(), which also happensto be declared as part of interface J.

Some Not-so-obviousPreconditions

Now, we convert and migrate A.m() to a default method of I:

interface I { default void m() {..} //was void m(); } interface J { void m(); //stays the same. } abstract class A implements I, J { //now empty, was: void m() {...} }

We now have a compile-time error in A because A needs to declarewhich m() it inherits.In general, inheritance hierarchies may be large and complicated.Other preconditions may also exist (work in progress).

More InformationProject Website

http://openlab.citytech.cuny.edu/interfacerefactoring

Prototype ImplementationEclipse Plug-in; in progress

http://github.com/khatchad/Java-8-Interface-Refactoring

Time for a Live Demo?Migrate Skeletal Implementation to Interface prototype refactoring plug-in

for Eclipse

Questions?