Wednesday Jun 01, 2011

EclipseCon 2007

Alex and I are on stage at EclipseCon 2007 waiting to give our presentation, unfortunately this means that we are missing Scott Adams who we can hear from the conference room next to ours.

So if you're interested in hearing our talk on Java SE 7 language features, now would be a good time to head down to Santa Clara Convention Center. We start at 10:10am.

The Language of God?

Thanks to Randall Munroe for generously sharing his comics with the rest of the world.

A Case for Generics

Forget about my wish list from last month. There are a few really good ideas on that list (closures and super packages). I gave up on properties. The rest is about making generic types easier to use. However, during my recent hiatus in Europe, I have been reflecting on generics. What is the problem with generics? Is it too complicated?

No doubt, generic types are relatively new in mainstream programming languages and wildcards are truly unique: it was literally invented for the Java™ programming language. This means that a lot of developers are not yet comfortable with generics. When I first heard about Object-Oriented Programming, I found it really scary. All that about inheritance, overriding, overloading, is-a, and has-a. Frankly, there is still a lot of confusion about something as fundamental as is-a, and has-a.

Most developers are very comfortable with OOP. In five years, most developers will be comfortable with generics.

Generic types are taking a lot of heat on various blogs. Not all of the critisism is without substance. I see that there is a problem when I talk to developers and close compiler bug reports as not being a bug. I see that there is a problem when trying to teach generics. I see that is a problem that causes otherwise diligent developers ignore a whole category of warnings about potential type unsafety in their programs.

The problem is the lack of reification. In other words, the lack of runtime type-information about generic types (at runtime, you cannot tell an ArrayList<String> from aArrayList<Integer>). We need to do something about that. It is indeed time to erase erasure!

In the next weeks I'll explain what it buys us and how we can accomplish it.

Static Factory Methods

Let me jump right into it. I propose an alternative to type inference for local variables. I'll explain why later. Everybody knows this example:


I propose this solution:

Map<String,List<Integer>> map =;

Before I get to caught up in the details, let me examine why we are talking about this in the first place. As far as I'm aware, there are primarily two reasons for looking at examples as the above:

  1. DRY—Don't repeat yourself.
  2. Inspiration from scripting languages (or dynamically typed languages): JavaScript, Ruby, Smalltalk, Scheme, etc. Moving to Java from such languages can feel very constraining because you have to type so many types.

I'm currently aware of two serious proposals, the first from James:

map := new HashMap<String,List<Integer>>();

The second is from Christian:

final map = new HashMap<String,List<Integer>>();

Rémi has implemented both of these proposals. But let us not forget what is going on in other languages:

var map = new HashMap<String,List<Integer>>();

This is well known from JavaScript and has recently been added to C#. However, adding it to Java would require adding a new keyword (which is bad) or having some really strange rules. So var is not really a contender for Java.

All of these proposals (mine excluded) essentially solve the problem using the same technique: type inference. The problem is that this promotes bad behavior:

  • Forces use of class types, not interface types on local variables. Generally the opposite is recommend as implementations are more flexible when they rely on interfaces instead of specific implementation classes. This is mediated by only allowing this syntax on local variables so no API is affected.
  • Code could be slightly harder to read. In many cases type declarations on variables are helpful when reading some code. Most will argue that some of the really nasty examples with long type arguments are fun to neither read nor write. So eliding the type on a variable can sometimes improve readability. However, since the language can't enforce a readability rule, some developers will misuse such a feature.

This motivated Neal to suggest:


Neal and I just had a chat about this. I think we both agree that it is ugly but the alternative could have compatibility problems (as well as other problems):

Map<String,List<Integer>> map = new HashMap();

So you can probably see how I got the idea:

Map<String,List<Integer>> map =;

However, there is more to it than just a simple syntax for constructing instances. My initial reaction to this problem was: we need more static factories throughout the JDK. For example:

Map<String,List<Integer>> map = HashMap.create();

Where the definition of create is:

public static <K,V> HashMap<K,V> create() { return new HashMap<K,V>(); }

What I propose is actually a new syntax for declaring static factory methods and that the compiler adds them by default (as it does with constructors). For example, if you declare a class:

public class Box<T> {
    public Box() {}

The compiler would automatically add this method:

public static <T> Box<T> new() { return new Box<T>(); }

The programmer can specify any number of new methods just as it is possible to have multiple constructors. If the programmer provides a new method with a signature that matches that of a public constructor, that will be used instead of the compiler providing one.

Thanks to Neal M Gafter for his input on this idea and this posting.

Kitchen Sink Language is open for Business

James jumped the gun a little bit earlier this week by announcing the Kitchen Sink Language before I had finished setting it up. So if you went there and got disappointed, please try again. We do require that you sign the SCA before you join, more details on the project page.

The Former Weblog of Peter Ahé


« June 2011