care to expand?
Printable View
Well what I'm doing is per-server event manager. Each event manager holds just a list of listeners, can be used to dispatch events and register more listeners.
About Listeners
To make a class a listener you must implement EventListener.
To listen for any event you need to specify a method with a single argument, being the event you are listening for, as well as annotating the method with @HandlesEventCode:public class Example implements EventListener {
}
You need to register the listener to an event manager also.Code:public class Example implements EventListener {
@HandlesEvent
public void onExampleEvent(ExampleEvent event) {
// do stuff
}
}
EventsCode:getServer().getEventManager().registerListener(listener);
To make an event all you need to do is extend Event.
To dispatch the event just useCode:public class ExampleEvent extends Event {
}
There is no need to register events. All listeners of the event manager will handle the event.Code:getServer().getEventManager().dispatchEvent(new ExampleEvent());
Plugins
Basically top-level implementation of a listener. Plugins are simpler with my system than in Bukkit.
To make a plugin all you need to do is implement Plugin.
If you want to do something when the plugin is enabled, there is an event for that. Just handle PluginRegisterEvent.Code:public class ExamplePlugin implements Plugin {
}
Now you might be wondering how the API knows what class to use as the Plugin implementation. This is done in the meta information inside a file called plugin.ini.Code:public class ExamplePlugin implements Plugin {
@HandlesEvent
public void onRegister(PluginRegisterEvent event) {
// do stuff
}
}
Performance Issue?Code:name: ExamplePlugin
description: This is just an example plugin...
version: 1.0
main: exampleplugin.ExamplePlugin
There is extremely low performance impact due to the way I'm caching listener events. Instead of having to use heavy reflection iteration each time an event is dispatched, upon listener loading it performs these iterations and maps them in a registry to the listener.
don't you think it would be smarter just to have the plugin be a jar in a certain directory then use reflection at runtime to go through the directory? you already do essentially the same exact thing as bukkit, why not take a lesson from the way they load plugins too? reduce the redundancy.
well you'd kind of have to. it doesn't make sense for it to go through and do a ton of reflection each time you wanted to raise an event lol.Quote:
Performance Issue?
There is extremely low performance impact due to the way I'm caching listener events. Instead of having to use heavy reflection iteration each time an event is dispatched, upon listener loading it performs these iterations and maps them in a registry to the listener.
The plugins are in a JAR in the plugins directory... Also, looping through all classes and checking if they implement Plugin is a SUPER BAD idea. What if multiple classes implement Plugin? They will too. Some people have old versions and variations, as well as library extensions that are resources of other plugins.
As for "have to" that's not that case at all. Bukkit doesn't do it my way either.
it's not a bad idea at all... it accomplishes the exact same goal without redundancy of declaring something twice for no reason. if multiple classes implement a plugin then it's safe to assume that they're plugins? i don't understand the question. you only do it once on start or whenever you want to "rebuild" the plugins. so i don't really get where you're getting the "it's a super bad idea" vibe from.
"they will too" what? also the thing that will kill an api is inability to innovate or change. plugins are implementing the api, not the other way around. you shouldn't worry about plugins not being compatible.
It does in a majority of ways.Quote:
As for "have to" that's not that case at all. Bukkit doesn't do it my way either.
No it doesn't. It's not safe to assume that the author intended to launch that plugin... Also I don't think you understand what I was explaining because you said something completely irrelevant to my reasoning provided in the former.
Loading all implementations of Plugin in a archive instantly kills innovation. People can no longer have dummy implementations for quick and easy plugin modifications. I never said plugins wouldn't be compatible, so I don't understand where you're getting that from either.
And it's obviously not required. There is likely a better way to load listeners. Your persistence again only leads me to believe that you didn't understand what I explained... Please reread the last post, and reread this post... to make sure you understand everything.
yeah it is you already explicitly mark methods that handle events with annotations. why not do the same thing to plugins that should/shouldn't run? depending on how you want to implement it. it doesn't make sense for you to have to explicitly state "oh you don't know about this class but this is a plugin, run it, i promise it implements plugin" where you could just roll through the jar files and find classes that match that specific criteria.
@Plugin(name = "Some Plugin", version = 1.0) is a better solution tbqh.
No it doesn't. Yes they can, even though I have no idea why they'd want to do that.Quote:
Loading all implementations of Plugin in a archive instantly kills innovation. People can no longer have dummy implementations for quick and easy plugin modifications. I never said plugins wouldn't be compatible, so I don't understand where you're getting that from either.
"Some people have old versions" you even bringing up anything relating to "old versions" implies that there's going to/might be changes that makes "old versions" (of something) even relevant to bring up in this discussion.
well it's kind of hard for you to tell me that i should understand everything you said previously when you left a fragment of a sentence in there, "They will too." they will too what? so no i don't understand everything you said. i get your point but you're not being very open to the idea that there's still better ways you could do some things and i'm just suggesting some and helping you work out the problems with those suggested implementations. you don't have to treat me like i'm retarded and don't understand what's going on, because i do.Quote:
And it's obviously not required. There is likely a better way to load listeners. Your persistence again only leads me to believe that you didn't understand what I explained... Please reread the last post, and reread this post... to make sure you understand everything.
I think that including performance beyond the primary of going for walks, discussing, products, things, battle fundamentals, multi-player, NPCs, outfitting, etc. right into a hosting server is ridiculous. Any content beyond primary performance should be through an API that way you aren't stomach ache the hosting server.