Foreign Function Interfaces in the Bukkit API

First, the big question: Are there plans to add FFI to the Bukkit API/specification?

One of the big promises of Bukkit is the freedom of plugin authors to code towards an API rather than a specific server. This frees up authors from having to know the details of the server they are working with, and also allows API-level testing of servers. However, the Bukkit specification appears to have no FFI at all, which effectively prevents it from being used with any server which is not written in Java.

http://wiki.vg/Server_List is the Minecraft Coalition's list of custom servers. One (Lightstone) is written in Java; however, the bulk of them are written in flavors of C (C, C++, C#) or Python. In fact, the two servers recommended by the Coalition for people looking for custom servers are Bravo and Mineserver, which are written in Python and C++ respectively. Neither of them have any reasonable way to support Bukkit as long as Bukkit's interfaces are Java-only.

What are the opinions of the Bukkit community on this matter?

~ C.

 

actually Mineserver could easily got with the Bukkit Specifications by using the JNI (Java Native Interface) to hook into the existing java based plugins and also then allow for plugins to be written in C++

 

I'm going to try my best to parse your reply.

JNI is not suitable for several reasons. The first reason is that it only provides a bridge to languages supported by JNI, which effectively means C. The set of types exposed by JNI is remarkably limited and imposes sharp limits on the amount of data that can be exchanged between plugins and their host. For example, JNI has no standard mechanism for passing C-style strings (const char*) in and out of the JVM, and requires the host (!) to make sure that jstrings are used instead. Getting the entire set of complex types defined by Bukkit in and out of JNI sounds quite a bit like pulling shark teeth.

Another reason that JNI is not okay is that JNI is highly cumbersome to host. In the Python community, we use the terms "extend" and "embed" to refer to the separate practices of calling C from Python and calling Python from C. Extending is always easier than embedding, and JNI makes embedding very painful.

Now, as for plugins written in C++... Mineserver already has that, in the form of its own plugin API. Your claim that Bukkit plugins could be written in C++ falls kind of flat because the Bukkit API specification has no provisions for C++. In fact, the specification is not language-neutral, but is written in Java and documented only in code. There is no way to take that API and make it language-neutral due to the various quirks of Java's primitive types; it would have to be written explicitly as a neutral document. (This is not to say that it couldn't be done given the right choice of language; however, at this point in time, C is the only reasonable language for doing that.)

Edit: The forum decided to double up my post. Not sure why.
[MERGETIME="1299646498"][/MERGETIME]
Are there any other thoughts on this? Is this the wrong forum or venue for this sort of discussion?

 

IMHO, Mineserver support should definitely be a priority. I've been watching that project for some time, and C++ is significantly faster than Java, which could allow servers to break the 1k player barrier.

I'm not an expert on cross-communication with programming languages, but I know that the JNI is going to be the least slow of any of the options. I believe the only real alternative is using network sockets to transmit packets.

 

Languages aren't fast; algorithms are fast. MINA can be used to write speedy Java servers.

Are there any useful tools for simulating player load? It's hard to find even a dozen guinea pigs, let alone a thousand.

Sure, JNI will be fast, but speed might not matter if there's no good way to pass the data across the bridge. It's moot at this point since there's no actual specification for it. Doing anything across a socket is even further away; last time I checked, Bukkit wasn't even committed to adding InfiniCraft support, and this would be even more work.

 

well realistically, if you don't mind not having the Java plugins already made work for the system and only allow C++ plugins (like CraftBukkit only allows Java plugins), then you don't have to worry about it

and about C+ being faster than java, if you use the same algorithm (or as close to as possible) C++ usually wins, but not by much and this return has been diminishing over time, especially when the code is re-run as it goes through the JIT now

about JNI data swapping across the bridge, i forgot how to do it (as i only read the manual, no code) and need to get the pdf back on the laptop so i can read it

 

This is the entirety of my complaint and query, actually. Bukkit is currently only specified in Java. My question could be viewed as, "When will Bukkit add an appropriate API for other languages, and how does Bukkit plan to offer cross-language services to its plugin authors?" If there were a Bukkit API specified in C, C#, Python, and Erlang, then this would no longer be an issue. That's a possible solution, but not the only one. I'm trying to determine what the big plan is, that's all.