Comparison to other APIs

Page Information

Page Completion	Valid as of	Notes
🟢 100%	Pre-release	None

Comparison

Notes

• This page is written in our own opinion.
• Please let us know if you disagree with anything here. We can always edit this page, we wish for it to be accurate.
• 🟢 = good, 🟡 = okay, 🟠 = bad, 🔴 = terrible. This is a score, not specifically an indicator on if a feature is included or not. For example, see Treasury's multi-world support comment.

Table

Feature	Treasury	Vault	Reserve	Comment
Adoption	❓	🟢	🔴	Treasury is brand new, so we have no idea. Reserve has been out for a few years but has still not gathered any noticeable adoption.
Documentation (Wiki & javadocs)	🟢	🟡	🟠	Treasury has the best documentation of the three projects. Vault's is okay, but it is also missing some key information. [Reserve's Wiki](https://github.com/TheNewEconomy/Reserve/wiki) is poor, but its javadocs are decent at least.
Time since release	🔴	🟢	🟢	Treasury: approx. early 2022. Vault: Oct 2011. Reserve: Dec 2017.
Stability	❓	🟢	🟢	Treasury is currently in pre-release development, so we are unable to compare stability of the API. It will only be determined with time.
Multi-platform	🟢	🔴	🔴	Vault and Reserve are only operational on Bukkit, whilst Treasury's APIs are platform-independent.
Quality support	🟢	🔴	❓	Vault's support is terrible. We are unsure about Reserve's, it's probably decent.
Concurrency support	🟢	🔴	🟡	Treasury uses a specialized EconomySubscriber class which can also be converted into a CompletableFuture. Reserve makes CompletableFutures available through their async methods but they are optional to use, which is detrimental. Vault has no concurrency support whatsoever. Concurrency support is important as an economy plugin may need to make a query to a database - when completed synchronously in Vault or Reserve, it will freeze the server until the request is completed. Database queries are not instantaneous due to possible load at the time and connection speed if it is ran on a different server.
Willingness for change (relative)	🟢	🔴	❓	If your proposed change to Vault breaks a plugin that hasn't been updated for 7 years, then forget it. We are unsure about Reserve since it does not appear to have received many contributions, especially on Treasury's scale, so we can't tell. Treasury will always strive to maintain some degree of legacy support, but we will not let it drag the project behind.
Non-bloated APIs	🟢	🟢	🟡	Treasury and Vault are quite strict against having bloated APIs. Reserve on the other hand has some unnecessary features.
Adoption of UUIDs	🟢	🟠	🟢	Vault still has deprecated APIs from years ago that people still decide to use which have player names instead of UUIDs. In addition, bank accounts are identified by name instead of UUID. Vault uses UUIDs through OfflinePlayer objects, but this can cause unnecessary server freezes whilst it needs to request data of a player from Mojang's servers. Treasury and Reserve have a concrete use of UUIDs.
Bank accounts	🟢	🟡	🟡	Vault's bank accounts require an owner which is not suitable for all implementations. They also do not use UUIDs. Treasury's bank accounts surpass those from Vault and Reserve. Vault's require an owner.
Multi-currency	🟢	🔴	🟢	Vault does not offer any multi-currency support whatsoever.
Code quality	🟢	🟡	🟠	Reserve's EconomyAPI class is 3000 lines long of methods, have fun using that. Vault's is better, but not as good as Treasury's organisation choices.
Multi-world	🟡	🟡	🟡	Vault and Reserve makes it optional to use their multi-world methods, which in essence, self-defeats the feature. Treasury started out with Multi-World support, but we removed it since we believe that it is better left in the hands of the economy provider. Treasury's historic multi-world support also brought about more confusion in using the API. We believe it is advantageous that Treasury does not have multi-world support for this reason. Multi-world economies are also difficult to manage.
Well-designed EconomyResponse	🟢	🟠	🟡	Treasury has opted to build upon Vault's EconomyResponse by making it a generic class instead, significantly upgrading its capability. It also supplies better communication potential through the economy API by supplying a variety of reasons why a transaction was unsuccessful, other than a 'yes or no' result. Oh, and you don't have to use the 'success' or 'fail' as a 'yes' or 'no'.. for some reason Vault does that.. :)
Transaction history	🟢	🔴	🟢	Vault does not offer this functionality.