extension methods

Syntax for calling “super” in Java 8 Defender methods

This is a very interesting discussion. How to reference default methods from implemented interfaces throughout the class / interface hierarchy?

Situation:

interface K {
  int m() default { return 88; }
}

interface J extends K {
  int m() default { return K.super.m(); }
                        // ^^^^^^^^^^^^ How to express this?
}

Solution ideas:

K.super.m()
super.K.m()
((K) super).m()
K::m()
K.default.m()
super<K>.m()
super(K).m()
super(K.class).m()
super[K].m()

Any other crazy ideas? See the discussion here:

http://mail.openjdk.java.net/pipermail/lambda-dev/2012-August/005616.html

Survey about the Java 8 “default method” syntax

Influence the future of Java now! Participate in this official survey by Brian Goetz:
https://www.surveymonkey.com/s/9VPJZQQ

Exciting ideas in Java 8: Streams

Brian Goetz’s recent post on the State of the Lambda reveils exciting new ideas that are prone to be included in Java 8. One of them is the concept of “Streams” as opposed to “Collections”. Using the new Java 8 extension methods, the Iterable interface can be extended compatibly with a lot of “lazy” and “eager” methods for streaming behaviour:

public interface Iterable<T> {
    // Abstract methods
    Iterator<T> iterator();

    // Lazy operations
    Iterable<T> filter(Predicate<? super T> predicate) default ...
    <U> Iterable<U> map(Mapper<? super T, ? extends U> mapper) default ...
    <U> Iterable<U> flatMap(
        Mapper<? super T, ? extends Iterable<U>> mapper) default ...
    Iterable<T> cumulate(BinaryOperator<T> op) default ...

    Iterable<T> sorted(
        Comparator<? super T> comparator) default ...
    <U extends Comparable<? super U>> Iterable<T> sortedBy(
        Mapper<? super T, U> extractor) default ...
    Iterable<T> uniqueElements() default ...

    <U> Iterable<U> pipeline(
        Mapper<Iterable<T>, ? extends Iterable<U>> mapper) default ...
    <U> BiStream<T, U> mapped(
        Mapper<? super T, ? extends U> mapper) default ...
    <U> BiStream<U, Iterable<T>> groupBy(
        Mapper<? super T, ? extends U> mapper) default ...
    <U> BiStream<U, Iterable<T>> groupByMulti(
        Mapper<? super T, ? extends Iterable<U>> mapper) default ...

    // Eager operations
    boolean isEmpty() default ...;
    long count() default ...
    T getFirst() default ...
    T getOnly() default ...
    T getAny() default ...

    void forEach(Block<? super T> block) default ...
    T reduce(T base, BinaryOperator<T> reducer) default ...
    <A extends Fillable<? super T>> A into(A target) default ...

    boolean anyMatch(Predicate<? super T> filter) default ...
    boolean noneMatch(Predicate<? super T> filter) default ...
    boolean allMatch(Predicate<? super T> filter) default ...

    <U extends Comparable<? super U>> T maxBy(
        Mapper<? super T, U> extractor) default ...
    <U extends Comparable<? super U>> T minBy(
        Mapper<? super T, U> extractor) default ...
}

The above are rough and incomplete API ideas, or as Brian Goetz puts it: A “strawman writeup of the key concepts”.

The goal of this early publication is for the community to “TRY OUT THE CODE. *The single most valuable thing that the community can do to help move this effort forward, and improve the quality of the result, is to try out the code early and often.*”

Read the full article here:

http://cr.openjdk.java.net/~briangoetz/lambda/collections-overview.html

Java 8 virtual extension methods

I’ve been following the evolution of the Java 8 Lambda expressions project for a while now, and I’m really thrilled by its current state of progress. The latest “easy-to-understand” presentation I’ve found is this one:
http://blogs.oracle.com/briangoetz/resource/devoxx-lang-lib-vm-co-evol.pdf

Now, as an API designer, I’m particularly interested in the concept of virtual extension methods and I was wondering whether it was also considered to introduce “final” extension methods as opposed to “default” ones. For example:

interface A {
  void a();
  void b() default { System.out.println("b"); };
  void c() final { System.out.println("c"); };
}

When implementing the above interface A, one…

MUST also implement a()
MAY implement / override b()
CANNOT override c()

Advantages:

API designers can create convenience methods more easily without risking client code “illegally” overriding default implementations. That’s one of the main purposes of “final”.
Lambda expressions wouldn’t need to be limited to pure “functional interfaces” (single-method interfaces), as a functional interface would still be “functional” if it also had any number of final extension methods. For example, the above interface A would become a functional interface, if b() was removed or if b() was made final as well.
Extension methods would have more features in common with regular methods, which can be final as well. I guess for the reflection API and for the JVM, that’s a plus.
The JVM is modified anyway to support extension methods. Java 8’s momentum could be used for this feature as well, i.e. now is the right time to think about this

Disadvantages:

A class could inherit multiple colliding final method implementations in the case of “diamond interface inheritance“. This could lead to new compilation errors in existing code. I guess this lack of backwards compatibility is the biggest drawback.

As with multiple inheritance itself, careful API designers could
further improve their API’s when using final extension methods,
whereas less careful API designers might break client code. But this
is the case with previous usage of “final” as well, so I think final
extension methods would be a very nice addition to Java 8.

See the full mail and follow-up on the lambda-dev mailing list here:
http://mail.openjdk.java.net/pipermail/lambda-dev/2011-December/004426.html

Java, SQL and jOOQ.