[Explanation] Why the Sponge implementation hasn't been released yet (but the API is)

I’ve been seeing a lot of people asking about running a Sponge server, especially since the 1.0 release of the API.

Note: If you’re not sure what an API is, or how it’s different from an implementation, you should see this thread.

If you’ve have (especially on IRC), you’ve probably seen one of these messages:

  • The API is now at version 1.0 but is definitely not feature complete. We ask developers to work with it and assist us in creating version 1.1. The official Forge-based implementation has no eta at this time.

  • The Sponge server implementation isn’t ready or released yet! However, the API has been released, and that is what developers use to create the server implementation and to make Sponge based plugins. Don’t ask about a server release date.

There’s many reasons no ETA exists (not an exhaustive list):

  • It’s hard to accurately estimate the time to write something, especially when the API you’re implementing keeps changing
  • It’s better to do it well in more time that do it badly in less time.

However, these reasons, and the actual development process, can feel frustratingly opaque if you’re not a developer.

In this post, I’ll attempt to explain why it takes longer to implement the API than to create it.

Writing an API

As you (probably) know, an API only describes an interface that other code (in this case, plugins) use. It doesn’t contain any code to implement it.

This means that contributing to the API doesn’t require any knowledge of the Minecrat codebase.

Writing the implementation

The implementation is a different matter.

First, you’re not creating the interface for plugins - you’re writing code to make the existing methods actually do something. This means that you can’t start implementing part of the API until it’s been decided on. While a certain part of the API might be just about finished, the work of implementing it is only just beginning.

Second, the official implementation is written on top of Forge (technically, it’s a coremod), which is built on top of (patched) Vanilla code. This means that implementer have to first figure out how an entirely different codebase does something, before they can begin hooking it to the API.

Third, unlike the API, what you’re writing doesn’t always get used like normal Java code. It gets injected into the Vanilla server using a variety of complex tricks, which don’t always work the way you expect. What might have been simple to write in the API can become quite complex in the implementation, due to the way the Vanilla code is structured.

The work being done on the Forge implementation isn’t private - you can see it on Github, and compile and run it yourself.

However - remember that the Forge implementation is not ready. Most methods won’t work, or will throw an exception.

Don’t expect anything to work until its released.

Other implementations

The point of the API is to separate the interface plugins use from the code that implement the interface. The forge implementation might be official, but it’s not the only one.

Some other implementations include:

  • Granite
  • Glowstone - planned, but work on implementing the API hasn’t been started in the main repository.

There are sure to be many others I don’t know of - reply to this thread, and I’ll add them to the list.


I hope this post was informative, and helped to clear up some of the questions regarding the implementation.

10 Likes

The ASO crowd probably will be to lazy to read this.

1 Like

Quite a few people have been working on a Glowstone implementation, including the folks over at LapisBlue with ShinySponge.