What Future Java Might Look Like

During the second week of November was Devoxx Belgium, Europe's biggest Java conference, and as every year the community's who's-who showed up. One of them was Brian Goetz, Java Language Architect at Oracle, and he gave what I would consider the conference's most thrilling talk: "Java Language and Platform Futures: A Sneak Peek". In it he presented ideas that the JDK team is currently kicking around. And boy, is the pipeline full of great stuff! Java won't look the same once it's all out in the wild.

When will that be? Nobody knows. And that's not nobody as in nobody outside of Oracle, that's nobody as in nobody knows whether happy endings exist for arbitrary n. Brian went to great lengths to stress how very, very speculative all of the following is and how much things might evolve or simply get dropped. He went so far to let everyone in the audience sign an acknowledgment thereof (just mentally but still) and explicitly forbade any sensationalist tweets.

Well... first of all, this is no tweet and second of all, I wasn't in that audience. So here we go! (Seriously though, take this as what it is: a glimpse into one of many, many possible futures.)

Crash Course

Before we go through the ideas one by one, let's jump right in and have a look at what code might look like that uses all of the envisaged features. The following class is a simple linked list that uses two types of nodes:

• InnerNodes that contain a value and link to the next node
• EndNodes that only contain a value

One particularly interesting operation is reduce, which accepts a seed value and a BinaryOperator and applies it to the seed and all of the nodes' values. This is what that might one day look like:

public class LinkedList<any T> {

    private Optional<Node<T>> head;

    // [constructors]
    // [list mutation by replacing nodes with new ones]

    public T reduce(T seed, BinaryOperator<T> operator) {
        var currentValue = seed;
        var currentNode = head;

        while (currentNode.isPresent()) {
            currentValue = operator.apply(currentValue, currentNode.get().getValue());
            currentNode = switch (currentNode.get()) {
                case InnerNode(_, var nextNode) -> Optional.of(nextNode);
                case EndNode(_) -> Optional.empty();
                default: throw new IllegalArgumentException();
            }
        }

        return currentValue;
    }

    private interface Node<any T> {
        T getValue();
    }

    private static class InnerNode<any T>(T value, Node<T> next) implements Node<T> { }

    private static class EndNode<any T>(T value) implements Node<T> { }

}

Wow! Hardly Java anymore, right?! Besides the omitted constructors there's only code that actually does something - I mean, where's all the boilerplate? And what if I told you that on top of that performance would be much better than today? Sounds like a free lunch, heck, like an entire free all-you-can-eat buffet!

Here's what's new:

• The generic type argument is marked with any - what's up with that?
• Where are the type information for currentValue and currentNode in reduce?
• That switch is almost unrecognizable.
• The classes InnerNode and EndNode look, err, empty.

Let's look at all the ideas that went into this example.

Continue reading %What Future Java Might Look Like%

by Nicolai Parlog via SitePoint