These are the same issues I was seeing in that thread. As I’ve said, easily fixed. An event bus is more work, but it’s fairly simple and can be searched online.
Heck I’ll even fix the code so they don’t have to. If their plugins are broken (as they probably would be by the package change) the plugin developers should be active enough to fix it. If not, then when loading the plugins they can remap the classes.
I was catching up on the latest and saw this thread. Good idea to get a summary of current state and evaluation.
First, I welcome everyone’s opinion on Rainbow, good or bad. Some things to consider in counterpoint to the negative things raised:
With this latest information, I think you’d have to consider any server mod publishing sources to be very sketchy. This also means when Spigot for example is done with their work, they won’t be able to publish sources for people to contribute openly to (at least not the server pieces).
About other things:
-The criticism on code is amusing. To each their own coding preference, it’s all 1s and 0s in the end. I only criticize code when it doesn’t work or is unnecessarily complex. If you find places where “This code doesn’t work” then I’ll be very interested and look to fix it! 
PS: Spigot status update looks promising. I wish them the best and don’t see anything stopping them. Technically it’s straight forward from where they are just requires hard work and following through.
Links to the tweets if anyone is as interested as I was:
1 I found 42 projects on github that contain the decompiled game code. Giving everyone a fair chance to fix it before I take further action.
2 Yes, I contacted all of them. It’s ok to decompile the game to make mods for it, but it’s not ok to publish the decompiled code.
Also these two also seem relevant. As for how much, I wouldn’t know since I’m not familiar with how this works but still I thought it would be a good thing to show.
3 Nobody will probably complain if someone copies a function or two from the code in their mod, but complete code is a different story.
4 I want to make sure everyone understands that I’m talking as the founder of MCP and our TOS, this is not related to Mojang in any way.
Thanks @DoingItWell I was hoping you might find the thread so I could get some idea of what you were thinking.
My critique of the code style is more the use of underscores and not using packages, which goes directly against both Oracle and Google’s published style guides. It’s common practice for beginner developers to not use packages, but beyond that I can’t say I’ve ever seen a developer choose not to use them. It makes the code way to complex to maintain in the future and can actually cause some very odd compiler issues (These I’ve had).
The point about plugins not existing makes a lot of sense to me. Bukkit actually had some in house plugins that weren’t part of the server, but were developed by the team called HomeBukkit, ScrapBukkit (and I think there was another one). However the concept of having to disable a non-vanilla feature is a little unusual given that no successful server has bundled commands that were default on.
As for published source, the whole reason other mods have such unusual ways of making their projects hook into the server is that Mojang made their position on decompiled code clear. Basically you can distribute your code as patches to a standard decompiled jar made via your toolkit. It’s a more annoying approach but it will be nice for people to get a copy of your code to make changes.
I should have seen this post earlier, somehow I missed it. The Spigot team is amazing, lots of people from the Bukkit staff are actually also Spigot team members. MD_5 for one is an excellent programmer.
Given the time needed to properly write and implement the API for Sponge, I doubt that the Spigot team can’t beat us, they’ve been working on it for longer. However I welcome the competition.
I would have to say that one of my first Minecraft modding projects was to try and patch MCP to support a snapshot. That didn’t work so well, as I’ve written about in the past, each team seems to want to keep their remapping tools close to the chest. Making each new project have to reinvent the wheel and start from scratch. Everything but the most important piece, the part needed to update, is put up as open source. However the homemade tool used to remap is kept by a few, a sacred torch of Minecraft decompiling if you will.
In fact, I was gonna contribute an event system that I’d just written for a project I’m working on to rainbow, when I realised that they don’t have any code up. Granite is looking quite interesting 
Edit:
Pheraps you coud add a link to
under rainbow.
You just added the link 
Granite’s code needs to be a bit more understandable and such. Also it has the potential to be very slow given the extensive reflection.
But I like it’s unique approach.
I meant to reply to this earlier but it slipped my mind. Whoops.
Anyway, from what I understand Spigot is going to phase out all bukkit code and replace it with their own. Once they do that I can’t see any reason why they wouldn’t be able to publish the sources. Correct me if I’m wrong but, I’m also pretty sure they haven’t/won’t distribute complete game code anyway so nothing would be stopping them.
And as @modwizcode has already said, Forge or Sponge doesn’t distribute complete game code anyway so the idea that you’d have to consider “any server mod publishing sources to be very sketchy” isn’t true. This also true for granite since it states on their site that it “doesn’t contain or build against vanilla code.”
“Reflection is super horrendously slow” is a myth that hasn’t been completely valid for at least 3 years. It appears that Granite is caching classes, fields, and methods based on name, so the overhead is already greatly reduced. See the recent posts on this thread: http://stackoverflow.com/a/435571
The only real performance drawback I can think of is inability to optimize vanilla stuff like Spigot, which could be worked around with ASM or similar bytecode manipulation.
In addition, I don’t see why Granite would be “at least somewhat hard to update”. It seems like it would be slightly simpler than CB due to not actually modifying the vanilla code, and the developers are supposedly starting to automate their mapping methods.
Personally, I feel that it’s the most viable, legal option ATM. It goes without saying that this is blasphemy on the Sponge forums, but from writing a simple plugin and appraising functionality/ease of use/future update potential, Granite definitely takes the cake.
I don’t think it’s blasphemy at all. Granite appears to be our most serious competition if Husk doesn’t turn out to exist.
I think we should help them design a good API, I actually would rather team up with and have them work on a native implementation of the SpongeAPI that doesn’t rely on forge.
All I can say is for someone that doesn’t have a product out, you sure do put sponge on a pedestal, Knocking down everything else. Not that I’m against Sponge, but what have you guys got to show for it as of now? I’ve said it before and I’ll say it again Rainbow is the only working alternative at this time for a 1.8 server that i find has less bugs then the others mentioned in the OP.
Thank You DoingitWell, my members are happy.
I haven’t knocked anyone down and neither has @modwizcode. Yes some people are shitting on it for no reason other than blind hate but if you look at my [other][1] [posts][2] and [various][3] examples you’ll find that the only thing that the legitimate arguments are doing is stating what they feel are pros and cons about other products. Nothing more. Heck even @Inscrutable has [made some good points][4] in the previous thread.
Just because something is the only thing available doesn’t mean it’s great. And just because Sponge isn’t out yet doesn’t mean we can’t discuss the pros and cons of other servers out there. Heck I may even start using another server if one comes out with the plugins I need and looks like it has a decent future.
Also as for the “You have nothing out yet so you can’t discuss the cons of a server that is out” argument I have to say that’s simply not true. As I already stated there are pros and cons to both products and you could easily compare the two on certain levels like Dev reputation, community, api features both planned and already shown, etc. Plus, yes Sponge isnt available to download and use yet but any dev can look at what they have done and pushed to the github and see if they would want to work with it in the future. The core part of a server platforms life are the plugin devs and depending on how many are willing to make plugins for the product and which well known ones get official ports is very important.
It’s not a race to see who get’s theirs out first it’s what pros and cons each one has more than just having a working product. Again, just because a restaurant is the only place to get food in town doesn’t mean it’s particularly good for you.
EDIT: Also, by that logic literally no one can give their pros and cons about rainbow because it’s literally the only working option available at the moment and that’s just foolish to suggest. If something is good then it’s good and if it has problems then it has problems. Whether iit’s the first one out or the last doesn’t change that fact.
[1]: Sponge vs Rainbow - #130 by HeirOfChairs
[2]: Sponge vs Rainbow - #132 by HeirOfChairs
[3]: An Appraisal Of The Competition - #13 by HeirOfChairs
[4]: Sponge vs Rainbow - #134 by Inscrutable
I agree with you to an extent, but how is possible to say Sponge is better than (anything) because the people working on it? The same developers will be working on other platforms so this should not matter. What I’m stating is that Sponge is being being put on a pedestal, with no proof of what’s being done with it. SO yeah you have some good developers onboard, but nothing to show for it. Pros and Cons should be compared for what you have going, not what might be.
You seem to have a few misconceptions so let me clear them up:
I have Never said Sponge is better than anything and most of the valid people in this and the other thread haven’t either. If I have alluded to that then that wasn’t my intention. The point of the pros and cons is to talk about the pros and cons not compare them. And if you do compare, you can compare on the levels as I have already said. I may support sponge and hope for the best for it’s future but it isnt even out yet. Anything could happen. Heck Granite may be the best one or Rainbow a little bit down the line.
As far as I know the plugin devs may or may not make plugins because the amount of time to port to each platform isnt worth it. Even if many do, not every one will take the time to port and what matters is which ones and how many are developed for what platform first
There is plenty of proof of what’s going on with it. From the Dev irc channel to the announcements to the Github. It’s not like a secret project only the head devs are able to access. Heck they even opened up applications for other devs to work on the api and you can ask any of them.
As I said above, there is work to be shown for it.
If pros and cons are to be compared they should be compared to everything. Yes, you shouldn’t say something like “Sponge will have better performance than Rainbow” because that would be a guess. But you could and should compare things like the future plans for each project or the way each of the api’s are shaping up. But again, the point isnt to compare to sponge necessarily but to give pros and cons on the platforms stand alone. Of course some people will make the comparison but the valid ones will compare to things that are actually, well, valid at the current time. Like some of the api problems some people have stated earlier.
I never said you , i was referring to the original poster.
In essence the brief description of the OP is a personal opinion regarding the server platforms.
I’ve tried Granite and several other platforms, none of them except for Spigot , can offer what i currently need as Rainbow does. Yes it’s not perfect, but i can guarantee no platform will be,
including Sponge.
Anyways my intent is not to get into a tit for tat with anyone, were all in this for the same thing ( the love of the game) I wish Sponge the best of luck., but in the meantime I’m happy with my Rainbow.
Ah, since you replied to me I assumed when you said
that you were referring to me. I’m sorry for the confusion but you should make it a little clearer who you’re talking about next time.
And alright. That’s your valid opinion and the op has theirs. Yes some of the comments may have been unnecessary but overall imo it was a reasonable pros and cons list.
Also what other platforms have you tried? I’d like to know what other ones are out there besides granite and rainbow.
Why we’re so sure that Sponge will succeed?
Well, we are actively developing Sponge, not only code-wise; thing is, the other projects only have small communities.
A big project with no community = can’t survive
A small project with a big community = can survive
And, well, our project isn’t even small.
Thank you ModWizCode for your concerns about Granite. We are aware that reflection will slow the server down slightly, but we have just come across something that could change the amount of reflection that we have done so far. Also I appreciate that people think that updating our project will take longer. In my opinion I don’t think that we will. I spent 2 nights (around 12 hours) updating to 1.8.1 (purely me deobfuscateing, comparing methods, classes and fields to 1.8.1) which will be release when Minecraft 1.8.1 is out. The only thing we have to do I update our mappings file and that’s it, Granite does the rest. As someone said ‘Finally, a use for Granite’ (This has become somewhat of our motto).
To Admin/Moderators:
Please do not take this as advertisement, I am purely expressing views on the projects current state.
Thanks for your response! I enjoy seeing participation from the projections I mentioned. Just a helpful hint modwizcode is the correct capitalization from my username. Not really a big deal at all.
I was wondering how hard it would be for updating Granite in an update like the one from 1.7 to 1.8 was, where large changes happened in the way it was written. The struggle I see, is that the reflection is a little hard to read as a developer, and functionality might be hard to understand because of the way it’s written.
Ah ok, sorry for that, my bad.
Um I’m a bit unsure really, most things now im looking at the NBT route of things which will cut a load of reflection. As for the implementation of reflection, we have a mappings file like MCP has to work out what method/class/field does. We then load that up in to a Map. if we want to reflect something all we do is go to the Mappings class and do Mappings.invoke(“readableName”, Args); this will then pass through to the mappings and will be worked out but the Mappings class what needs to be invoked. It will then pass the Args through to the method that has been selected.
As for updating from 1.7 to 1.8, most methods were kept so there wouldn’t have been a lot to do. If a new method was added then we you just reflect it and add it to the API (Easy Peasy). And as for it nobe being clear and readable I am currently going through and adding javadoc to everything to make it clear to everyone.