Closures, the next "Big Thing" in Java: Russel Winder

Closures
The Next “Big Thing” in Java

Russel Winder
email: russel@winder.org.uk
xmpp: russel@winder.org.uk
twitter: @russel_winder

Copyright © 2012 Russel Winder 1

Closures
The Next “Big Thing” in Java?

Russel Winder


Aims, Goals and Objectives
● Investigate why some idioms from Java 0–7 lead to
bad code in a post-Java 7 world.
● Show what some of the idioms of Java 8 and beyond
are likely to be.
● Survive to the end of the session.


Structure

A beginning.

A middle.

An end.


Interstitial Advertisement


A Beginning


Many people are still using Java 1.4.


They see no reason to move to any
later version of Java:
no real benefit, for too much pain.


Java 5 is a barrier too far for them.


The Java 7 → Java 8 change
is an even more disruptive change.


This possibly means Java
is now a legacy language?


No, it's an opportunity to stop
programming using 1970s techniques
and start using 1930s ones.


Alonzo Church
Alan Turing
Stephen Kleene
J B Rosser


And an opportunity to do 1990s programming.


i.e. We finally get to do real object-oriented
programming using Java.


Another Beginning


What is a “closure”?


A closure is a function with an associated
environment containing values for all the free
variables in the function.


A Function

Integer f(final Integer x) {
return x * y ;
}

Free variable.


A closure should be referentially transparent.

Whenever function f is evaluated on the same value,
a say, then the same value is returned.

f(a) = b


Java has had things (sort of) like this
since (almost) the beginning…


A closure can be realized as an instance of
a class with a single method and
single assignment fields.


public class ClosureClass {
private final Integer multiplier;
public ClosureClass(final Integer m) {
multiplier = m;
}
public Integer call(final Integer i) {
return multiplier * i;
}
}

No free variables in call.


final ClosureClass multiplyBy5 = new ClosureClass(5);

multiplyBy5.call(4)


Alternatively…


public interface ClosureInterface<T> {
T call(T t);
}

final ClosureInterface<Integer> multiplyBy5 =
new ClosureInterface<Integer>() {
public Integer call(final Integer i) {
return 5 * i;
}
};

multiplyBy5.call(4)


If Java had operator overloading, this
could be made to look much nicer.


Just as it can in proper programming languages
such as Groovy, Scala, C++, Python, etc.


final multiplyBy5 = {i -> 5 * i}

final multiplyBy5 = {5 * it}

multiplyBy5(4)

multiplyBy5.call(4)


def multiplyBy5(i: Int): Int = 5 * i

multiplyBy5(4)


But Java 8 can do stuff a bit like that…


final ClosureInterface<Integer> multiplyBy5 = i -> 5 * i;

multiplyBy5.call(4)


Nothing much revolutionary here,
just a bit of syntactic sugar…


…true, but that isn't all there is…


A Middle


It all about where the iteration is.


Explicit iteration

vs.

Implicit iteration


Work with a (trivial) example:


Calculate the sum of the squares of the
numbers between 0 and 100 that are
divisible by 7.


final List<Integer> numbers = new ArrayList<>();
for (int i = 0; i < 100; ++i) {
if (i % 7 == 0) {
numbers.add(i);
}
}
Integer sum = 0 ;
for (final Integer i: numbers) {
sum += i * i;
}


(for (i <- 0 until 100; if i % 7 == 0) yield i * i).sum


sum(i * i for i in range(100) if i % 7 == 0)


(0 until 100).filter(i => i %7 == 0).map(i => i * i).sum


(0..100).findAll{i -> i % 7 == 0}.collect{i -> i * i}.sum()


(0..100).findAll{it % 7 == 0}.collect{it * it}.sum()


numbers.filter(i -> i % 7 == 0).map(i -> i * i).reduce(0, (t, x) -> t + x)

Huh?


final List<Integer> numbers = new ArrayList<>();
for (int i = 0; i < 100; ++i) { numbers.add(i); }

Oh ffs.

Higher Order Functions


Functions that take functions as parameters
and/or return functions as result.


Some may be thinking:
Why do I give a f###


After all nothing good has happened
in Java since Java 1.4.2.


Because all computers are
now parallel computers.


We have to move to an attitude where we
assume our software is not uniprocessor.


We have to actually do object-oriented and
functional programming.


Instead of just saying we write Java and so are
doing object-oriented programming.


numbers.parallel().filter(i -> i % 7 == 0).
map(i -> i * i).reduce(0, (t, x) -> t + x)


GParsPool.withPool {
value = (0..100).findAllParallel{it % 7 == 0}.collectParallel{it * it}.sum()
}


GParsPool.withPool {
value = (0..100).parallel.filter{it % 7 == 0}.map{it * it}.sum()
}

Very Java 8.

def value = (0..100)
ParallelEnhancer.enhanceInstance(value)
value = value.parallel.filter{it % 7 == 0}.map{it * it}.sum()


def value = (0..100)
ParallelEnhancer.enhanceInstance(value)
value = value.findAllParallel{it % 7 == 0}.collectParallel{it * it}.sum()


GPars and Groovy give you Java 8 style
approach and parallelism today
for Java with JDK6 or JDK7.


Guava, TotallyLazy, and FunctionalJava can be used
today to practice the functional approach using Java.

Or just install the JDK8 Lambda release.


(0 until 100).par.filter(i => i %7 == 0).map(i => i * i).sum


An End


Java is about to get the functional
programming aspect.


Java is about to become
an object-oriented language.


Scala, Groovy, Python, C++, etc.
already have object-oriented and functional.


It's all about how your data evolves.

It's not about the flow of control.


It's all about sending messages to your
objects, requesting activity.


Closure the next “big thing” in Java?


Squirrels deny parallelism.


Yes*.

*But will everyone ignore it?

No.


It is not the lambda expressions in Java 8 that is
the disruptive revolution.

It's the change to the Java library that is.

It's all about those defender methods.


Surreptitious Advertisement


The End


Closures
The Next “Big Thing” in Java?

Russel Winder


Closures, the next "Big Thing" in Java: Russel Winder

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (12)

Similaire à Closures, the next "Big Thing" in Java: Russel Winder

Similaire à Closures, the next "Big Thing" in Java: Russel Winder (12)

Plus de JAX London

Plus de JAX London (20)

Closures, the next "Big Thing" in Java: Russel Winder