Open Problems in Automatically Refactoring Legacy Java Software to use New Features in Java 8

Open Problems in Automatical-Open Problems in Automatical-
ly Refactoring Legacy Javaly Refactoring Legacy Java
Software to use New FeaturesSoftware to use New Features
in Java 8in Java 8
Raﬃ Khatchadourian
Computer Systems Technology
New York City College of Technology
City University of New York
Programming Research Group
Mathematical and Computing Sciences
Tokyo Institute of Technology
June 2, 2015
Based on slides by Duarte Duarte, Eduardo Martins, Miguel Marques and
Ruben Cordeiro and Horstmann, Cay S. (2014-01-10). Java SE8 for the
Really Impatient: A Short Course on the Basics (Java Series). Pearson
Education.

Demonstration code at: .http://github.com/khatchad/java8-demo

Some HistorySome History
Java was invented in the 90's as an Object-Oriented language.
Largest change was in ~2005 with Java 5.
Generics.
Enhanced for loops.
Annotations.
Type-safe enumerations.
Concurrency enhancements (AtomicInteger).

Java 8 is MassiveJava 8 is Massive
10 years later, Java 8 is packed with new features.
Core changes are to incorporate functional language features.

Functional LanguagesFunctional Languages
Declarative ("what not how").
The only state is held in parameters.
Traditionally popular in academia and AI.
Well-suited for event-driven/concurrent ("reactive") programs.

Lambda ExpressionsLambda Expressions
A block of code that you can pass around so it can be
executed later, once or multiple times.
Anonymous methods.
Reduce verbosity caused by anonymous classes.

LambdasLambdas
(int x, int y) -> x + y
() -> 42
(String s) -> {System.out.println(s);}

LambdasLambdas
ExamplesExamples
BeforeBefore
Button btn = new Button();
final PrintStream pStream = ...;
btn.setOnAction(new EventHandler<ActionEvent>() {
@Override
public void handle(ActionEvent e) {
pStream.println("Button Clicked!");
}
});
AfterAfter
Button btn = new Button();
final PrintStream pStream = ...;
btn.setOnAction(e -> pStream.println("Button Clicked!"));

LambdasLambdas
ExamplesExamples
List<String> strs = ...;
Collections.sort(strs, (s1, s2) ->
Integer.compare(s1.length(), s2.length()));
new Thread(() -> {
connectToService();
sendNotification();
}).start();

Functional InterfacesFunctional Interfaces
Single Abstract Method Type

Functional InterfacesFunctional Interfaces
ExampleExample
@FunctionalInterface
public interface Runnable {
public void run();
}
Runnable r = () -> System.out.println("Hello World!");
@FunctionalInterface:
May be omitted.
Generates an error when there is more than one abstract method.
Can store a lambda expression in a variable.
Can return a lambda expression.

java.util.functionjava.util.function
Predicate<T> - a boolean-valued property of an object
Consumer<T> - an action to be performed on an object
Function<T,R> - a function transforming a T to a R
Supplier<T> - provide an instance of a T (such as a factory)
UnaryOperator<T> - a function from T to T
BinaryOperator<T> - a function from (T,T) to T

Method ReferencesMethod References
Treating an existing method as an instance of a
Functional Interface

ExamplesExamples
class Person {
private String name;
private int age;
public int getAge() {return this.age;}
public String getName() {return this.name;}
}
Person[] people = ...;
Comparator<Person> byName = Comparator.comparing(Person::getName);
Arrays.sort(people, byName);

Kinds of method referencesKinds of method references
A static method (ClassName::methName)
An instance method of a particular object
(instanceRef::methName)
A super method of a particular object (super::methName)
An instance method of an arbitrary object of a particular type
(ClassName::methName)
A class constructor reference (ClassName::new)
An array constructor reference (TypeName[]::new)

More ExamplesMore Examples
Consumer<Integer> b1 = System::exit;
Consumer<String[]> b2 = Arrays::sort;
Consumer<String> b3 = MyProgram::main;
Runnable r = MyProgram::main;

Default MethodsDefault Methods
Add default behaviors to interfaces

Why default methods?Why default methods?
Java 8 has lambda expressions. We want to start using them:
List<?> list = ...
list.forEach(...); // lambda code goes here

There's a problemThere's a problem
The forEach method isn’t declared by java.util.List nor the
java.util.Collection interface because doing so would break
existing implementations.

We have lambdas, but we can't force new behaviors into current
libraries.
Solution: 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.

