Just over two months ago, I wrote a blog post on an API I created called the CommandAPI. I decide to review the major changes since the first blog post and show how development has been since the creation of the CommandAPI.
Stats
Since the beginning of my project, I’ve created over 90 separate commits which modify over 12,000 lines of code. I’ve dealt with 13 separate issues, half of them involved implementing new features, whereas the other half involved fixing various bugs and critical problems with my project. I’ve released 6 versions of the CommandAPI, where the first version only had support for primitive data types and the latest version (version 1.5) has support for 12 various Bukkit objects. It’s also my repository with the most stars on it!
A first time for everything
From this project, I’ve been able to gain lots of new experience in various fields that I’ve never had experience in before.
GitHub Issues
I’ve never really used GitHub’s issues before and I must say that I have no idea how on Earth I’ve lived without it. Developers create issues and I’d fix them. With GitHub issues, I’d organize my bug reports and filter out suggested enhancements to be on top of all of the issues that came my way. I’d discuss with the various developers about the features they’ve submitted for implementation and point out any flaws in their suggestions. All of this made me feel like a star reaching out to my adoring fans.
Caching Reflection
Java’s reflection is notoriously known for its powerful capabilities and horrific performance. In other words, if you thought Java was slow, then reflection is a whole new level of a performance hindrance (as stated in the oracle docs). Most developers that would use reflection, therefore, cache various methods and fields to reduce the number of reflective calls to the same methods or fields. Unfortunately, until this project, I’ve never implemented my own reflection caching before and by implementing a viable solution successfully, I feel like I have a nice basis for when I want to use reflection in future other projects.
Maven
I’ve never really liked Maven when it came to Java projects. It was complicated to set up, the dependencies would always throw errors and I could never get the right version of anything I wanted without it messing up my entire build path in Eclipse. During this project, a developer tried to convert it to Maven and as expected, Eclipse didn’t cooperate, so I rejected their pull request. Within the same day, that developer managed to get Maven to work properly and I decided to try it out for once and for all. It worked a charm! The required dependencies were easily managed, I was able to understand the mysteries of the pom.xml file and I even managed to host a Maven repository on my GitHub repository so anyone else can use my project!
Destructive Methods & clone()
During this project, a developer came across this strange issue. After discussing it with my fellow computer scientists, I learnt that Java can have these things called destructive methods, which are methods that modify the attributes of an object. Little did I know that this existed, despite having experience in Java for the past 6 years. I also learnt the importance of the clone() method, which can be used to duplicate an object.
Syntax changes
Two days after creating that blog post, I had changed the entire syntax revolving around my API and the blog post’s sample code was instantly outdated. To put my mind at ease, I present an example of the new syntax of two months ago:
1
2
3
4
5
6
7
8
9
10
11
//List for arguments
LinkedHashMap<String, Argument> arguments = new LinkedHashMap<>();
arguments.put("target", new EntitySelectorArgument(EntitySelector.ONE_PLAYER));
arguments.put("message", new GreedyStringArgument());
//Command registration
CommandAPI.getInstance().register("mycommand", arguments, (sender, args) -> {
//Safe casting as type checks have already been performed
((Player) args[0]).sendMessage((String) args[1]);
});
Spreading the word
When I created this project, I didn’t have the intention of mentioning it to the Spigot community (I’m still rather skeptical about the Minecraft server plugin communities after a previous community basically shut down). However, a certain developer going by the username Combustible seems to have done the job for me. They’ve posted on commodore’s resource thread (commodore was mentioned in my previous blog post), as well as various other threads.
Conclusion of the conclusion
In the conclusion of my previous blog post, I stated:
In general, it’s a little wrapper to tie over the time until the spigot/bukkit developer team create their own wrapper for the new command UI.
Hopefully, the development team would have started working on some sort of implementation for Minecraft 1.13’s greatest new feature by now, right? Wrong. According to this issue report, the lead developer of the Spigot software chose to dismiss the issue and not fix it. It seems that my “little wrapper” may become something much much larger in the future.