A Lesser-Known Java 8 Feature: Generalized Target-Type Inference

Going through the list of Java 8 features, Generalized Target-Type Inference struck me as a particularly interesting, lesser-known gem. It looks as though the Java language designers will ease some of the pain that we’ve been having with generics in the past (Java 5-7). Let’s have a look at their example:

class List<E> {
  static <Z> List<Z> nil() {..}
  static <Z> List<Z> cons(Z head, List<Z> tail) {..}
  E head() {..}
}

Given the above example, the JEP 101 feature claims that it would be nice to be able to write:

// This:
List.cons(42, List.nil());
String s = List.nil().head();

// ... instead of this:
List.cons(42, List.<Integer>nil());
String s = List.<String>nil().head();

Being a fluent API designer myself, I was thrilled to see that such an improvement is on the roadmap, particularly the latter. What’s so exciting about these changes? Let me comment on that more in detail:

// In addition to inferring generic types from
// assignments
List<String> l = List.nil();

// ... it would be nice for the compiler to be able
// to infer types from method argument types
List.cons(42, List.nil());

// ... or from "subsequent" method calls
String s = List.nil().head();

So in the last example where methods are chained, the type inference would be delayed until the whole assignment expression has been evaluated. From the left-hand side of the assignment, the compiler could infer that <Z> binds to String on the head() call. This information could then be used again to infer that <Z> binds again to String on the nil() call.

Sounds like a lot of trickery to me, as the nil() call’s AST evaluations would need to be delayed until a “dependent” sub-AST is evaluated. Is that a good idea?

Yes, this is so awesome!

… you may think. Because a fluent API like jOOQ or the Streams API could be designed in a much much more fluent style, delaying type inference until the end of the call chain.

So I downloaded the latest evaluation distribution of the JDK 8 to test this with the following program:

public class InferenceTest {
    public static void main(String[] args) {
        List<String> ls = List.nil();
        List.cons(42, List.nil());
        String s = List.nil().head();
    }
}

I compiled this and I got:

C:\Users\Lukas\java8>javac InferenceTest.java
InferenceTest.java:5: error: incompatible types: 
    Object cannot be converted to String
        String s = List.nil().head();
                                  ^
1 error

So, the type inference based on the method argument type is implemented (and thus, compiles), but not the type inference for chained method calls. I searched the internet for an explanation and found this Stack Overflow question linking to this interesting thread on the lambda-dev mailing list.

It appears that the Java type system has become quite complex. Too complex to implement such crazy type inference stuff. But still, a slight improvement that will be greatly valued when writing every day Java 8 code.

And maybe, in Java 9, we’ll get val and var, like everyone else ;-)

Subtle Changes in Java 8: Repeatable Annotations

Apart from the “big stuff”, related to extension methods, lambda, and the streams API, Java 8 also has a couple of minor, very subtle changes. One of them is the fact that you can now annotate an object several times with the same annotation!

An example taken from the tutorial:

@Alert(role="Manager")
@Alert(role="Administrator")
public class UnauthorizedAccessException { ... }

For this to work, your @Alert annotation has to be meta-annotated with java.lang.annotation.Repeatable.

Tools, which heavily rely on annotation processing may need to review their code to get ready for Java 8. Existing methods, such as AnnotatedElement.getAnnotations(), have not been retrofitted to return repeatable annotations. Instead, other, new methods, such as AnnotatedElement.getAnnotationsByType(Class) and AnnotatedElement.getDeclaredAnnotationsByType(Class) have been added to the JDK, in order to be able to discover repeated annotations on any element.

More authoritative information can be found here:

JDK 8: State of the Collections

Here’s the latest publication by Brian Goetz, Oracle’s project lead for JSR 335, a.k.a. Project Lambda. Here’s a nice example showing new collection features, such as “Streams” using method references:

List<String> strings = ...
int sumOfLengths = strings.stream()
                          .map(String::length)
                          .reduce(0, Integer::plus);

Another nice example showing the use of lambda expressions:

int sum = shapes.stream()
                .filter(s -> s.getColor() == BLUE)
                .map(s -> s.getWeight())
                .sum();

See more, here:
http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html