Example 1Example 1
BasicsBasics

public interface A {
default void foo() {
System.out.println("Calling A.foo()");
}
}
public class Clazz implements A {
}

Client codeClient code
Clazz clazz = new Clazz();
clazz.foo();
OutputOutput
"Calling A.foo()"

Example 2Example 2
Getting messyGetting messy

public interface A {
default void foo(){
System.out.println("Calling A.foo()");
}
}
public interface B {
default void foo(){
System.out.println("Calling B.foo()");
}
}
public class Clazz implements A, B {
}
Does this code compile?

Of course not (Java is not C++)!
class Clazz inherits defaults for foo() from both types
A and B
How do we ﬁx it?

Option A:
public void foo(){/* ... */}
}
We resolve it manually by overriding the conﬂicting method.
Option B:
public void foo(){
A.super.foo(); // or B.super.foo()
}
}
We call the default implementation of method foo() from either
interface A or B instead of implementing our own.

Going back to the example of forEach method, how can we force it's
default implementation on all of the iterable collections?

Let's take a look at the Java UML for all the iterable Collections:
To add a default behavior to all the iterable collections, a default
forEach method was added to the Iterable<E> interface.

We can ﬁnd its default implementation in java.lang.Iterable
interface:
@FunctionalInterface
public interface Iterable {
Iterator iterator();
default void forEach(Consumer<? super T> action) {
Objects.requireNonNull(action);
for (T t : this) {
action.accept(t);
}
}
}

The forEach method takes a java.util.function.Consumer
functional interface type as a parameter, which enables us to pass in a
lambda or a method reference as follows:
List<?> list = ...
list.forEach(System.out::println);
This is also valid for Sets and Queues, for example, since both classes
implement the Iterable interface.
Speciﬁc collections, e.g., UnmodifiableCollection, may override
the default implementation.

SummarySummary
Default methods can be seen as a bridge between lambdas and JDK
libraries.
Can be used in interfaces to provide default implementations of
otherwise abstract methods.
Clients can optionally implement (override) them.
Can eliminate the need for skeletal implementators like
.
Can eliminate the need for utility classes like .
static methods are now also allowed in interfaces.
AbstractCollection
Collections

Open ProblemsOpen Problems
Can eliminate the need for skeletal implementators like
.AbstractCollection
Can we automate this?Can we automate this?
1. How do we determine if an interface
implementor is "skeletal?"
2. What is the criteria for an abstract 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 ImplementatorsSkeletal Implementators
Abstract classes that provide skeletal implementations
for interfaces.
Let's take a look at the Java UML for AbstractCollection:

Open ProblemsOpen Problems
Can eliminate the need for utility classes like .Collections
Can we automate this?Can we automate this?
1. How do we determine if a class is a
"utility" class?
2. What is the criteria for a static method to
be:
Converted to an instance method?
Moved to an interface?
3. How do we preserve semantics?
4. What client changes are necessary?

Let's start with question #2 for both the previous slides. There seems to
be a few cases here:
# From a class To an interface
1. abstract method default method
2. instance method default method
3. static method default method
4. static method static method
Can you see any diﬀerence between cases #1 and
#2?
Is case #4 a simple move method refactoring? (Yes
but to where? -- more later)

Why Is This Complicated?Why Is This Complicated?
Case #1 corresponds to moving a skeletal implementation to an
interface.
1. abstract method default method
For case #1, can we not simply use a move method refactoring?
No. 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.

Case #1Case #1
Some (perhaps) Obvious PreconditionsSome (perhaps) Obvious Preconditions
Source abstract method must not access any instance ﬁelds.
Interfaces may not have instance ﬁelds.
Can't currently have a default method in the target interface with
the same signature.
Can't modify target method's visibility.
Some Obvious TasksSome Obvious Tasks
Must 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.

Case #1Case #1
Some Not-so-obvious PreconditionsSome Not-so-obvious Preconditions
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 happens
to be declared as part of interface J.

Case #1Case #1
Now, we pull up A.m() to be 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 declare
which m() it inherits.
In general, inheritance hierarchies may be large and complicated.
Other preconditions may also exist (work in progress).

Why Is This Complicated?Why Is This Complicated?
Case #3 corresponds to moving a static utility method to an interface.
3. static method default method
For case #1, can we not simply use a move method refactoring?
No and for a few reasons:
Method signature must change (not only removing
the static keyword).
Client code must change from static method calls
to instance method calls.
Which parameter is to be the receiver of the call?
What is the target interface?

