Generics Journey Continues

WARNING: Brain Might Explode

I’m not sure I will ever fully grok Java generics. Kevin’s explanation of Set.contains() was enough to prod me into well over 1 TimeUnit.HOURS of experimentation tonight.

While I can say that I follow his examples and could verify all of the behavior he describes, I cannot say I have a sense of deep confidence in this dark corner of the language.

What I Did

I wanted to experiment with different variations of Set.contains(...), but modifying the JDK Set interface would be quite complex. Instead, I wrote my own little interface:

public interface MySet<E> {
  boolean contains(Object o);
  boolean add(E o);
}

Along with a simple implementation (that merely delegates to the real HashSet), this is enough to tinker with the concepts.

Step 1: Verify Kevin’s Claims

As expected, the code below works exactly as he describes:

public class Main {
  public static void main(String[] args) {
    MySet<Long> set = new MyHashSet<Long>();
    set.add(10L);
    if (set.contains(10)) {
      System.out.println("10 is contained!");
    } else {
      System.out.println("10 is NOT contained!");
    }

    MySet<Foo> foos = new MyHashSet<Foo>();
    MySet<SubFoo> subFoos = new MyHashSet<SubFoo>();
    doSomeReading(foos);
    doSomeReading(subFoos);
  }

  public static void doSomeReading(MySet<? extends Foo> foos) {
    // EDIT: my first post incorrectly said new Foo() {}; here
    Foo aFoo = new Foo();
    System.out.println(foos.contains(aFoo));
  }
}

When you run the above code, it prints “10 is NOT contained!”, plus a few “false” messages from the dummy method.

Step 2: Modify Set.contains(…)

Now I tried changing my contains(...) method to this:

boolean contains(E o);

This breaks the sample program in two places. First, this line fails (which is actually good):

if (set.contains(10)) {

That’s nice because 10 is boxed into an Integer, and our Set expects a Long. Changing the parameter to 10L fixes that issue.

The second breakage is a problem, however:

System.out.println(foos.contains(aFoo));

I tried all sorts of mojo and came up with this ugly hack:

public static <T extends Foo> void doSomeReading(MySet<T> foos) {
  T aFoo = (T) new Foo();
  System.out.println(foos.contains(aFoo));
}

You know what? Everything compiles now. Only…with a warning:

Unchecked cast: ‘Foo’ to ‘T’

Damn.

Step 3: Try Something Else

So now I tried changing contains(...) to this:

boolean contains(? extends E o);

That won’t even compile. IDEA says “Wildcards may be used only as reference parameters”. Uh, yeah.

Step 4: Try Again

Then I tried this:

<T extends E> boolean contains(T o);

Hey, at least that compiles! As in my earlier attempt, the sample program fails to compile in the same two spots. I can fix the first issue by passing 10L, just like before.

And the same doSomeReading(...) hack also compiles, although with the same ugly warning as before.

Closing Thoughts

• Given the way generics work today, contains(Object o) seems better than any alternative.
• IDEA’s “Suspicious call to ‘Set.contains’” warning only works with the built-in collections. The warning does not fire for my custom MySet interface.
• I have to wonder…is there some underlying language improvement that could simultaneously allow both strict contains(E o) signatures while also supporting the substitutability principle for collections?

One more thing…all this talk of adding closures to Java…that scares me to death. Spontaneous brain explosion is a serious concern, already affecting 3% of Java programmers. With closures added to mix, that number will undoubtedly rise.

This entry was posted on Sunday, December 16th, 2007 at 10:17 pm and is filed under Java. You can skip to the end and leave a response.