First of all, thank you for your thoughts on my project. As Pohl points out, the anonymous handler-implementations are chosen by design, and are in my opinion very well suited for these types of situations. But I'm thinking maybe you're not bothered by the anonymous implementations, but by the fact that classes like the Event-interface and the GenericEventHandler classes are made as public inner classes within the EventManager class? My thought was that, as they are so tightly coupled to the use of the EventManager class, they might as well be defined inside the EventManager as inner classes. However, if you have any reasons for why they should be defined elsewhere, I'd apprechiate your opinions.
As to your concerns regarding the static use of the EventManger, I can apprechiate your point of view. I'll put it on my todo-list for the next version.
The static methods need to go. That's just bad form, because of unit tests, or the ability to use the decorator pattern to enhance an EventManager (or instrument one), or to make an EventManager injectable via something like Guice.
I'm not sure why you're bothered by inner classes, though. Anonymous inner classes are a very common way to write event-handling code in java, especially if the handler needs to capture some enclosing scope for later use.
As to your concerns regarding the static use of the EventManger, I can apprechiate your point of view. I'll put it on my todo-list for the next version.