Common mistakes while coding a Bukkit plugin In this article I hope to cover a bunch of mistakes that I see frequently either in the Bukkit Plugin Development forum, the #bukkitdev IRC channel, or in plugins that I help folks write in other places on the net. All of these issues or mistakes can occur on a plugin that compiles fine. Building with Java 7 or Java 8 While technically not a problem for your own computer, you need to keep in mind that plenty of Bukkit servers are running Java 6. You need to compile with Java 6 in order for them to use it (Java 7/8 users can use something built on 6). Minecraft, Bukkit and CraftBukkit are built for Java 6. Go grab Java JDK 6 and tell whatever you use to compile to use that instead! Denying Console from using commands that it could otherwise use I see a lot of plugins that, for commands not affecting the sender, deny anyone that isn’t a Player from using them. If your command can operate with console using it, why not allow it? Checking for instanceof Player prevents execution from console as well as other situations such as IRC plugins executing commands remotely. Not registering events or commands You’ve created your amazing event listener full of methods for catching all sorts of events. But none of them are firing! You created an onCommand method or a couple CommandExecutors for your commands but they aren’t triggering! Looks like you forgot to register your events and commands. Event registration is documented here, while command registration is documented here. Putting other plugins classes (or entire plugins) in your jar I’ve seen several developers, in the hope of ensuring their users also get the plugin theirs uses, include plugins or pieces of plugins in their code. First, this is often a license violation. More importantly this can breakthat other plugin and is a bad practice. Only include your own code (or code used with permission under license) in your plugins. Including CraftBukkit in your plugin This is certainly an impressive feat, but I’ve seen it in probably half a dozen submissions. Don’t include CraftBukkit (or Bukkit) in your plugin! Importing individual permissions or chat plugins for chat formatting (prefix/suffix) You create your awesome chat plugin that needs to get prefix/suffix data from other plugins. You release it and it works fine for 5 months. In those 5 months a brand new awesome prefix plugin comes out and you have to now edit in support, or one of the plugins you supported completely changes its internals. Your plugin needs constant updates to keep track of all the other plugins you’re checking just for some simple data they all provide. The plugin Vault was created precisely to avoid this scenario. Vault handles keeping track of all these systems for you and is an easy dependency to have your users install. They just drop it in and go. Done! On your end, you now have a single plugin to support whose API isn’t going to change. Using Vault to check if a Player has a permission On the opposite side of the Vault issue, is people who believe that using Vault to check a permission is the ideal way to go. I’ve seen plugins require Vault just for checking has(Player,permission). Fun fact: Vault’s permission check just calls Bukkit’s methods. There is zero benefit in using Vault to check a permission. Just call player.hasPermission(permission) and your life is far easier! Using non-threadsafe methods in Async events (AsyncPlayerPreloginEvent, AsyncPlayerChatEvent) or Async tasks (scheduler) Async events are not running as part of the minecraft thread. A good way of judging if you should be calling a method from an async event is asking yourself “does this method change or query something in-game?” If the answer is yes, you probably shouldn’t be doing it. Permission checks are not safe, as are many other methods. Pretty much, if you’re not certain, don’t. Examples of valid ways to deal with various async features: AsyncChat: Format the chat with your formatter. Use cached information about the player to format the chat. AsyncPrelogin: Query an external database (async is perfect for this, the delay in reply won’t lag the server) to determine if that username or IP can join. Async task: Update a MySQL database with new data. IO operations (writing non-config files, MySQL queries, metrics, update checks, etc) on the main thread IO calls can take a long time. Running your MySQL query or update check from the main thread can very quickly slow down the server in a highly noticeable way. Instead, schedule these actions to run in an async task. Need to do something that isn't thread-safe (see above) as a result of an IO operation? Schedule a sync task from that async task when it's time to react! Utilizing static variables for information sharing There are many reasons this is generally a poor decision. Here is a great description of some reasons: http://stackoverflow.com/questions/7026507/why-are-static-variables-considered-evil/7084473#7084473 Storing constants statically is great. Storing temporary information is less so. Storing Player objects Store their UUID instead. Solve about 50 problems this way. You are welcome to comment below and even suggest additions. EDIT by Moderator: merged posts, please use the edit button instead of double posting.