Case #3Case #3
Some (perhaps) Obvious PreconditionsSome (perhaps) Obvious Preconditions
The source method vaciously doesn't access instance ﬁelds.
Default version of the source method can't already exist in the target
interface.
Some Obvious TasksSome Obvious Tasks
Must add the default keyword.
If nothing left in utility class, remove it?
Need to deal with documentation.

Case #3Case #3
/**
* Copies all of the elements from one list into another.
*/
public static <T> void Collections.copy(List<? super T> dest, List<? extends T
Should this be a static or default method?
Call it as Collections.copy(l2, l1) or l2.copy(l1)?
It's probably more natural to leave it as static .
Also, we can't express the generics if it was refactored to a
default method.
The generics here express the relationship between the two
lists in a single method.
We can't do if it was default.

Case #3Case #3
This method should actually move to the List interface and remain
static, but:
What is there's another method named copy in the List interface?
List is an interface, and interfaces can extend other interfaces.
What if there's another method with the same signature in the
hierarchy?

Case #3Case #3
You may be tempted to move the copy method to a default method in
List, but since the method uses generics and expresses a very distinct
relationship between two two Lists, you will lose the type safety
oﬀered by the generics. For example, suppose you have:
List<String> l1;
List<String> l2;
Now, you copy the contents of l2 into l1:
Collections.copy(l1, l2);
If l2 is, instead, List<Integer>, you will receive a compile-time error.
However, if copy was a default method of, say, the List interface, we
would have something like this:
l1.copy(l2)
Making l2 a List<Integer> would not result in a compile-time error.

Case #4Case #4
Determining the target interface for caseDetermining the target interface for case
#4#4
We can apply a heuristic: take the least common interface of the
parameters. For example:
public static void m(I1 p1, I2 p2, ..., In pn);
Here, we would take the closest sibling to I1, I2, ..., In as the target
interface. Otherwise, we normally take the ﬁrst parameter if it's an
interface.

java.util.streamjava.util.stream
ﬁlter/map/reduce for Java

List<Student> students = ...;
Stream stream = students.stream(); // sequential version
// parallel version
Stream parallelStream = students.parallelStream();
traversed once
inﬁnite
lazy

Stream sourcesStream sources
CollectionsCollections
Set<Student> set = new LinkedHashSet<>();
Stream<Student> stream = set.stream();
GeneratorsGenerators
Random random = new Random();
Stream<Integer> randomNumbers = Stream.generate(random::nextInt);
// or simply ...
IntStream moreRandomNumbers = random.ints();
From other streamsFrom other streams
Stream newStream = Stream.concat(stream, randomNumbers);

Intermediate operationsIntermediate operations
.filter - excludes all elements that don’t match a Predicate
.map - perform transformation of elements using a Function
.flatMap - transform each element into zero or more elements by
way of another Stream
.peek - performs some action on each element
.distinct - excludes all duplicate elements (equals())
.sorted - orderered elements (Comparator)
.limit - maximum number of elements
.substream - range (by index) of elements
List<Person> persons = ...;
Stream<Person> tenPersonsOver18 = persons.stream()
.filter(p -> p.getAge() > 18)
.limit(10);

Terminating operationsTerminating operations
1. Obtain a stream from some sources
2. Perform one or more intermidate operations
3. Perform one terminal operation
reducers like reduce(), count(), findAny(), findFirst()
collectors (collect())
forEach
iterators
List<Person> persons = ..;
List<Student> students = persons.stream()
.map(Student::new)
.collect(Collectors.toList());

Parallel & SequentialParallel & Sequential
List<Person> persons = ..;
List<Student> students = persons.stream()
.parallel()
.sequential()
.map(Student::new)
.collect(Collectors.toCollection(ArrayList::new));

Documentation & InterestingDocumentation & Interesting
LinksLinks
http://download.java.net/jdk8/docs/
http://download.java.net/jdk8/docs/api/
https://blogs.oracle.com/thejavatutorials/entry/jdk_8_documentation_develope
http://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html

Open Problems in Automatically Refactoring Legacy Java Software to use New Features in Java 8

More Related Content

What's hot (18)

Viewers also liked (8)

Similar to Open Problems in Automatically Refactoring Legacy Java Software to use New Features in Java 8 (20)

More from Raffi Khatchadourian (20)

Recently uploaded (20)

Open Problems in Automatically Refactoring Legacy Java Software to use New Features in Java 8