Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Towards Improving Interface
Modularity in Legacy Java
Software through Automated
Refactoring
Ra Khatchadourian, Olivia Moo...
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...
Java Interfaces
A list of publicmethod 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 ...
Example
Listcontains declarations of methods common to all lists.
interfaceList<E>{//...
/**
*Removesalloftheelementsfromt...
The Skeletal Implementation
Pattern
Default behavior for interface methods.
Problem
Interface implementers may share common functionality.
Some interface methods may be optional (like List.clear()).
Skeletal Implementations
Provide separate abstractclass as a partial interface implementation
[Bloch'08].
Implementers ext...
Example
interfaceList<E>{//...
/**
*Removesalloftheelementsfromthislist(optionaloperation).
*@throwsUnsupportedOperationEx...
Issues
Flexibility
Java has single class inheritance -> classes cannot extend classes
other than the skeletal implementati...
Default Methods
Add default behaviors to interfaces
Default Methods
Traditionally, interfaces can't have method de nitions (just
declarations).
Default methods supply default...
Examples
Example 1
Basics
interfaceList<E>{//...
defaultvoidclear(){
thrownewUnsupportedOperationException();
}
}
classMyList<E>implementsList<E>{//...
Client code
List<E>list=newMyList<>();
list.clear();
Result
An UnsupportedOperationExceptionis thrown.
Example 2
Getting messy
interfaceList<E>{//...
defaultvoidclear(){
thrownewUnsupportedOperationException();
}
}
interfaceQueue<E>{
defaultvoidclea...
Of course not (Java is not C++)!
class MyListinherits defaults for clear() from both
types Listand Queue
How do we x it?
Option A:
classMyList<E>implementsList<E>,Queue<E>{
@Override
publicvoidclear(){/*...*/}
}
We resolve it manually by overr...
Work in Progress
Can eliminate the need for skeletal implementations?
Motivation
Two cases:
1. Complete migration of skeletal implementation to interface.
Makes type hierarchy less complicated...
Work in Progress
Can eliminate the need for skeletal implementations?
Can we automate this?
1. How do we determine if an i...
Skeletal Implementators
Abstract classes that provide skeletal
implementations for interfaces.
Let's take a look at the Ja...
Why is this Complicated?
Corresponds to converting and migrating a skeletal (instance) method
implementation to an interfa...
Some (perhaps) Obvious
Preconditions
Source instancemethod must not access any instance elds.
Interfaces may not have inst...
Some Obvious Tasks
Must replace the target method in the interface(add a body to it).
Must add the defaultkeyword.
Must re...
Some Not-so-obvious
Preconditions
Suppose we have the following situation:
interfaceI{
voidm();
}
interfaceJ{
voidm();
}
a...
Some Not-so-obvious
Preconditions
Now, we convert and migrate A.m()to a default method of I:
interfaceI{
defaultvoidm(){.....
More Information
Project Website
http://openlab.citytech.cuny.edu/interfacerefactoring
Prototype Implementation
Eclipse Pl...
Time for a Live Demo?
Migrate Skeletal Implementation to Interface prototype refactoring plug-in
for Eclipse
Questions?
Upcoming SlideShare
Loading in …5
×

Towards Improving Interface Modularity in Legacy Java Software Through Automated Refactoring

742 views

Published on

The skeletal implementation pattern is a software design pattern
consisting of defining an abstract class that provides a partial interface implementation. However, since Java allows only single class inheritance, if implementers decide to extend a skeletal implementation, they will not be allowed to extend any other class. Also, discovering the skeletal implementation may require a global analysis. Java 8 enhanced interfaces alleviate these problems by allowing interfaces to contain (default) method implementations, which implementers inherit. Java classes are then free to extend a different class, and a separate abstract class is no longer needed; developers considering implementing an interface need only examine the interface itself. We argue that both these benefits improve software modularity, and discuss our ongoing work in developing an automated refactoring tool that would assist developers in taking advantage of the enhanced interface feature for their legacy Java software.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Towards Improving Interface Modularity in Legacy Java Software Through Automated Refactoring

  1. 1. Towards Improving Interface Modularity in Legacy Java Software through Automated Refactoring Ra Khatchadourian, Olivia Moore Computer Systems Technology, New York City College of Technology City University of New York, USA Hidehiko Masuhara Mathematical and Computing Science, Tokyo Institute of Technology, Japan International Workshop on Language Modularity 2016 (LaMOD'16) at the International Conference on Modularity (MODULARITY'16) Málaga, Spain March 15, 2016
  2. 2. 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 defaultmethods.
  3. 3. Java Interfaces A list of publicmethod declarations (no bodies) that concrete implementers (classes) must de ne.
  4. 4. 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 an interface can be implemented by multiple classes.
  5. 5. Example Listcontains declarations of methods common to all lists. interfaceList<E>{//... /** *Removesalloftheelementsfromthislist(optionaloperation). *@throwsUnsupportedOperationExceptioniftheclearoperation *isnotsupportedbythislist. */ voidclear();//... } MyListis a particular kind of list. classMyList<E>implementsList<E>{//... @Override publicvoidclear(){//notsupported. thrownewUnsupportedOperationException(); }//... } A Listcan refer to MyListinstances in clients. List<E>list=newMyList<>();
  6. 6. The Skeletal Implementation Pattern Default behavior for interface methods.
  7. 7. Problem Interface implementers may share common functionality. Some interface methods may be optional (like List.clear()).
  8. 8. Skeletal Implementations Provide separate abstractclass as a partial interface implementation [Bloch'08]. Implementers extendthe skeletal implementation instead. Inherit "default" and/or partial interface method de ntions. Makes implementing the interface easier.
  9. 9. Example interfaceList<E>{//... /** *Removesalloftheelementsfromthislist(optionaloperation). *@throwsUnsupportedOperationExceptioniftheclearoperation *isnotsupportedbythislist. */ voidclear();//... } abstractclassAbstractList<E>implementsList<E>{//... @Override publicvoidclear(){//notsupported. thrownewUnsupportedOperationException(); }//... } classMyList<E>extendsAbstractList<E>{//... //Inheritsdefaultimplementationofclear(). }
  10. 10. Issues Flexibility Java has single class inheritance -> classes cannot extend classes other than the skeletal implementation (can use delegation instead [Bloch'08]). Evolvability Interface modi cations must be in sync with skeletal implementions in separate classes. Modularity No syntatical path from the interface to its skeletal implementation. Developers wishing to implement an interface may need a global analysis to nd corresponding skeletal implementers.
  11. 11. Default Methods Add default behaviors to interfaces
  12. 12. Default Methods Traditionally, interfaces can't have method de nitions (just declarations). Default methods supply default implementations of interface methods. By default, implementers will receive this implementation if they don't provide their own.
  13. 13. Examples
  14. 14. Example 1 Basics
  15. 15. interfaceList<E>{//... defaultvoidclear(){ thrownewUnsupportedOperationException(); } } classMyList<E>implementsList<E>{//... }
  16. 16. Client code List<E>list=newMyList<>(); list.clear(); Result An UnsupportedOperationExceptionis thrown.
  17. 17. Example 2 Getting messy
  18. 18. interfaceList<E>{//... defaultvoidclear(){ thrownewUnsupportedOperationException(); } } interfaceQueue<E>{ defaultvoidclear(){ System.err.println("Unsupportedoperation."); } } classMyList<E>implementsList<E>,Queue<E>{ } Does this code compile?
  19. 19. Of course not (Java is not C++)! class MyListinherits defaults for clear() from both types Listand Queue How do we x it?
  20. 20. Option A: classMyList<E>implementsList<E>,Queue<E>{ @Override publicvoidclear(){/*...*/} } We resolve it manually by overriding the con icting method. Option B: classMyList<E>implementsList<E>,Queue<E>{ @Override publicvoidclear(){ List.super.clear();//orQueue.super.clear() } } We call the default implementation of method clear()from either interface Listor Queueinstead of implementing our own.
  21. 21. Work in Progress Can eliminate the need for skeletal implementations?
  22. 22. Motivation Two 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 skeletal implementation required. 2. Partial migration of skeletal implementation to interface. Possibly makes interfaces easier to implement. All implementations may not need to extend the skeletal implementation. Possibly makes interfaces easier to maintain. Possibily less simultaneous modi cations between interface and skeletal implementation required.
  23. 23. Work in Progress Can 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?
  24. 24. Skeletal Implementators Abstract classes that provide skeletal implementations for interfaces. Let's take a look at the Java UML for :AbstractCollection
  25. 25. Why is this Complicated? Corresponds to converting and migrating a skeletal (instance) method implementation to an interface. From a class To an interface instancemethod defaultmethod Can we not simply use a "Pull Up Method" [Fowler'99] refactoring? Not exactly. The inherent problem is that, unlike classes, interfaces may extend multiple interfaces. As such, we now have a kind of multiple inheritance problem to deal with.
  26. 26. Some (perhaps) Obvious Preconditions Source instancemethod must not access any instance elds. Interfaces may not have instance elds. Can't currently have a defaultmethod in the target interface with the same signature. Can't modify target method's visibility.
  27. 27. Some Obvious Tasks Must replace the target method in the interface(add a body to it). Must add the defaultkeyword. Must remove any @Overrideannotations (it's top-level now). If nothing left in abstractclass, remove it? Need to deal with documentation.
  28. 28. Some Not-so-obvious Preconditions Suppose we have the following situation: interfaceI{ voidm(); } interfaceJ{ voidm(); } abstractclassAimplementsI,J{ @Override voidm(){...} } Here, Aprovides a partial implementation of I.m(), which also happens to be declared as part of interface J.
  29. 29. Some Not-so-obvious Preconditions Now, we convert and migrate A.m()to a default method of I: interfaceI{ defaultvoidm(){..}//wasvoidm(); } interfaceJ{ voidm();//staysthesame. } abstractclassAimplementsI,J{ //nowempty,was:voidm(){...} } We now have a compile-time error in Abecause Aneeds to declare which m()it inherits. In general, inheritance hierarchies may be large and complicated. Other preconditions may also exist (work in progress).
  30. 30. More Information Project Website http://openlab.citytech.cuny.edu/interfacerefactoring Prototype Implementation Eclipse Plug-in; in progress http://github.com/khatchad/Java-8-Interface-Refactoring
  31. 31. Time for a Live Demo? Migrate Skeletal Implementation to Interface prototype refactoring plug-in for Eclipse
  32. 32. Questions?

×