CraftBukkit.jar vs. Bukkit.jar?

ShadowDrakken I amaware of that, but then the API (Bukkit) should provide methods for all native method equivalents without reducing performance. Other than that, method calls do slightly affect performance. For example, this is slower:

Code:

e.setX(e.getX() + 60);

Than:

Code:

e.x += 60;

But usually this difference isn't noticeable.

 

I don't quite understand the need for Bukkit API tbh. With only a few exceptions, it looks like all it does is wrap CraftBukkit API in the exact same classes, but with less functionality.

 

Not true at all.

CraftBukkit is a wrapper around net.minecraft.server classes, not an API. Bukkit is a published API, with documentation, and a "promise" that published functionality won't change between releases without prior deprecation. CraftBukkit is an implementation of the Bukkit API (the only implementation right now, although Spout's Bukkit bridge will presumably be another implementation in the near future). The implementation details could change at any time, so if you use it directly, you need to be prepared for plugin breakage between releases.

Granted, there are times when you might need to use CraftBukkit and/or NMS calls directly when Bukkit doesn't do what you need, but it's not accurate to say that "Bukkit is just CraftBukkit with less functionality".

 

desht You are absolutely right. I'll try to give my point of view with it:

At the first releases of Minecraft, a new 'Minecraft Server' was included. Just like how client modding started, people wanted to mod the server. hMod was the first server software that tried this, compare it to the current Modloader for the client.

Later on CraftBukkit came to be. They decided to build a protective layer around the native server, which plugin developers can call without the risk of breaking things. They added an 'API', The 'Bukkit API', not only to hide unimportant functions and classes, but also to allow other server software to implement Bukkit.

This never happened. The fact right now is that there is no alternative Bukkit-API implementing software available, maybe it is in the making, you don't know. So what lets you from using CraftBukkit instead? It's not like the Bukkit API is consistent itself, think of the event system change which now breaks a lot of older plugins.

So yes, implementing the API instead of CraftBukkit does not give you more functionality, it will give you a safety net at a cost of less abilities. I definitely recommend plugin developers that just start making plugins to use Bukkit and NOT CraftBukkit. I am used to all the native coding gibberish and can understand everything just fine, that is something called 'experience', but when you are just starting it will be far too hard to understand. Stick with the Bukkit API and it's events and tasks to aid you, you can always decide to use CraftBukkit afterwards once you understand it more thoroughly.

But, now that server software is heavily segregating into different directions, using Bukkit over CraftBukkit is a wise decision. It will make sure that any future server software implementing Bukkit will run your plugin, which makes your plugin very versatile. I've used 'Colorme' from build 1080 till 1938, I mean, if that isn't versatile I don't know what is! CraftBukkit is something you can jump into when you feel that Bukkit doesn't do for you.

In my case, I have added a third option. I added native wrapper classes in a separate library (BKCommonLib) which takes care of some of the 'dangerous' calls:

• Obtaining entities, tile entities and block data quickly
• Messing around with packets
• Using native calls to use craft recipes, get furnace recipes and others
• Transfer items using net.minecraft.server.ItemStack and IInventory classes to improve performance
• Functions to safely teleport entities cross worlds

I strongly recommend you try to put native calls into separate functions, instead of copy-pasting the same code everywhere. IF something breaks, it is a lot simpler to fix.

 

This does bring up an interesting topic... I've seen a few plugins that the developer was able to make a single version of their plugin work for several different versions of the Bukkit API where the API had changed significantly from one version to the next... how is this accomplished? The only way I've been able to figure out is writing separate versions of the plugin... I think being able to have a single JAR handle multiple Bukkit versions would be handy for situations like we have right now where 1.1 is solid and 1.2 is far from usable but still deserves plugin attention.