views:

2335

answers:

5

Update: Thanks for everyone who helped out - the answer to this one lay in what I wasn't noticing in my more complex code and what I didn't know about the Java5 covariant return types.

Original Post:

I've been playing around with something this morning. While I know that I could tackle this whole problem differently, I'm finding myself obsessed with figuring out why it isn't working the way that I was expecting. After spending some time reading around on this, I find I'm no closer to understanding, so I offer it up as a question to see if I'm just being stupid or if there is really something I don't understand going on here.

I have created a custom Event hierarchy like so:

public abstract class AbstractEvent<S, T extends Enum<T>>
{
    private S src;
    private T id;

    public AbstractEvent(S src, T id)
    {
        this.src = src;
        this.id = id;
    }

    public S getSource()
    {
        return src;
    }

    public T getId()
    {
        return id;
    }
}

With a concrete implementation like so:

public class MyEvent
extends AbstractEvent<String, MyEvent.Type>
{
    public enum Type { SELECTED, SELECTION_CLEARED };

    public MyEvent(String src, Type t)
    {
        super(src, t);
    }
}

And then I create an event like so:

fireEvent(new MyEvent("MyClass.myMethod", MyEvent.Type.SELECTED));

Where my fireEvent is defined as:

protected void fireEvent(MyEvent event)
{
    for(EventListener l : getListeners())
    {
        switch(event.getId())
        {
            case SELECTED:
                l.selected(event);
                break;
            case SELECTION_CLEARED:
                l.unselect(event);
                break;
         }
    }
}

So I thought that this would be pretty straightforward but it turns out that the call to event.getId() results in the compiler telling me that I cannot switch on Enums, only convertible int values or enum constants.

It is possible to add the following method to MyEvent:

public Type getId()
{
    return super.getId();
}

Once I do this, everything works exactly as I expected it to. I'm not just interested in finding a workaround for this (because I obviously have one), I'm interested in any insight people might have as to WHY this doesn't work as I expected it to right off the bat.

+5  A: 

This is not related to generics. Switch statement for enum in java can only use values of that particular enum, thus it's prohibited to actually specify enum name. This should work:

switch(event.getId()) {
   case SELECTED:
         l.selected(event);
         break;
   case SELECTION_CLEARED:
         l.unselect(event);
         break;
}

Update: Ok, here's an actual code (which I had to change a little bit to get it to compile with no dependencies) that I've copy / pasted, compiled and ran - no errors:

AbstractEvent.java

public abstract class AbstractEvent<S, T extends Enum<T>> {
    private S src;
    private T id;

    public AbstractEvent(S src, T id) {
        this.src = src;
        this.id = id;
    }

    public S getSource() {
        return src;
    }

    public T getId() {
        return id;
    }
}

MyEvent.java

public class MyEvent extends AbstractEvent<String, MyEvent.Type> {
    public enum Type { SELECTED, SELECTION_CLEARED };

    public MyEvent(String src, Type t) {
        super(src, t);
    }
}

Test.java

public class Test {
  public static void main(String[] args) {
      fireEvent(new MyEvent("MyClass.myMethod", MyEvent.Type.SELECTED));
  }

  private static void fireEvent(MyEvent event) {
        switch(event.getId()) {
            case SELECTED:
                System.out.println("SELECTED");
                break;
            case SELECTION_CLEARED:
                System.out.println("UNSELECTED");
                break;
         }
    }
}

This compiles and runs under Java 1.5 just fine. What am I missing here?

ChssPly76
No, I'm afraid that doesn't work. If that were the case then it would be complaining about my case : lines and not my event.getId() in a switch statement. Besides, if I override getId() in my concrete class and only return the super's getId() it all works.
Chris Boran
I apologize: I typed in the example wrong. You are of course correct about the qualification of the case labels, however the real problem that is puzzling me is why event.getId() isn't a valid switch-able parameter.
Chris Boran
It most certainly works for me with your code - no overrides. Now if `fireEvent()` was declared with `AbstractEvent` as parameter type, that would have been a different story.
ChssPly76
Nope, fireEvent() uses the concrete class.
Chris Boran
I don't know... I'm using JDK 1.6, but I don't imagine there should be a difference...
Chris Boran
+1  A: 
Yishai
This would only matter if we have a raw reference to `AbstractEvent`.
notnoop
That was what I was thinking - that the auto-boxing isn't working for some reason - but WHY is the important question.
Chris Boran
Nope, fireEvent only works with the concrete MyEvent class. No one is dealing with the AbstractEvent - it is just a convenience for me.
Chris Boran
@Yishai, it's true that types are erased at runtime and the `getName()` would return Enum, but at compile time, the compiler has access to the parameterized types.
notnoop
@Yishai - ah, but you've tested the whole different issue. Chris's code _explicitly_ passes MyEvent.Type instance to his MyEvent constructor, so his switch works just fine.
ChssPly76
+3  A: 

Yishai is right, and the magic phrase is "covariant return types" which is new as of Java 5.0 -- you can't switch on Enum, but you can switch on your Type class which extends Enum. The methods in AbstractEvent that are inherited by MyEvent are subject to type erasure. By overriding it, you're redirecting the result of getId() towards your Type class in a way that Java can handle at run-time.

Jason S
This is great - I missed this feature of Java5 entirely thanks for the pointer!
Chris Boran
After going back and combing through the code, I hadn't noticed that I'd defined a second getId() method in my abstract class (obviously it was more complex than the example I'd posted here). It was this second getId() that returned an Enum<T> was being called by the switch statement and messing me up!
Chris Boran
A: 

I just tried this (copy-pasted your code) and I can't duplicate a compiler error.

public abstract class AbstractEvent<S, T extends Enum<T>>
{
    private S src;
    private T id;

    public AbstractEvent(S src, T id)
    {
        this.src = src;
        this.id = id;
    }

    public S getSource()
    {
        return src;
    }

    public T getId()
    {
        return id;
    }
}

and

public class MyEvent extends AbstractEvent<String, MyEvent.Type>
{

    public enum Type
    {
     SELECTED, SELECTION_CLEARED
    };

    public MyEvent( String src, Type t )
    {
     super( src, t );
    }


}

and

public class TestMain
{
    protected void fireEvent( MyEvent event )
    {
     switch ( event.getId() )
     {
      case SELECTED:
      break;
      case SELECTION_CLEARED:
      break;
     }
    }
}
Trevor Harrison
+1  A: 

Works for me.

Complete cut-out-and-paste test program:

enum MyEnum {
    A, B
}
class Abstract<E extends Enum<E>> {
    private final E e;
    public Abstract(E e) {
        this.e = e;
    }
    public E get() {
        return e;
    }
}
class Derived extends Abstract<MyEnum> {
    public Derived() {
        super(MyEnum.A);
    }
    public static int sw(Derived derived) {
        switch (derived.get()) {
            case A: return 1;
            default: return 342;
        }
    }
}

Are you using some peculiar compiler?

Tom Hawtin - tackline
I'm using a Java 6 compiler (r14) through Eclipse
Chris Boran