Why are there different Listener types?

I am trying to write an omniscient and omnipotent plugin, and a list of events this plugin needs to process changes in realtime, possibly even when processing some another event. I had to write several different classes overriding Listener for every event type to work around such feature. This has severely complicated architecture of my plugin and almost drove me insane.
I ran into createExecutor and discovered that a single org.bukkit.event.Event object is dispersed into various event types before being pushed to a certain *Listener converted from org.bukkit.event.Listener taken as a parameter to PluginManager's registerEvent.
This leaves me to a question: is there any detour to stop bukkit from doing unnecessary work and leave all Event handling to me?
tl;dr - need Event, not eg. PlayerJoinEvent, coming into my Listener, not eg. PlayerListener.
P.S. Java has interfaces, why don't you use them?

 

> Implying they're not being used.
> Bukkit is pretty much a collection of interfaces and enums.

 

Not where I need them. All Listeners are implemented as classes derived from org.bukkit.event.Listener (which is actually an interface, yes) and I can't actually understand why.

 

@apiocera Interfaces can ONLY have abstract methods that you have to override. Thus, if the *Listener-classes would be interfaces, you would have to override every single onXXX-method for the interface - if you registered your event or not.
It's kinda unfortunate that you can't use a single class for different event-types. But it would be even more of a hassle to always override tons of methods just to listen to one single event.

 

Or there would be one interface per event.