Performant, high code quality and extensive command framework, Inspired by High Quality Command Frameworks such as Lamp to try fix their (current) issues
Okay, cool, I have heard this a million times, you probably have terrible performance, readability, understandability and/or code quality, slow support, non-extensive and/or have a massive jar size
Look, don't assume, other command frameworks are obviously great and try their best, although:
Here is what makes you choose FlameWare over others:
Here is why FlameWare tops in performance:
FlameWare is Java 11, to improve API safety, security, to promote new versions, and of course, performance.
it also helps developers suffer less by using more dated features and having much more performant features than Java 8
Java 11 is also the perfect Java version because it runs on most Spigot/PaperMC versions (1.11.2/1.12.2+)
Read on Microsoft performance improvements from Java 8 to Java 11
Read on de-caff benchmarks between 8 vs 11
Features you could've been missing when using Java 8:
but mister FlameyosFlow, how can performance make readability better? that's hard
Your answer: Well I defeated hard!
FlameWare tries to take advantage of Java and other stuff to not only improve performance, but to even improve readability in some cases!
FlameWare is very based on caches and map computing, in some cases it lowers the amount of lines and makes it more readable or understandable, making it better maintainable for even better code in the future!
FlameWare is cache-based AND hash-based, especially for argument parsing and command registration
FlameWare uses a lot of thread-safe operations, and FlameWare utilizes the smartest features to improve functionality, extensibility and performance.
Didn't I just tell you how much I try utilizing the smartest features to improve performance and so on? that doesn't break here.
The current method handling can only happen for public command methods to significantly improve performance. Here is the current execution:
MethodHandles.publicLookup().unreflect(Method).invokeExact(Object, ...);.publicLookup() improves performance by doing optimizations for public methods, significantly improving performance more than the traditional reflection actually.
.invokeExact(...) invokes the method with a lower amount of checks than invoke(...), since there's no need for extra checks (since the parameter are parsed from the Method object anyways), it improves performance using invokeExact.
Here is why FlameWare tops in Readability and Development Time:
Here is what some command frameworks make you do:
@Command(aliases = { ... })
// optionals
@Usage("...")
@CommandPermission("...")
@Description("...")
public class MyCommand {
@Default
@MoreAnnotationsFromCmdFrameworkIfNeeded
public void coolCommand(Player player, int number, @Join String hey) {
...
}
@Subcommand(aliases = { ... })
// optionals
@Usage("...")
@CommandPermission("...")
@Description("...")
public void anotherCoolCommand(Player player, int number, @Optional @Join String hey) {
...
}
}Wow, that's a lot of work, right?
Well, this is what you do in FlameWare:
@Command(name = "...", /* optionals */ desc = "...", perm = "...", usage = "...", aliases = "...")
@MoreAnnotationsFromFlameWareIfNeeded
public class MyCommand {
@Command
@MoreAnnotationsFromFlameWareIfNeeded
public void coolCommand(Player player, int number, @Default OfflinePlayer target, @Default @Join String hey) {
...
}
@Subcommand(name = "...", /* optionals */ desc = "...", perm = "...", aliases = "...")
@MoreAnnotationsFromFlameWareIfNeeded
public void coolDudeCommand(Player player, String[] args) {
...
}
}18 lines to 14 lines, and thats just a sample, imagine real code, man.
This approach leads to a slightly smaller jar file, easier maintanence and better development time
Lamp does top FlameWare in extensibility as of now since it is a much earlier project, but here is why FlameWare is so good in Extensibility and Customizability:
Not only does using HashMaps and ConcurrentHashMaps instead of a bunch of switch/if statements improve performance (especially in huge maps) but they even allow for much easier extensibility!
Imagine this for extensibility:
if (...) {
} else if (...) {
} else if (...) {
) else if (...) {
} else if (...) {
} // and so onThat would be slower and MUCH harder to add extensive features to it. Just 1 or 2 if statements with a map can be so much faster and more extensive too
There is an API for suggestions and parsing, thanks to the hash implementations we talked about above.
this is at 1.0.0, that was added at the very first version, imagine how many features it is right now (I'm looking at the future)
Here is why FlameWare tops in support:
Yes, I am active every hour on discord and I am willing to help anyone.
There is quick support as long as you ping me! (unless there is an emergency)
Speaking of small, here is the Size.
Okay, this has to be big with all these features.. right?
Here is why FlameWare tops in File size:
As of now, here are the size of the modules with no minimization: (these are the last checked size, could be higher or even lower)
- Spigot & Common Combined: 50kb~
FlameWare is light despite its features!
First of all, there are no implementations, everything is compiled only, here are the used libraries:
- Lombok - compiled only
- Jetbrains annotations - compiled only
- Classics such as Spigot - compiled only
Other reasons may be:
- Because of the low amoumt of classes, interfaces, enums and annotations combined
- Because FlameWare removes all of the meta data using ShadowJar that usually comes normally in a JAR file
- Because FlameWare uses as much Java as possible, the JDK has all the java classes, meaning, using java classes will be better for file size
- Because FlameWare attracts the eye of people looking for extensibility, not complete features, leaving more space for your projects!
- and more!
Fine, you convinced me, this is just too much to resist, how do I try this?
Since you kept reading until here, there is a very big surprise at 2.0.0, it will send your heads flying :)