—
« Static Factory Metho... | Main | The Language of God? »

Search

Categories

Links

Referers

Today's Page Hits: 96

A Case for Generics

Jan 26 2007, 01:04:44 AM PST »Java»Language Comments [6]

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 a ArrayList<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.

Post a Comment:
Comments are closed for this entry.
Comments:

I agree with you that Java needs reified generics now. Later it will be too late.
I have two simple questions:

  1. Is the VM spec will change ? a la C#
  2. Is wildcard will be supported at runtime ?

Rémi

Posted by Rémi Forax on January 26, 2007 at 01:57 AM PST #

Hi,

If you can do it without C++ style code bloat, that would be great, but are there not already JDK-supplied (or at least fairly standard) cllection wrappers that explicitly check types and that could therefore allow those types to be tested at runtime?

Rgds

Damon

Posted by Damon Hart-Davis on January 26, 2007 at 03:01 AM PST #

I am actually expecting Peter to go on and talk about patterns that resolves common issues with erasure. After all, I really don't see a direct change in the VM for reification would have much gain.

Posted by Alex Lam on January 28, 2007 at 01:31 AM PST #

As someone who is writing an extensive framework that uses reflection... I could not agree more. Erasure is pure evil. It breaks java and makes meta-programming using reflection impossible.

Posted by Gary on January 29, 2007 at 10:52 AM PST #

Just to add... erasure has nothing to do with code bloat or efficiency. That is taken care of (or not) by java passing in type information as a hidden parameter as opposed to at the source level ala c++. You loose a lot of power by doing that, but you do have some gains: no code bloat, easier to debug and optimize, no need to have all the source available at compile time. Erasure was added for backwards compatibility. Just a waste...

Posted by 69.110.236.18 on January 29, 2007 at 10:55 AM PST #

Peter: thank God that you recognize the problem of generics in java and the lack of type reification that is driving us all nuts--and even better, that you are in a position to do something about it!

One small suggestion that I have about generics is simply a syntax sugar enhancement that will aid code readability.

I would like to see you introduce syntax that would allow you to eliminate duplicate generics definitions by using "...".

For example, instead of declaring a variable like
Map<Foo,List<? extends Bar>> fooToBar = new HashMap<Foo,List<? extends Bar>>();
which is really ugly, why should I not be able to eliminate that redundant generics definition as follows:
Map<Foo,List<? extends Bar>> fooToBar = new HashMap...();
where the compiler infers from ... that the same generics definition should be used?

Posted by Brent on April 25, 2007 at 07:22 AM PDT #

Java is a trademark of Sun Microsystems, Inc.
Copyright © 2006,2007 Peter von der Ahé