joustlog

I’ve been using Java 5’s generics a lot lately, and I’ve been thinking about what about the design works, and what needs improvement. Here’s a list of some things I think Java’s generics needs.

1. Cleaner syntax

My main problem with generics is that the syntax is so verbose. For example:

private Set<OutputPortValueListener<? super V>> listeners
    = new CopyOnWriteArraySet<OutputPortValueListener<? super V>>();

I think there needs to be a way to tell the compiler to figure out what the type arguments for some things must be, like this:

private Set<OutputPortValueListener<? super V>> listeners
    = new CopyOnWriteArraySet<...>();

The compiler could easily figure out what the “…” needed to be replaced with.

2. Stronger inference of generic type arguments

Java’s type inference is intentionally weaker than it could be. In fact, it is weaker than it was before 5.0’s release. Sun’s compiler team decided it would be too difficult to document the advanced type inference capabilities of javac in the Java Language Specification, so they simply removed them. Now, code like this won’t compile, when it would have with earlier versions of javac:

SortedSet<Map.Entry<Integer,Port<?>>> entries
         = new TreeSet<Map.Entry<Integer,Port<?>>>(KeyComparator.getInstance());
...
class KeyComparator<K extends Comparable<? super K>>
        implements Comparator<Map.Entry<K, ?>> {
    public static <K extends Comparable<? super K>> KeyComparator<K> getInstance() {
        return new KeyComparator<K>();
    }
    public int compare(Map.Entry<K, ?> entry, Map.Entry<K, ?> entry1) {
        return entry.getKey().compareTo(entry1.getKey());
    }
}

To compile, the underlined part needs to be replaced with “KeyComparator.<Integer>getInstance()”, because javac can’t figure out that it needs the <Integer> type argument. As I said, earlier versions of javac didn’t need the explicit type argument for this type of inference.

3. Inferred type bounds

As I’ve shown already, right now javac requires you to be verbose in your generics code in several ways. Another way is with generic type bounds. The following code will not compile:

<E> void doSomething(EnumSet<E> set, E val) { }

javac complains that you must specify bounds for <E>, because EnumSet<T> requires that T be a subtype of Enum<T>. So, you must insert the bounds like this to get it to work:

<E extends Enum<E>> void doSomething(EnumSet<E> set, E val) { }

The compiler should have been able to figure out this bound, but instead, you have to write it out, making your code longer and uglier, and not much, if any, clearer to developers who must use the method.

4. Inferred type arguments

Sometimes we want type arguments to be optional, when they could be inferred from the values other type arguments. For example, in this code, again using EnumSet:

class Thing<S extends EnumSet<E>, E extends Enum<E>> { }

The E type parameter could be inferred from the S type parameter, so a user of the Thing class should never need to explicitly type it in their programs.

There is also no syntax for defining type parameters whose values should only be inferred, and should not be specified by the user of the class. For example, maybe this syntax would work:

class Thing<X,Y extends X> uses <Z extends Y & Comparable<? super Z>> {
    public Thing(Z argument) { .. }
}

You might have noticed that this functionality is very similar to a feature used heavily with generics in C++: typedefs. Maybe instead of my “uses” syntax, you could do this:

class Thing<X,Y extends X> {
    public type Z extends Y & Comparable<? super Z>;
    public Thing(Z argument) { .. }
}

Thinking in terms of typedefs, another option might be:

public type ThingParam<T> extends T & Comparable<? super ThingParam<T>>;

class Thing<X,Y extends X> {
    public Thing(ThingParam<Y> argument) { .. }
}

This would allow us to create our own types without actually making classes, like this:

public type IdentifierMap extends Map<Integer,SomeObject>;

Then, we could start making our own code less verbose with these type definitions alone.

5. Support for backwards compatibility

Currently, if you write a class today that takes two type parameters, you are tied to those parameters forever, unless you want to break code that uses the class. If you want a third type parameter, you have to create a subclass or subinterface of the class which takes three parameters, and then tell the developers using the old class to switch over to the new class. (Or something like that, depending on your needs.)

In Java, we can overload methods with different numbers and types of parameters. I think we should be able to handle different type parameters just as easily. While I don’t know if this would be practical, we could at least take a small step forward by specifying default values for type parameters. The code might look like this:

public class Something<X,
        Y extends Comparable<? super Y>,
        Z extends Collection<? extends X> = List<? extends X>> { }

This would make the following two statements equivalent:

Something<String,Integer> thing = new Something<String,Integer>();
Something<String,Integer,List<? extends String>> thing
        = new Something<String,Integer,List<? extends String>>();

Another possible syntax for this would be possible if you could add metadata annotations to type parameters, and use type literals as annotation properties:

public class Something<X,
        Y extends Comparable<? super Y>,
        @Default(List<? extends X>) Z extends Collection<? extends X>{ }

Conclusion

These are some ideas I’ve been thinking about. I’d like to hear if anyone else has had similar problems as mine, and what you think of my ideas for solutions.

This entry was posted on Wednesday, December 1st, 2004 at 10:59 pm and is filed under Code. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.