Async Development – Task Chain – Java Control Flow for Bukkit
Reposting because Google has bugged out and ended up dropping this from Google :/ So making it look new to get it back on Google.
So as any Bukkit developer knows, the API is not thread safe! And to make matters worse, there is no concrete Java Control Flow API in Bukkit.
However at Empire Minecraft our server very heavily depends on our MySQL Database to provide features. So running database queries on the main thread is common but undesired, and Java control flow is needed.
Running queries async creates complicated java control flow issues, need to run this query… now need to access the bukkit api, so return to Sync processing, oh wait, now I need to act again with another database query!
Easy to avoid all that java control flow trouble by running everything sync – but then performance can be hurt.
Therefor, to avoid Java running into this same callback mess, I wrote an elegant Java Flow Control system on top of the Bukkit Scheduler.0
The problems with Bukkit and Contributing
I spend quite a lot of time improving the CraftBukkit’s core code, in order to make it perform better, more efficient and overall do things in a better way. I’m responsible for some of the biggest performance improvements that’s been made to the Minecraft Server.
However, if you’re not apart of the Spigot community, it’s likely you’ve not seen my name before. That’s because I’ve barely had any PR’s accepted to the CraftBukkit project.
It’s not for a lack of trying, it really all boils down to politics and policies.
I feel that CraftBukkit’s PR Policy is a reason the project went further downhill. There are countless people like myself that want to work to make the project better, but do not have the time to deal with the politics.
I’m speaking of the “holier than thou” attitude that the (original) CraftBukkit team (well, specifically certain members who handled PR’s) attitude.
It’s not that I’m lazy, it’s quite the opposite: I’m BUSY. I work a full time job to pay the bills, then another full time job to run my own Minecraft Server. I don’t have the time to contribute to Bukkit or Spigot, but I do it any ways especially when it can benefit my own server.
Every experienced developer knows designing a solution and testing and working all the bugs out is the hard part of writing code, not the syntax or styling details. However, COUNTLESS Pull Requests are closed on Bukkit purely due to minor things.
I look at it this way, if all that is “wrong” is a simple white-space on a single line or a 3 line change, then just make the fix yourself when pulling it!
This PR for example: https://github.com/Bukkit/CraftBukkit/pull/1352
Only feedback was formatting errors essentially which I resolved, then it sat for many months untouched. It then of course conflicted with newer commits.
The problem is Bukkit thinks everyone contributing is sitting around, waiting to make the next change to get it accepted. But, we can’t do that. We have other things to work on. My focus has been switched and I’m now working on the next task.
To have to stop what I’m doing, switch back to a different project/checkout, add a space and recommit and push… It’s hard to justify stopping work on something significant for such a small thing.
Essentially, Bukkit thinks we should lose 10-30+ minutes of our time, and most importantly: break concentration (and we all know how bad that is) for meaningless politics just so that the Bukkit team member doesn’t have to do a single change to the code, to save them 2 minutes.
I disagree with this ideology completely. When you are a team member of a successful open source project, your goal should be to make that product great. If someone took their time to solve a complicated issue, and bring it to production readiness, it is fairly reasonable for you to spend 5-30 minutes when pulling it to fix up tiny things, verify it works yourself, and fix up things that you want changed that does not interfere with the logic of the change itself (styling, whitespace, imports, etc).
The only reason you should be sending a PR back to the submitter is if you have a concern with the implementation, or need more details to understand the change yourself.
A project maintainers time is no more important than the contributors, and remember, its not the contributor who’s going to get the mass-praise over a major new change – its the project itself and its developers, even when they didn’t even do the hard part of a change.
Be happy that someone is helping you improve your product, and work WITH them to improve your product.
Mojang: My suggestion to you – Put someone in charge of the project who is enthusiastic about making the project great. Someone who gets excited when someone is working on “the next big change” for them, and is eager to work with them and discuss it and push for it to be included.
Please build a team of FRIENDLY people, people who are not going to personally insult everyone who tries to have low level talks, and someone who is not going to try to make others feel lesser than them.
Loosen up the PR process, and give people realistic hope that a PR might actually be pulled before the next major upgrade that conflicts the PR.
Another thing to do is encourage low level discussion and “potential” talk. Numerous times I tried to discuss the feasibility of whether or not CraftBukkit would even CONSIDER an idea. I wasn’t about to go spend 12+ hours working on a change to just be told “We don’t want to maintain a change of that scale” or “we don’t think the API should offer that”.
But every time I was told to go do it then bother them with it… And discussing the idea without showing results was met with insults.
That can not happen any more.
Spigot isn’t perfect, but is a much better place than Bukkit was, so if you can at least match Spigot, then you will have done great things for the Bukkit project.
If any Mojang member (Dinnerbone?) wants to discuss this more with me, I’m on IRC (Esper, Spigot, FreeNode) as Aikar every day.
Here’s hoping Dinnerbone is true to his word that Bukkit will be better than before!