New Event System

Some of you may have noticed that we have introduced a new way of handling events in Bukkit. Those of you that haven't noticed sure will when you next open your IDE and find a bunch of big yellow deprecation warnings
Anyway lets start with the old way of using listeners, or more specifically how I do it in all of my projects.

Code:java

 package com.md_5.noclip.listeners;
 
import org.bukkit.Bukkit;
import org.bukkit.event.Event;
import org.bukkit.event.EventHandler;
import org.bukkit.event.EventPriority;
import org.bukkit.event.player.PlayerJoinEvent;
import org.bukkit.event.player.PlayerListener;
 
public class NoClipPlayerListener extends PlayerListener{
 
public NoClipPlayerListener() {
Bukkit.getServer().getPluginManager().registerEvent(Event.Type.PLAYER_JOIN, this, Event.Priority.Normal, plugin);
}
@Override
public void onPlayerJoin(final PlayerJoinEvent event) {
}
}
 

Looking at the code we have a listening class that extends PlayerListener, we then have a constructor which registers the events and some methods to execute the events. The way I use this class is to simply call: new NoClipPlayerListener() : In my onEnable() method. But now how do we replace this with the new event system you ask? Well lets take a look at the same method again:

Code:java

package com.md_5.noclip.listeners;
 
import org.bukkit.Bukkit;
import org.bukkit.event.EventHandler;
import org.bukkit.event.EventPriority;
import org.bukkit.event.Listener;
import org.bukkit.event.player.PlayerJoinEvent;
 
public class NoClipPlayerListener implements Listener {
 
public NoClipPlayerListener() {
Bukkit.getServer().getPluginManager().registerEvents(this, plugin);
}
 
@EventHandler(priority = EventPriority.LOW)
public void onPlayerJoin(final PlayerJoinEvent event) {
}
}
 

Well aside from the lack of big warnings several things have changed. The first being we no longer extend PlayerListener, instead all Listeners, no matter what their type implement Listener. Now instead of registering each event individually in the constructor we can simply call registerEvents() and get all the events we use registered for us. Another bonus of this system is you can name your methods anything you like. Now how do we actually go about registering these new events? Well instead of using the @Override tag to replace the listening methods you add a new tag:
@EventHandler();
The syntax goes like this:

Code:

    @EventHandler(event = NAMEOFEVENT.class, priority = EventPriority.WHATPRIORITY)

So say I wanted to add a new event, say playermove it is as simple as adding this method:

Code:java

 @EventHandler(priority = EventPriority.LOW)
public void whenThePlayerMoves(final PlayerMoveEvent event) {
}
 

Notice here how I can call the method anything I like. Using these new listeners in your plugin is exactly the same as before: new MYListener();

I hope this is a brief tutorial on how to upgrade your plugins to the new event system.

 

Snapshots? No. Maven is not a build tool.
Or do you mean the repo contents? They should be getting updated everytime you start eclipse (by default). Propably you need to repull the git repo, if you are using maven with git.

 

Never mind. I don't know why i even bother trying sometimes.

 

Why shouldn't you try? Are you already aware of this?

 

What?

EDIT:

Clean and Build your project to update the (local) maven repo

 

Irony being that the pull request came from Spout.

 

Cool, thank ya. This makes things ALOT better and easier!

 

Strange. I keep getting "IncompleteAnnotationException: org.bukkit.event.EventHandler missing element event". Im using the latest build from here:
http://forums.bukkit.org/threads/jenkins-temporarily-unavailable.55174/#post-916651

Show Spoiler Hide Spoiler

Code:

17:13:31 [SCHWERWIEGEND] Error occurred while enabling CHDistantFarm v1.04 (Is i
t up to date?): org.bukkit.event.EventHandler missing element event
java.lang.annotation.IncompleteAnnotationException: org.bukkit.event.EventHandle
r missing element event
        at sun.reflect.annotation.AnnotationInvocationHandler.invoke(Unknown Sou
rce)
        at $Proxy12.event(Unknown Source)
        at org.bukkit.plugin.java.JavaPluginLoader.createRegisteredListeners(Jav
aPluginLoader.java:990)
        at org.bukkit.plugin.SimplePluginManager.registerEvents(SimplePluginMana
ger.java:432)
        at me.zacherl.distantfarm.DistantFarm.onEnable(DistantFarm.java:443)
        at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:232)
        at org.bukkit.plugin.java.JavaPluginLoader.enablePlugin(JavaPluginLoader
.java:1034)
        at org.bukkit.plugin.SimplePluginManager.enablePlugin(SimplePluginManage
r.java:252)
        at org.bukkit.craftbukkit.CraftServer.loadPlugin(CraftServer.java:190)
        at org.bukkit.craftbukkit.CraftServer.enablePlugins(CraftServer.java:173
)
        at net.minecraft.server.MinecraftServer.t(MinecraftServer.java:356)
        at net.minecraft.server.MinecraftServer.a(MinecraftServer.java:343)
        at net.minecraft.server.MinecraftServer.init(MinecraftServer.java:175)
        at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:407)
        at net.minecraft.server.ThreadServerApplication.run(SourceFile:465)

