Re: [aspectj-users] Another generics bug?

[Andy Clement <andrew.clement@xxxxxxxxx>]

Oh no! Posts from you about generics always worry me :)

I'm trying to craft a failing test program so I can fix whatever you
are seeing, but my minimal case here is fine:

--- Code.aj
public class Code {
  public static void main(String []argv) {
    new MySelectAction().setSelected(new User());
    new MySelectAction().setSelected("abc");
  }
}

class User {}

class MySelectAction extends SelectAction {
  public void setSelected(User u) {}
}

class SelectAction<A,B> { }

aspect X {
  public void SelectAction<T, I>.setSelectedId(I id) {}
  public void SelectAction<T, I>.setSelected(T object) {
    I id = null;
    setSelectedId(id);
  }
}
----

What am I doing differently to you?  In my case the ITDs cause the
setSelectedId(Object) method to be added to SelectAction and so no
bridge method is needed in the MySelectAction.  Do you have type
parameter bounds somewhere that I don't have above?

cheers,
Andy

2009/6/11 Dave Whittaker <dave@xxxxxxxxxx>:
> I think I am seeing a bug caused by intertypes which introduce 2 generic
> methods that call each other, but I am a little fuzzy on why it's happening.
>  Maybe someone on the list can help me clarify what is going on here and if
> it is, indeed, an aspectJ issue.
>
> I have an intertype declaration that includes these two methods:
>
>
>        public void SelectAction<T, I>.setSelectedId(I id) {
>                selectedId = id;
>                T entity = null;
>                if(id != null){
>                        entity = H2Lookup.em().find(getManagedClass(), id);
>                        setSelected(entity);
>                }
>                if(!EqualityUtils.equal(getSelected(), entity))
>                        setSelected(entity);
>        }
>
>
>        public void SelectAction<T, I>.setSelected(T object) {
>                this.selected = object;
>                I id = object == null ? null : findIdValue(object);
>                if(!EqualityUtils.equal(getSelectedId(), id))
>                        setSelectedId(id);
>        }
>
> Then I have a class the implements SelectAction and overrides the
> setSelected method.  The problem is, when setSelectedId is called I end up
> with an AbstractMethodError
>
> Caused by: java.lang.AbstractMethodError:
> mhc.users.AdminUserAction.setSelected(Ljava/lang/Object;)V
>        at
> h2.actions.SelectActionAspect.ajc$interMethodDispatch1$h2_actions_SelectActionAspect$h2_actions_SelectAction$setSele
> cted(SelectActionAspect.aj)
>        at
> h2.actions.SelectActionAspect.ajc$interMethod$h2_actions_SelectActionAspect$h2_actions_SelectAction$setSelectedId(Se
> lectActionAspect.aj:44)
>        at mhc.users.AdminUserAction.setSelectedId(AdminUserAction.java:1)
>        ... 87 more
>
> My guess here, based on my limited understanding of how generics work behind
> the scenes, is that in the usual case aspectJ will add methods for
> setSelectedId(Object id) and setSelected(Object object) that will "dispatch"
> the call to the proper method signature based on the parameters type.  It
> seems that when I override setSelected and give it a non-generic parameter
> though, say setSelected(User user), then aspectJ ignores that method and
> does not create a version that takes an Object parameter.  Since the
> setSelectedId method that was added by aspectJ expects there will be a
> generic form of setSelected that will take an Object parameter, that call
> fails.
>
> That sound about right?  If so, I'm not sure what the fix would be.  I
> suppose I can work around the problem by changing my version of setSelected
> to setSelected(Object user) and then casting to the proper type.  It's be
> nice if this worked without the hack though.
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>