GOTO notes: Evolving Java

04/29/13

GOTO notes: Evolving Java

Evolving Java
Brian Goetz - Java Language Architect, Oracle

Compatibility - avoiding breaking existing programs - takes up a lot of his time.
Serialization - big regret.
What Would James Do?

Java SE 8 - modernizing Java - Summer 2013

Alonzo Church - 1930’s Lambda Calculus

Language features are only enablers.
Better libraries are what gets things done.

In 1995, few mainstream languages supported closures.
Today, Java is just about the last holdout. (Even C++ added them recently.)

In 1995, everything was sequential. (Single processor.) For loops, iterators, etc.
In today’s world, that’s an impediment to parallelizing code.

Mutability was the default.
Today, that’s the wrong default.

External Iteration
There’s a lot of accidental complexity in a for loop that’s mutating items in a collection. We want to separate the “what” from the “how".

Internal Iteration
Don’t ask me, just do it.
The library can use parallelism, out-of-order, laziness.
(This is an argument for ForEach() as a method. - Bill S.)

Lambda Expressions

What is the type of a lambda?

Functional Interfaces

Problem - Interface Evolution
If we had lambdas when we designed Collection libraries, our libraries would look nothing like they do.
New feature: default methods (similar to abstract)
  You can add a virtual interface method with a default implementation.
  If an existing implementation doesn’t have the new method, it still works (using the default implementation).
  Multiple inheritance of behavior, not state.
  This is not full-blown traits (like Scala).
  Not designed for monkey-patching.

It’s All About the Libraries
Best way to evolve the platform - cheaper, more scalable, etc.

Lambdas Enable Better APIs
Boundary between client and library becomes more permeable
The library owns the “how", the client owns the “what”
Key effect on APIs is: more composability
  You want to build behavior by composition.

Sorting today: The code reads nothing like the problem statement.
You want the code to look as much as possible like the requirements.

Bulk operations on Collections
Exposing aggregate operations on collections.
(Very LINQ-y.)
You have to ask for parallelism, but you don’t have to ask very loudly.

Guy Steele’s talk on How to Think about Parallel Programming: Not!
(Highly recommended by presenter.)

Streams
New abstraction
Stream of values - not a data structure
Pipelined
Lazy
(like IEnumerable in C# - Bill S.)

Parallelism
Let the experts write the libraries, and let the libraries handle the hard problems.
JDK7 added Fork/Join - lots of boilerplate code
parallelStream() lets you do map-reduce easily.

Aggregation
sum() is a special case of what functional languages tend to call fold
Reductions work really nicely in parallel.
Composable.

Gentle push towards a more functional style of programming.
People will have to unlearn some things. Want pure methods, immutability, etc.

Tuples coming!?


Your Host: webmaster@truewill.net
Copyright © 2000-2013 by William Sorensen. All rights reserved.