For Minecraft+Forge 1.8 we can detect whether the user is a Forge user before we get the mod list, due to the changes to the initial (not FML|HS) handshake that are now made (which is for vanilla client support). Bungee can exploit this to detect FML clients from the off, but it still does not tell us what the mod list is. Thus, creating this API method for users who simply need to know whether the user is connected via FML is no longer a duplication of the getModList api method.
This commit allows BungeeCord to support Minecraft clients both of versions 1.7.x and of 1.8.x. There should be no breakages to any other support, however following their deprecation and uselessness within 1.8, the Tab list APIs have been removed.
Please report any issues to GitHub and be sure to mention client, server and BungeeCord versions.
When used with an appropriate server jar (such as multi protocol Spigot), this will allow clients of many versions to concurrently be connected to the same set of servers.
This commit adds the basis for the intergration of a security manager into BungeeCord. The goal of the security manager is to prevent plugins from doing potentially dangerous or otherwise undesirable behaviour that may damage the stability of Bungee itself or pose a risk to the user's server.
One common theme in some Bungee plugins, especially those which were written in the very early days, is using Threads and ExecutorServices for scheduling purposes. Not only is this inefficient as there is no use of the thread caching features provided by the scheduler, it is also difficult to track who created which thread. Additionally creating threads not managed by the BungeeCord scheduler poses issues for when|if a plugin reload system is implemented, as these threads cannot be appropriately cleaned up and may continue to leak class references or perhaps even continue executing.
At this stage the SecurityManager is set to warn of prohibited actions, but not block them. For some plugins using external APIs, where usage of an ExecutorService is unavoidable, we have included an Unsafe interface to the scheduler which allows direct access to the underlying ExecutorService, or potentially a compatability wrapper.
Currently, passing a null favicon String to the ServerPing(Protocol, Players, String, String) constructor causes a NPE. However, passing a null `Favicon` object to the corresponding constructor does not cause one. Setting the favicon String using the setFavicon(String) method doesn't cause a NPE either.
Therefore, the NPE thrown by the constructor is inconsistent and should be avoided. Please find a sample NPE here: http://newpaste.md-5.net/pmtqjc8vl (Note the `null` favicon)
This PR changes the documented (unintended?) behaviour by adding a null check before passing the favicon String to the alternative `Favicon` object constructor. This makes the constructor consistent with the other one and the `setFavicon(String)` method. This also adds compatibility for old (made before Favicon API) plugins passing `null` favicon Strings (and expecting no favicon to be displayed instead of a NPE).
Thanks!