It seems like the api is updated, but the latest build still needs the deprecated event annotation parameter.

md_5: Any suggestions?

 

Any information on doing custom events with this?

 

http://wiki.bukkit.org/Introduction_to_the_New_Event_System#Creating_Custom_Events

 

I can't figure out how to fetch variables in this new version, because this works:

Code:

@EventHandler
public void playerChat(PlayerChatEvent event) {
//some code   
}

But this doesn't:

Code:

@EventHandler
public void playerChat(PlayerChatEvent event, Player player) {
//some code   
}

[SEVERE] Wrong method arguments used for event type registered

 

Thanks, that works. Sexy, this new event system.

 

You need to get the objects you need from the event. For example, for player events you'd do event.getPlayer() to get the player.

 

Does onCommand still work the same way?

 

Love, you! :3

 

It seems to work, but the bukkit doesn't do any actions with the config file(s)?
The config doesn't work at all, its generating the folder, and writtes the nodes into it, but does not do any actions with them in-game..

EDIT: I got it.. bukkit doesn't support the if (plugin.config.getBoolean(...), true) anylonger..
You have to type, if (plugin.getConfig().getBoolean(...), true) now..

EDIT 2: wow, that seems to stop working to.. wtf is going on?

EDIT 3: AND NOW ITS WORKING AGAIN, WTH IS GOING ON BUKKIT?!

 

Okay, I got a problem with the new Eventsystem.

What I've done with the last Eventsystem:

1. My plugin reads the event-priority out of a config (this helps to be compatible to other plugins)
2. Now it registers the events with the given priority

With the new system, I can't find a way to do this without using Java-Reflections.. Did I miss anything, or is there simply no way to read the Priorities out of a config and change the level with the given priority?

Using reflections should NOT be the goal of the new system :/

 

To be honest I liked the old system.

 

GeMoschen: The only way i see, is registering a method for each priority. But i see no valid reason for reading the priorities out of a config file.

 

The reason is, that serverowners can adjust the event-level if they have compatibility-problems with other plugins.

Not every plugin-dev is using "event.isCancelled()" (although they should) and this 'causes the incompatibilty sometimes. When you save the level in a config, you can adjust it.

 

This new system seem's good, but I think I'll keep to the old one for now (Seeing as it still works)...

 

I'll put up a bleeding branch with a registration option that forces all listeners in a class that will be registered to a specific priority some time in the next few days. That should resolve your issue once it is merged.

 

This is GREAT!

 

I find myself loving this new event system.

 

Forcing an entire class to the same priority seems like a workaround rather than a proper solution. So instead of being able to merge a variety of events with a variety of run-time defined priorities, I need to create separate classes once again. This seems to be walking away from a primary goal of the redesign.

While I do like the simplicity of this new system, annotations seem to be a form of meta-coding and this problem underlines my concern. Why were annotations chosen and not simply a standard method like before but with the local instance handler tracking approach? Is all this being overthought? Are annotations simply being used because of their perceived novelty, or is there some other benefit to them that I'm overlooking?

 

I know a lot of people that are a bit irritated about this change, but personally I like the new system. It'll be nice to not have to make 10-line classes just to cancel a single event.

 

Wow I love this new feature, thanks Afforess and Spout for making this.

Now that the new RB is out I was finally able to throw away the old junk, and instead of having 5 classes, I know have just 2

This is best for TrainCarts, since I can now add new events very easily without supplying custom listener classes or other weird shenanigans.

ONE question.

Could you allow this annotation to be added in the class body?

Code:

@EventHandler(priority = EventPriority.MONITOR)
public class PlayerListener implements Listener {

I get this error:

Or is this simply not possible to do?

 

Should the old system still work perfectly fine?

 

It's depracted and will be removed by time, It's recommended to change to the new system immediately.

 

Reflection allows analytical analysis of metadata for classes, methods, and fields. The event priority is metadata to the event callback method, therefore using reflection is logical, not wrong.

I agree. The solution is to leave the system as is.

Annotations provide metadata to classes, methods and fields. This is a logical extension of such a system.

 

Afforess - Any method's parameters are metadata to the method. We could just define annotations for all method parameters and use annotations exclusively for everything with that logic.

Metadata for coding seems a role that fits much better for compiler type interactions, not for the needs of a Plugin Developer's plugin. It's logical for things like @Override or @Deprecated as it assists the developer's efforts within the IDE. Forcing a metadata dependency for code logic seems counter intuitive at the minimum.

I'm still not clear why a more conventional programming pattern isn't being employed here. I know Java is not the most concise when it comes to a callback design. My assumption is this annotation approach is being used to circumvent the standard approach of creating an individual class for each event callback. Is there no standard design pattern for event callbacks that would be appropriate here?

All said and done creating individual callback classes for each event really shouldn't be considered as bad as most people seem to think it is. I even started programming Java myself trying to avoid creating classes wherever possible. I've since learned that is akin to trying to make as few methods as possible. Both are ignorant approachs to well-designed object oriented programming.

I don't mean to stir the pot too much here, but at the same time if a new system is being tested, no time like the present to question it in detail.