Generics support for beans hierarchy

I've submitted PR #793 early, but it looks like my intentions wasn't clear enough.
Let's assume:

@EBean
abstract class BeanA<N extends Number> {

    @Background
    void method(List<N> list) {
    }

}

@EBean
class BeanB extends BeanA<Double> {

}

Now it generates:

class BeanB_ extends BeanB {
    @Override
    public void method(final List<N> a) {...}
}

But should:

class BeanB_ extends BeanB {
    @Override
    public void method(final List<N> a) {...}
}

Another case is:

@EBean
public abstract class BeanA<T> {
}

and

@EBean
public class BeanB<T> extends BeanA<T> {
}

Right now it breaks generated class BeanB_.

I've also fixed <? super A> wildcard problem, discussed in #838 (but is not the rare case for me, actually).
I've used some durty hacks to make it work. The main reason for that is limitations of the code model.
That PR is not up-to-date, but, if you want, I could make it so.

<? super A> was discussed actually in #858.

Oh, sorry, typo.

Actually, there wasn't any limitations, except <? super A> problem. They were only in my mind.
I'll make PR with cleaned up and up-to-date code.

Looks like I'll be able to hack around <? extends A&B> situations, should I?

Not in this PR. It'll be simplier to handle <? extends A&B> when this PR will be merged

Ok.
The idea is similar with JSuperWildcard - if you are ok with such hacks, it should be just a peace of cake.

Merged

Navigation Menu

Repository navigation

Generics support for beans hierarchy #865

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Generics support for beans hierarchy #865

Description

Activity

WonderCsabo commented on Jan 7, 2014

Artyomcool commented on Jan 7, 2014

Artyomcool commented on Jan 9, 2014

Artyomcool commented on Jan 9, 2014

DayS commented on Jan 10, 2014

Artyomcool commented on Jan 10, 2014

DayS commented on Jan 11, 2014

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions