Thursday, February 6, 2014

Java 8 Type Annotations

Lambda expressions are by far the most discussed and promoted feature of Java 8. While I agree that Lambdas are a large improvement I think that some other Java 8 feature go a bit short because of the Lambda hype. In this post I want to show a number of examples from another nice Java 8 feature: Type Annotations.

Type Annotations are annotations that can be placed anywhere you use a type. This includes the new operator, type casts, implements clauses and throws clauses. Type Annotations allow improved analysis of Java code and can ensure even stronger type checking.

In source code this means we get two new ElementTypes for annotations:
@Target({ElementType.TYPE_USE, ElementType.TYPE_PARAMETER})
public @interface Test {
} 
The enum value TYPE_PARAMETER allows an annotation to be applied at type variables (e.g. MyClass<T>). Annotations with target TYPE_USE can be applied at any type use.

Please note that the annotations from the following examples will not work out of the box when Java 8 is released. Java 8 only provides the ability to define these types of annotations. It is then up to framework and tool developers to actually make use of it. So this is a collection of annotations frameworks could give us in the future. Most of the examples are taken from the Type Annotations specification and various Java 8 presentations.

Simple type definitions with type annotations look like this:
@NotNull String str1 = ...
@Email String str2 = ...
@NotNull @NotBlank String str3 = ...
Type annotations can also be applied to nested types
Map.@NonNull Entry = ...
Constructors with type annotations:
new @Interned MyObject()
new @NonEmpty @Readonly List<String>(myNonEmptyStringSet)
They work with nested (non static) class constructors too:
myObject.new @Readonly NestedClass()
Type casts:
myString = (@NonNull String) myObject;
query = (@Untainted String) str;
Inheritance:
class UnmodifiableList<T> implements @Readonly List<T> { ... }
We can use type Annotations with generic type arguments:
List<@Email String> emails = ...
List<@ReadOnly @Localized Message> messages = ...
Graph<@Directional Node> directedGraph = ...
Of course we can nest them:
Map<@NonNull String, @NonEmpty List<@Readonly Document>> documents;
Or apply them to intersection Types:
public <E extends @ReadOnly Composable<E> & @Localized MessageSource> void foo(...) { ... }
Including parameter bounds and wildcard bounds:
class Folder<F extends @Existing File> { ... }
Collection<? super @Existing File> c = ...
List<@Immutable ? extends Comparable<T>> unchangeable = ...
Generic method invocation with type annotations looks like this:
myObject.<@NotBlank String>myMethod(...);
For generic constructors, the annotation follows the explicit type arguments:
new <String> @Interned MyObject()
Throwing exceptions:
void monitorTemperature() throws @Critical TemperatureException { ... }
void authenticate() throws @Fatal @Logged AccessDeniedException { ... }
Type annotations in instanceof statements:
boolean isNonNull = myString instanceof @NonNull String;
boolean isNonBlankEmail = myString instanceof @NotBlank @Email String;
And finally Java 8 method and constructor references:
@Vernal Date::getDay
List<@English String>::size
Arrays::<@NonNegative Integer>sort

Conclusion
Type annotations are an interesting addition to the Java type system. They can be applied to any use of a type and enable a more detailed code analysis. If you want to use Type annotations right now you should have a look at the Checker Framework.

If you want to continue reading about this topic you should check out the discussion on reddit.

Share this post using Facebook, Twitter or Google+

4 comments:

  1. I sincerely believe that once you get to the point that you need this sort of type system, you should switch to a language that has native support for it...

    ReplyDelete
  2. I agree with Lukas here.

    This level of (over) annotating code makes it far harder to learn, read and maintain. It is far more powerful and easier to maintain unit tests for some of these conditions.

    I have a similar feeling about Lambdas. Does the benefit outweigh the cost in learning curve and reduced readability? It remains to be seen, but I'm skeptical.

    JDK 8 should have been all about fixing Generics (kill raw types) and removing all deprecated code from JDK 1.5 and older. Instead of cleaning up the language, they are adding more and more crap with every passing release. More features != better. They should clean up the language first, before adding more stuff into it.

    ReplyDelete
  3. While I agree that over annotated code is painful to read I don't think this will become a (bigger) problem with type annotations. In my opinion, this is mostly a problem of certain frameworks that require a bunch of (sometimes nested) annotations on class names and fields. I see type annotations a bit different here because they are much more fluent to read if named properly. Something like "@NotEmpty String str" should be easy to understand.

    ReplyDelete
  4. Great article. I really loves features which some how get hidden between biggies like lambda expression and streams. Java 8 seems to have good number of these hidden picks.

    ReplyDelete