Is Bukkit actually good?

Discussion in 'Spigot Discussion' started by Abstraction, May 24, 2016.

  1. Disclaimer: I will refer to Bukkit and Spigot and being the same thing, While it is technically incorrect, in this context, the differences are irrelevant.

    The server platform

    Bukkit has been working as a stable server platform for the past couple of years, and has been able to maintain stability between Minecraft versions fairly well. But with that being said I think it is about time we look into new and better alternatives, or start creating a update and more optimized version of Bukkit, to slowly shift towards an improved environment. Surely Bukkit has been the to-go choice for Minecraft servers for many years, and for good reasons. But to me Bukkit seems like a project that is becoming increasingly outdated, with core functionality that cannot be updated without breaking older plugins.

    The developers

    Another obvious issue (to me at least) surrounding Bukkit, is its developer community and the people who frequent it. This is not necessarily directed at the people who are developing the Bukkit platform, but rather the people developing plugin using Bukkit API. Throughout my relatively short time around here on SpigotMC, I consistently see an obvious lack of knowledge of the Java language, causing a lot of unnecessary questions, and sometimes even scenarios of people straight up asking for code, even when a valid solution has been given. Don't get me wrong, everybody starts somewhere, but starting somewhere that requires prior knowledge of dependent subject is not a good place to start. But I honestly think the amount of unknowledgeable people is really hurting the development part of the Bukkit community.

    Standardized libraries & handling
    Note: When I refer to libraries, that also includes various utilities, APIs, and frameworks.

    While this does not appear to me as a problem in particular, the process of adding libraries seems to be a quite cumbersome, and often also impractical. A lot of plugins are not entirely standalone, and requires other plugins or libraries to function. That is all fair and square, but the problem arises when the dependency need to be distributed. You will often find people who shade the dependencies into their plugin JAR, this sometimes even include the dependent plugins.

    This may not be a big problem, but it is bad practice, and it would make a lot more sense to be able to add designated resources, that can also be shared among other plugins dependent on the same resource. It would however also have to be integrated with the plugin system, in such a way you can easily set up dependency for these resources, and not only plugins.

    Along with this, I think adding standardized APIs for common tasks, which are officially supported and recommend by Bukkit/Spigot could be a good idea, if implemented in a proper and moderate manner. I can see pros with this idea, but just as many cons. The idea of a standardized permission management system, which has been thoroughly designed and implemented, to me seems like a good idea, and it would make it easier for developer to create compatible plugins, since there is only one central API they have to implement, rather than implementing support for multiple different permission management system. Now this is just an example, and a rather bad one to be honest, since the Player#hasPermission renders some of this obsolete, but my point still stands.

    Another thing that I'd also like to see introduced, would be a system to encourage plugin developers to implement more flexibility in their, by providing an easy and standardized system to allow their plugin(s) to seamlessly accept and handle plugin extensions. I know a lot of APIs and plugin our there could definitely benefit from a feature such as thing, as it would also provide more control of the plugin for the end user.

    The event system

    Throughout my time developing clients and various other project, I've worked with a couple of different event systems. However my general experience with Bukkit's is displeasing, and I find the syntax odd, and a bit confusing to work with.

    I won't to in-depth with all of the things that I think could be improved with the event system. However, I'll make an incomprehensive list of some things that can be done to improved the speed of the system system, preventing duplicated code in the event implementations, and suggestions to improved the ease of use.
    • Changed the name of the priorities - they're confusing and unclear, especially if you don't read the JavaDoc
    • The EventHandler#ignoreCancelled is also slightly confusing and unclear, if you don't read the JavaDoc
    • Create a abstract Cancellable event implementation to prevent a lot of events with duplicated code
    • Remove the Listener interface - it's completely obsolete, and serves no legitimate purpose by the looks of it
    • Create a centralized event and listener management class, instead of event handling their own listeners
    • I do not understand why do register event listeners through the plugin management classes
    • Utilize the Flyweight pattern to minimize the instantiation load. (Only for safe/synchronized events)
    • Various small adjustments to improve the overall speed of the event system. (can be at least twice as fact)

    These suggestions are from a rough look at the portion in the Bukkit API, and I could easily keep going for longer before moving only the portion in the CraftBukkit implementation. Generally what I'm saying is, since the event system is such a crucial part of the platform, it would greatly benefit both server owners, and developers to implement some of the suggestions. I'm not trying to trash it, I just think there are a couple of things that could - and should be improved.

    My conclusion

    Now of course this isn't a full review of what I think is good, and what I think is bad about Bukkit. This thread is most meant to highlight a few of the things I've like added or updated in Bukkit, and the whole community could benefit from, so it is going to appear to be more negative than positive.

    I think the same concept that applies to PayPal, also applies to Bukkit - It isn't popular because of the service, it's popular because of its large userbase. But that's just my opinion, and comparing PayPal to Bukkit is not a fair or reasonable comparison.

    All in all, Bukkit is a functional server platform, with a large verity of plugins for server owners to easily create a server, with the features they want. However, I think Bukkit suffers a from being an outdated platform, with no ability to update, without breaking old plugins, and requiring current plugin developers to update their plugins. Some of the things I've suggest can indeed be updated and improved, but some core functionality is beyond what Bukkit can do, without break backwards compatibility, and outside the scope of Spigot.

    Ask me any question regarding any of my opinions on anything related to Bukkit, and I'll try answer it the best to my abilities.
    • Agree Agree x 5
    • Winner Winner x 2
    • Informative Informative x 1
  2. Tldr someone?
    • Agree Agree x 2
  3. TL;DR. No, it isn't any good and you should by no means use it on a production server.
    • Winner Winner x 2
    • Like Like x 1
    • Agree Agree x 1
    • Optimistic Optimistic x 1
  4. I have to agree on some parts. My real problem with Bukkit is that for so many things, we need to use NMS for. A lot of the things such as Titles, action bars, boss bars (I think some of those were fixed in 1.9) and much, much more require NMS and packet manipulation to achieve them.
  5. Wont most public plugins fail if you use something different?
  6. At the time of writing the post, I just couldn't be bothered to add anything about Bukkit's lack of functionality, but I might add something about it later, since that's another thing that really annoys me about Bukkit. The platform is extremely limited, and they highly discourage people using 'NMS', and genuinely don't care if people's code break on version updates, since it's not within the scope of Bukkit or Spigot.
  7. Read the post? All your answers is in there. There is even a small section dedicated to your kind.
  8. Alright, I asked sweepy for a Tldr, shoulda read the post before commenting xD
  9. Also "your kind" wot
  10. What? Bukkit plugins are compatible with Spigot.
    • Optimistic Optimistic x 1
  11. Tux


    I agree with most of this, but the current alternatives are also suboptimal.

    The most serious project in this regard is Sponge, but it has a lot of problems. The data API does not gracefully handle many cases, has poor error handling, and has generally bad API design. The data API infects much of Sponge, so a fault in the data API ruins many Sponge use cases. Sponge also has unnecessarily high amounts of garbage creation that (believe it or not) is worse than even Spigot. Sponge also suffers from a chronic lack of server owners using it. Virtually everyone is using Spigot or the old Bukkit.
    • Agree Agree x 1
  12. Sponge seems like a really promising project, but now it just seems too bloated to really be an optimized functional server platform. However from what I've seen, Sponge seems like a good, and it seems decently well covered.
  13. MiniDigger


    all these optionals in sponge that no one realy uses and no one realy cares about makes all sponge code looks to bloated...
    I was one of the first members that singed up on the forums, I was in irc when it all started. But the project kinda lost it for me.
    • Agree Agree x 1
  14. How about cross-plugin compatibility, one can't just redo super perms a second time!
    Below a couple of thinkable directions (not necessarily the thing):
    • A more powerful generic services API. Think of multiple generic input types and multiple generic output types. Likely wrapped via a broker object, that allows efficient setting/getting of generic input/output, with concepts of factory/overriding of factory including reference implementations and pooling support, so plugins needn't depend on building vs. other plugins so much, but still can have very efficient ways of wrapping the broker objects within their own methods, with little overhead on modern/near-future JIT compilers.
    • Reliable ways to override other plugins permissions without touching their attachments. Currently it's a random thing what applies, if several permission attachments have the same permission referenced. One can't reliably undo a permission temporarily, if it's set by another plugin. One way would be to have a priority for either attachments or for permissions. Easiest compatible way: sort attachments by priority, higher priority overrides, default is 0 (pos/neg possible).
    • Craft events such that plugins know when another plugin has overridden something, keep original data accessible.
    • More cases / registry questions. Think more of cross-plugin compatibility in general, wehn doing things.
      • e.g. event priority ... some issues can be tackled by a more powerful generic registry, but sometimes the only way of compatibility is wrapping around another plugins event, how to register earlier than EventPriority.LOWEST taken by another plugin that you possibly depend on .... ugly... either have an extra priority (int) or perhaps allow to inspect registered listeners and either insert yours at a certain position via an iterator or add a way to reliably have it sorted before another listener by referencing it somehow, e.g. via a context object passed with registration)
      • How about post event tasks, running as soon as possible after effects of the event have been applied, Potentially a complex topic, as sometimes events may fire more or less nested, or several events are fired one after the other, such as with vehicle moving (update + move), or subsequent effects can be many and can not really controlled. Technically you could demand a post-event-task-list to be passed to events, so it can be shared between several events firing (then again one never really knows what happened between... shifty + open topic, could have a context object collecting tasks set by plugins as well as all indication about all events that fired since/nested, e.g. classes). Another option is to register the post event task to run next time on-tick tasks are run in certain cases (run before the on-tick tasks), but that leaves much more of a gap then. Potentially hard to guarantee effects of such a feature, however it would enable plugins to timely check effects of events, without relying on things like "maybe the block will have been placed there". Performance-wise this has near zero impact, implementation-wise... possibly not the most practical to add thing.
    • Also make odd server side behavior accessible, at least allow plugins to know what happens/happened (cancelled player move event leads to a packet sent silently, something moved 'wrongly' or 'too quickly'... add a useful teleport reason for players and add events for vehicles so plugins know (vehicle positions get altered with player inside without plugins noticing), in fact since vehicle are under control of the player, make their moving accessible, allow to set new target efficiently. Instead of silently skipping PlayerMoveEventS due to some threshold checks, make things available always or add a player position update event for the case of not firing a PlayerMoveEvent (no need to alter internals much, no plugins breaking, do allow cancel/setTo), efficiency is still possible if you skip this for the case no listeners are registered. And so on...

    (I don't fully agree with all mentioned points being of the same importance/relevance, but i can't take so much time to answer now.)
    • Like Like x 1
  15. MiniDigger


    there are many strange things about bukkit. Its nearly 6 (!) years old ( so the api itself had some serious growth to it. the team behind it changed a few times. currently the main team consitsts of two guys. they can't fix these problems. And I don't think they would want to.
    working with minecraft was never a smooth experience, and It will never be. The server code is just so.... yeah probably now that better then I do.

    Sponge aimed to fix this. But I don't think they found a good solution. Thier api feels bloated.
  16. Same here :(

    Btw, I don't think "it's confusing if you don't read the JavaDocs" is a reasonable argument. Isn't it obvious that you have to read the JavaDocs? And standardized libraries: There is one standardized library, the Bukkit API, which should be extended instead of creating tons of NMS utils.

    If there's a problem with Bukkit, then it's its lack of features and its lack of support for Forge since Cauldron died. Maybe we need a Forge implementation of Bukkit like SpongeForge.
    • Agree Agree x 1
  17. I know you should be able to assume people will read the JavaDoc, but the majority of the people around here do not, which creates a problematic situation. This is related to the same issue I described about a lot of people having little to no understanding of Java.

    I disagree about Bukkit being our only standardized library. Yes, Bukkit should be extended upon, but adding common functionality such as economy is not a preferred situation, since it could quick bloat the standard version, with a lot of features server owners to do need, and it can sometimes make it harder for developers who wants to write and use their own system.
  18. I don't get why these newbies are "hurting the development part of the Bukkit community". Neither do my plugins get worse because noobs ask questions, nor does the Bukkit API. We still use it for decent projects.
    I get what you mean, but economy is a considerably bad example as there's a de facto standard library: Vault.
  19. Tux


    Optionals are a good practice. For instance, they allow you to tell the difference between "no value" and a value, something that is much harder to do with "possibly-null" variables. They are also very useful with Java 8's pseudo-functional syntactic sugar.
  20. To me they're bloating the development section with questions that could easily be solved with minimal programming knowledge, or within 5 minutes of a Google search.

    If Vault is collectively agreed upon as the standard plugin for handling economy, wouldn't be it better if it was promoted as being the standardized economy plugin. I can definitely see both pros and cons with this.