Event Listener and Publisher
I've got a few small points about this code and then I have some other points regarding your design. I'll try to discuss your design in perspective to game-development (where I am completely inexperienced) and in perspective to (the more common Java area) business applications.

Names and Design choices

Your class (and interface) names seem to come from a C# dominated development perspective to me. Prefixing I to interfaces smells .NET to me. Whenever I am developing Java I try to keep interfaces without clutter and then usually suffix the implementation classes if that is required.

Next thing that somewhat bit me was the A prefix for your abstract class. I am not a great friend of abstract classes anyways. I try to avoid them wherever I can and prefer interfaces and "Default[...]"-implementations. I have been going better with that since abstract classes often end up constraining the use of the "Interface" too much.

I'd rather write a little duplicate code than creating a central abstract class that limits my possibilities when using the interface. Instead I'll create a simple, if not "minimalistic" interface. Multiple minimalistic interfaces can be combined to allow more complex uses, but since your use-case is clear ....

Anyways this is enough of abstract talk about personal preferences in regards to language constructs. Let's give your code a thorough examination.

Code Analysis:

What instantly struck me when I first saw your code was the lack of explicit visibility modifiers on your AEventPublisher and your IEventListener. Neither of these needs the other for context so much that you'd have to put them into the same classfile.

The next thing I saw was your incredibly long generics specification:


AEventPublisher&lt;Model, Publisher extends AEventPublisher&lt;Model, ?&gt;&gt;



This seems to be a lot of unnecessary work to me. Also you're needlessly restricting the possibilities you have, when using your publishing mechanism. IMO the following would be sufficient:

AEventPublisher&lt;Model, P extends Publisher&gt;


Then I saw how you store listeners. You have a private List&lt;...&gt;

You have two choices when creating an abstract class like this. Either you allow "full" access to your fields (by making them protected) or you close yourself off completely.

Following the Open/Closed principle (Open to extension, Closed to modification) I definitely suggest the latter. You did that not even bad, but I have two small nitpicks to make.


Make your "immutable" fields really immutable:

private final List&lt;...&gt;


is better than just a private list.
Make use of "common" language features:
You're currently initializing your List in the constructor, and (again) repeat the clunky generics definition. Save yourself from that and use the Java 7 feature: the diamond operator. It makes overly clunky generics (as java has them) easier by shortcircuiting redundancy:

private final List&lt;IEventListener&lt;Model, Publisher&gt;&gt; listeners = new ArrayList&lt;&gt;();



Next up is how you handle publishing. The problem you're describing when you implemented your publish method is rooted in how you restricted yourself when starting directly with an abstract class, instead of taking yourself the room of creating an interface for a Publisher. Consider the following:

public interface Publisher&lt;E&gt; {
    public void subscribe(IEventListener&lt;E, Publisher&lt;E&gt;&gt; listener);
    public void unsubscribe(IEventListener&lt;E, Publisher&lt;E&gt;&gt; listener);
    public void publish(E sender);
}


This greatly simplifies your generics declarations and nestings and additionally resolves the conflict you had internally.

If you'd sacrifice a little "flexibility" (which you problably won't need anyways, more later), you could even make your IEventListener much simpler and completely get rid of the second type-parameter you introduced. 

In general your solution seems overengineered for the problem. Which brings me to my next point.

Design Discussion:

In general your design is somewhat over the top. You try to keep flexibility and allow substitions (which is in principle a good thing) in places where it's overly complicating your source-code and detrimental to code-readability and hurtful to your actual flexibility.

Coming from a "GameDevelopment-Perspective"

You will never need a Listener, which can listen to multiple different model classes, and if against all odds you need it, an abstract class or interface to group these model-classes is the simplest call to make. You went too far in your idealistic approach to be "open to everything". This is something you should strive to do, but not at the cost of simplicity and effectiveness. 

This is true to both gamedevelopment and business applications.

In addition to that, gamedevelopment is a often heavily performance-reliant environment, and let me tell you, overcomplicated generics and backreferencing interfaces are not something to make the JVM run faster. 

I also have no idea why you'd need or want the Listener to obtain a reference to the publisher. From what I see with my nonexistant experience you could "directly" subscribe to your model, which would then pass a reference to itself to it's listener. But that makes the whole Model-circus in your code moot, and defeats the point of a separate Publisher (which I don't see in the first place).

In general, separating the Publisher from the "published" is somewhat overkill and most probably sign of an underlying design mistake. I can not imagine a situation where I'd have to get a reference to a Publisher, before publishing something. You're again: overly complicating a simple matter. 

Because in the end, what is this all about?

You want to bring data from one end to another, depending on certain conditions. And there's already a lot of existing solutions (beginning with Observable and ending god knows where) in the Java world for that.

Which is also what makes this model somewhat problematic from a business perspective. The simplicity of existing solutions beats your idea easily. The practical use-case is from my point of view missing. 

Overall you reinvented the wheel, but not as wheel, but as a polygon. Your solution to "Get data from A to B on demand" suffers from clunkyness in use. It's a bumpy ride and I don't know how I'd make it better without landing at some place that's already polished for use.

Final overview:

When I reviewed your code I copied it to a local project in my IDE. A few changes and a little headscratching later I was at the state of code that follows.

From what your use-case seems to be, that should be completely sufficient:

public interface Publisher&lt;E&gt; {
    public void subscribe(IEventListener&lt;E&gt; listener);
    public void unsubscribe(IEventListener&lt;E&gt; listener);
    public void publish(E sender);
}




public interface IEventListener&lt;E&gt; {
    public void actionPerformed(Publisher&lt;E&gt; publisher, E sender);
}




public class DefaultEventPublisher&lt;Model&gt; implements Publisher&lt;Model&gt; {
    private final ArrayList&lt;IEventListener&lt;Model&gt;&gt; listeners = new ArrayList&lt;&gt;();

    @Override
    public void subscribe(IEventListener&lt;Model&gt; listener) {
        listeners.add(listener);
    }

    @Override
    public void unsubscribe(IEventListener&lt;Model&gt; listener) {
        listeners.remove(listener);
    }

    @Override
    public void publish(Model sender) {
        for (IEventListener listener : listeners) {
            listener.actionPerformed(this, sender);
        }
    }
}


And since you also had an example of a usecase:

public class ButtonEventPublisher 
       extends DefaultEventPublisher&lt;ButtonEventPublisher.ButtonEvent&gt; {
    public static class ButtonEvent {}
}


This code should in essence be able to do the same things that your code can do, but is IMO much simpler. Let me know what you think ;)