Solved Announcing Glowstone++: an open source Minecraft server implementation of the Spigot-Bukkit 1.8 API

Discussion in 'General Help' started by deathcap, Apr 19, 2015.

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


    Hello Bukkit users,

    Most server owners I assume are using either the Spigot or CraftBukkit implementations of the Bukkit API. However due to the nature of the Bukkit API design it is possible for other server implementations to be created, completely independent from the official Minecraft server, while still offering compatibility with many Bukkit plugins. Pore and Glowstone are two such alternatives. In this post I would like to bring your attention to a new third alternative on the block, Glowstone++.

    Based on the original open source Glowstone server by SpaceManiac, Glowstone++'s main differentiating feature is that it targets Spigot's update to the Bukkit API for 1.8.x. Full compatibility with most Spigot plugins is the goal. The project is also more experimental, in that many proposed changes from contributors are accepted without extensive thorough review (an "open open source" model, inspired by voxel-engine, you can read about in the contribution guidelines where it is likened to a "wiki").

    Why would anyone use Glowstone++ over Spigot? One word: opensource.

    Like Glowstone (and the C++ MC-Server), Glowstone++ is fully open source - the implementation is MIT, and the API (Bukkit-based) is GPL. No proprietary code is present, since it is not an addon to Minecraft. This does have a downside, in that it is not as feature-complete, so if you want a fully-working complete server then Glowstone++ may not be ready for you yet, but if you're adventurous and like open source want to help out, come check it out. I also posted some Q&A on Reddit with more details if anyone is interested. Server administrators, players, and developers are welcome, to submit bug reports feature requests and pull requests. All further information is available in the project's GitHub page:


    P.S.: I posted this in the "Bukkit Alternatives" section, hope that's okay
  2. Offline

    timtower Administrator Administrator Moderator

    @deathcap And what is the big difference between Glowstone and Glowstone++ ?
  3. @timtower So far as I can tell the only difference is that Glowstone++ is a bit lazier, rather than updating to 1.8 themselves :p
    timtower likes this.
  4. Offline


    Hi timtower,

    The biggest difference is:

    Glowstone added their own 1.8.x APIs not necessarily compatible Spigot 1.8.x plugins.
    Glowstone++ aims to reconcile these API differences to improve Spigot 1.8.x+ plugin interoperability.

    There was effort required to port Glowstone to Spigot's APIs, at least the following changes:

    • New non-deprecated block targeting API methods
    • Changing blocks without physics updates
    • Command-sendable entities
    • Banner API, completely different between Glowstone/Spigot
    • Item frame rotations API
    • Rabbit types API
    • Enchanting inventory API
    • Particles API, another large Glowstone/Spigot API difference
    • New material enum names
    • Guava 17 instead of 10 (somewhat surprisingly this is part of the API)

    Also, Glowstone++ has additional features not yet in Glowstone (also updated to target Spigot API). Most of these came from proposed changes to Glowstone, which were accepted in Glowstone++, not yet Glowstone but this delta may shrink over time as Glowstone development continues. Regardless, the current feature difference in Glowstone++ build 201 vs Glowstone build 123 is support for at least:

    • Sophisticated overworld generation
    • Structure spawning and saving
    • Biome grid generation
    • Biome decorators
    • Bone meal
    • Flower pots
    • Noteblocks
    • Jukeboxes
    • Double chests
    • Crop growth
    • Item frames
    • Enchantments
    • Beds
    • Cauldrons
    • Suffocation
    • Liquid physics
    • Lightning
    • Various fixes
  5. Well sure, but you honestly can't expect me to believe that it's more effort to port to Spigot than to update to 1.8, right?
    timtower likes this.
  6. Offline


    Is it possible that you could make it run older Spigot plugins?
  7. Offline


    Wouldn't be able to say, Glowstone++ branched from Glowstone after the 1.8 update so it wasn't an effort I was involved in. It does look like updating took a substantial amount of work. Glowstone++ build's on Glowstone's update, sharing the same basic 1.8 implementation, but the difference being how plugin's access it: through a Spigot 1.8.3-compatible API interface.

    Almost all the code from Glowstone made it into Glowstone++, it is mostly a "superset". Comparable to how C++ is mostly a superset of C, which is where the naming was inspired from. But like C++ is not a strict superset of C, there are some necessary removals, mainly where both Glowstone and Spigot had an incompatible API for the same feature. In these instances, I opted to support the Spigot API instead, with the aim is supporting more Spigot plugins.

    Why target supporting Spigot plugins? The basic idea is to make plugin developer's lives easier, and by extension server administrator's. As a plugin developer, if you want to add some cool new 1.8+ features in your plugin, you had to choose whether to develop against the Spigot API or the Glowstone API. If you pick the Spigot API, then the functionality won't necessarily work on Glowstone, but if you pick the Glowstone API then they won't necessarily work on Spigot.

    One way around this is to limit your plugin to only rely on API common to both platforms, which primarily means the 1.7.x API. But what if you want to harness the new 1.8+ features?? Then you're stuck in this dilemma. It technically may be possible to compile against both Spigot and Glowstone APIs, and then at runtime try to determine what platform you are on and switch to the appropriate APIs accordingly, but that's a lot of work to put on plugin developers' shoulders. If they are willing to do it, sweet, but it is certainly not something I would expect all developers to be willing to do. Most likely, they'll pick one and stick with it, and probably for now Spigot since it is more well-supported and feature-complete at the moment.

    The dichotomy also introduces complexities for server admins. Plugins for 1.7 will probably work, but once you venture into 1.8 and beyond territory, the path splits off and there is now the concept of 1.8-Glowstone and 1.8-Spigot plugins. How do you tell the difference, and where do you find each types? BukkitDev lets plugin developers specify the version their plugin works on, but now there is another level of granularity to take into account.

    This is where Glowstone++ comes in. The goal is to fully support the Spigot API, with the intention of having your 1.8.x-Spigot plugins work on Glowstone++. Disclaimer, we're not quite 100% there yet, but the Spigot-Bukkit API is fully included (but may not be fully implemented), as are some Spigot API patches. Pardon my crude ASCII art, but this diagram tries to show the API re-unification I'm talking about:

            Bukkit 1.7.x
                /  \
              /    \
              /      \
            /        \
            /          \
          |            |
          |            |
      Spigot 1.8.x    Glowkit 1.8.x
          |            |
          |            |
          |\          /|
          | \        / |
          ... \      / ...
              \    /
                \  /
          Glowstone++ 1.8.x
    Maybe, is there a specific plugin you have in mind? Try it out if you get a chance, file an issue on GitHub if it does not work and I can look at it. There are a couple known incompatibilities I'm aware of so far.

    First is a few API removals, such as Material.LOCKED_CHEST. This should not matter since the material has been deprecated and non-existant for more than a year, probably no plugin should be using it.

    More significant, is the transition from Guava 10 (in 1.7 and earlier) to Guava 17 (in 1.8). If a plugin uses Guava it might not be compatible. You can try on Glowstone to see since it does use the earlier Guava, if so you may be better off using it for now, since Glowstone++ has switched to Guava 17 for Spigot plugin compatibility. Nonetheless, in theory it is possible to bundle both versions of Guava and have an option to choose which version is used by each plugin, I have a plan for this but haven't coded it up yet, but it could be pushed up in priority if there is a demonstrable need for it. Would be a fun feature to add, too. I would have to hook into the plugin classloader somehow and rewrite the Guava API calls. If anyone really wants to see this feature added please let me know!

    Lastly, a more intractable problem is plugins not only using the Spigot/Bukkit APIs. That is, accessing the Minecraft server internals directly. Since Glowstone++ (and Glowstone) are not built on the official Minecraft server, all of the internals are completely different, so these kinds of plugins won't find what they are looking for. Unfortunately, there is not much we can do here. If there is a specific plugin requiring a small subset of the server internals, maybe it can be implemented, feel free to file issues if you have specific issues with plugins and aren't sure, but in general the best approach here is for the required functionality to be added to the Spigot API, so it can then trickle down to Glowstone++ where it can be implemented without raw access to the internal server classes.

    Anyways, good Q&A we've got going on here, if anyone has any further questions about the Glowstone++ project feel free to ask, I'll check this thread periodically. Also a reminder, more information is available on GitHub at, including the commit history showing what precisely was added, builds you can download and run, and the issue tracker for reviewing and reporting bugs/features.
Thread Status:
Not open for further replies.

Share This Page