CraftBukkit.jar vs. Bukkit.jar?

Discussion in 'Plugin Development' started by fuggles7, Feb 12, 2012.

Thread Status:
Not open for further replies.
  1. Offline

    fuggles7

    It appears that both of these jars have different items and classes to them. I use the Javadocs for Bukkit.jar, but have not been able to find any reference whatsoever for CraftBukkit.jar. Since there are many classes I would like to be able to use in CraftBukkit.jar, does anyone know if Javadocs exist for it?
     
  2. Bukkit.jar is for Plugin developement, Craftbukkit.jar is or running the server.
     
  3. Offline

    fuggles7

    I am aware of that. But you see the Bukkit.jar package does not include the different types of network packets which can be sent to players, making you able to create a fakequit, without Spout. So for some stuff I do, it will not build unless I add CraftBukkit.jar to the Java Build Path Libraries.
     
  4. Offline

    Daniel Heppner

    CraftBukkit contains Bukkit plus some extras. But if you develop against CraftBukkit, your plugin won't be compatible with server software that has Bukkit but isn't CraftBukkit.
     
  5. Offline

    Jozeth

    I use the normal Craftbukkit for referenced library and give it the attach the source from Bukkit's Bukkit repo on Git.com...
     
  6. What do you mean ?
     
  7. Offline

    Daniel Heppner

    I meant CraftBukkit.
     
  8. Bukkit is the API (Which plugins should generally build against), and CraftBukkit is the implementation, using the original Minecraft server (Vanilla) as it's base. Only build against CraftBukkit if you need a Craft/Minecraft specific class (Example: You need to modify a value in CraftServer, which you can't do with just Bukkit)
     
  9. Offline

    Jade

    Plugins should build against bukkit.jar
    YOU as a server owner/host should use CraftBukkit.jar.
    Bukkit.jar = Bukkit, nothing more, nothing less.
    CraftBukkit.jar= Commands, etc.
     
  10. No, I was asking what do you mean by:
    ???
     
  11. Offline

    Daniel Heppner

    CraftBukkit isn't the only server software that implements Bukkit. There's a few other server mods that can run Bukkit plugins, but they won't be able to run CraftBukkit plugins (plugins that are built against CraftBukkit, not Bukkit, and use CraftBukkit methods)
     
  12. I see, I didn't know that... but how are those platforms named ?
     
  13. Offline

    Atomic Fusion

    Named? They can be named whateverso they wish. Spout (the server software, not the Bukkit plugin) will sortof implement Bukkit, I believe.
     
  14. Nope, will just have a bridge to convert from Bukkit to SpoutAPI.
     
  15. Yes, their names, Daniel said there are other platforms that support bukkit plugins, just like craftbukkit... I was asking what are they called because I'm interested in them... or did I understand wrong ?
     
  16. Offline

    Atomic Fusion

    Isn't this bridge (won't it be a Spout plugin?) implementing the Bukkit API?
    No, it was I who did not understand.
     
  17. No, converting (as much of) a plugin to SpoutAPI
     
  18. What if I don't need a Craft/Minecraft specific class and still build against CraftBukkit?
     
  19. Then your stupid ;)
    Being serious, you can, but it's not recommended because the chance that it breaks is alot higher. Also, you HAVE to build against Bukkit because you need to extend JavaPlugin, etc
     
  20. Offline

    Atomic Fusion

    Then you're denying others the chance to use your plugin on server software other than Craftbukkit, without a reason.
     
  21. I'm still curious WHAT are the other server softwares apart from CraftBukkit.
    I can't find anything concrete on google because anything related to "Bukkit" sends me here.
     
  22. Offline

    bergerkiller

    I stopped referencing Bukkit in my projects. Why?
    The API does not offer me enough support to go around. Using the API is significanly slower than using the native calls directly, and many things are not possible through the API. For example, packet sending is completely impossible through the API. Why? I have no idea, because packets are a general server thing. Why no implementation for it? The sendBlockChange is 1% of the packet sending.

    The wrapper lacks support for:
    And I can go on a bit more. BTW: The entire Bukkit library is included in CraftBukkit. So referencing both libraries is not needed and will only cause confusion.

    Maybe if you write logging plugins and/or plugins that change some blocks based on signs or something, the BUkkit wrapper may do. But for me the wrapper is not-d0ne.
     
    hqSparx and mushroomhostage like this.
  23. Offline

    Atomic Fusion

    Not to suggest that Bukkit is not, but is Craftbukkit not subject to great change, pretty much every MC update? What about consolidating all of the packet sending into a plugin built against Craftbukkit, and then calling that plugin? Or even just submit a patch to Bukkit? That way there is abstraction and the chance for other hypothetical sever softwares to use your plugin. As for speed, with time, will Craftbukkit's Bukkit implementation not improve?

    There was one called Glowstone, but I think that Spout may be taking that over.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: May 24, 2016
  24. Canary and Tekkit MP came to my mind.
     
  25. Offline

    ZNickq

    Canary doesn't implement bukkit...tekkit does though!

    Actually, BukkitBrige will implement Bukkit...
     
  26. ZNickq Digi asked for general server software asides Bukkit... but oh well :)
     
  27. Offline

    bergerkiller

    Atomic Fusion
    - changes every update: Yes, because the team spends more time on the wrapper than fixing up the native coding
    - separate plugin? Sure, but there are too many packet related requirements that need to be inserted in the native coding and can't be done through a plugin (the listener for example, requires hackish reflection)
    - submit a patch? I stopped doing that, they don't want drastic changes
    - speed will not and never improve. No matter how you much you fix, you will never make it better than calling the native coding. A wrapper adds 1-2 layers of functions before the thing you want to do.

    Very simple example.
    The location class. If you want to change the entity location, you need to use the location class. This class uses up 3*8 + 2*4 + 4 + 5*4 + 4 = 24 + 8 + 4 + 20 + 4 = 60 bytes of data per new instance. A new one is constructed every time getLocation() is called. Instead, this class should be referenced back in the entity, so when you change the location class, it changes it directly. (so no need to call teleport either)

    And there are a lot of these examples. Notch used raw variables everywhere, but Bukkit decided to give each and every variable a separate function.

    Functions slow down. It is simple as that. When I replaced the recursive explosion function with one simple while loop without function calls, the time spent on exploding went from 50 ms to 2 ms. Of course, it was called quite a lot. But with 3K entities and lots of calls to getLocation you can imagine it slowing down.

    So, what I propose for a better server:
    - less calls to functions
    - more use of raw variables instead of wrapper functions
    - less hidden/obfuscated variables spreaded around
    - STOP THE REQUIREMENT OF GETHANDLE() (seriously)
    - when you change an entity, you change the entity, and not a hidden native entity behind tonnes of functions
    - No more duplicated classes (nms.ItemStack, CraftItemStack, Bukkit.ItemStack)

    Spout server is on it's way doing just that. And when Spout server is finished and allows the use of plugins, I will definitely use that instead. No offence, Bukkit, you did a nice job, but you will never match software that acts as a real server instead of covering up the minecraft server.
     
  28. Offline

    Atomic Fusion

    bergerkiller
    But isn't that just the point of an API? Yes, Craftbukkit may be slow, by necessity as a wrapper around vanilla, but if you code to the Bukkit API, the couldn't it be dropped into a faster setting (such as Spout)?
     
  29. Offline

    bergerkiller

    Atomic Fusion Will be very hard, but not impossible. Then they will have to get rid of the native entities (EntityMinecart) and convert all code in those classes into the Bukkit (CraftBukkit) equivalent: Minecart

    Then the object you get returned as entity (Minecart) is the actual Minecart, and not a wrapper with a handle to the EntityMinecart.

    Only problem is that you can't make an API for loose variables. You will end up having to extend the Minecraft abstract class in CraftMinecart, instead of implementing the interface.

    Code:
    entityPlayer.locY += 2.6;
    Is a lot simpler and faster than:
    Code:
    Location loc = player.getLocation();
    loc.setY(loc.getY() + 2.6);
    player.teleport(loc);
    Isn't it? Downside is that you can't listen for events (teleport event) this way. So wrapper functions are probably inevitable. However, getting rid of the 'wrapper around wrapper' framework would benefit a lot of people.

    These are wrappers versus the type they represent:
    CraftMinecart -> net.minecraft.server.EntityMinecart
    CraftWorld -> net.minecraft.server.WorldServer
    CraftServer -> net.minecraft.server.MinecraftServer (also ServerConfigurationManager)
    ItemStack -> CraftItemStack -> net.minecraft.server.ItemStack -> net.minecraft.server.Item
    CraftInventory -> IInventory implementing classes
    CraftChunk -> net.minecraft.server.Chunk
    CraftBlockState -> net.minecraft.server.TileEntity (in most cases)

    And probably some more. (including materials, block types, block lists and even the Block class is a wrapper around a chunk and a set of coordinates. Material classes are wrappers around a byte, generated using the Material. (material.getNewData(byte data))

    Some things I find useful, such as the material and block classes, but the CraftWorld/WorldServer relationship is a bit worthless in my opinion...
     
    fromgate and mushroomhostage like this.
  30. Offline

    ShadowDrakken

    bergerkiller exposing a class's members is poor OOP practice. They should always be declared private/protected and mutators used instead, that way anything talking to the class is forced to talk the same way and all calculations needed against that member are done correctly and consistently. If you expose members that affect other parts of the class, and that member gets changed, the rest of the class is unaware of the change and can severely break things.
     
Thread Status:
Not open for further replies.

Share This Page