For a while now, we have been talking about the next logical step in evolving the Velocity platform. There have been many ideas on how we can push Velocity to the next level, and on the heels of the relicense to GPLv3, now is a good time to show you the money.
Requires Java 11 or Greater
Velocity 2.0.0 is projected to be the first Velocity release that requires Java 11 or higher. This allowed us to simplify some code paths that only use Java 11 features or higher and also lets us take advantage of newer Java platform features that we could have not used before.
Velocity 2.0.0 will touch just about the entirety of the Velocity API. Much of it is simply renaming methods and classes or moving packages around, but other changes are more substantial modifications to the Velocity API.
One change that we recently did was dropping
get prefixes in cases where it was unambiguous what the bare method name would refer to. In other cases, the
get prefix was replaced with a more appropriate prefix - for instance,
PermissionSubject#getPermissionValue has become
PermissionSubject#evaluatePermission. Other changes are planned, such as a complete revamp of the event result system, moving to entirely auto-generated event implementations, removing all use of
Optionals, and separating Java Edition-specific parts of the API to make room for Bedrock support.
Today, to run a listener asynchronous, we recommend blocking the event thread. However, this is far from a viable solution, and with the lack of “true” green thread support in Java, is simply not a real solution.
Cybermaxke’s PR changed this. Velocity 2.0.0 now supports “event continuations”, which allow an event to continue processing asynchronously without being interrupted (a major issue with the similar
AsyncEvent in BungeeCord). In addition, events now initially fire on the event loop (if it was triggered from a connection, that is). This provides some extra speed for trivial event listeners. In addition, it also enables Velocity to utilize other concurrency models for events (an example was provided for Kotlin coroutines).
Plugin Messaging API Changes
A rather common issue we have recently seen in the Velocity Discord with developers is the lack of a coherent explanation of the plugin messaging components of Velocity. Velocity’s system here is quite similar to BungeeCord’s, with the added quirk of explicitly distinguishing between “modern” (Minecraft 1.13 and above) and “legacy” (Minecraft 1.12.2 and below) plugin channels. This has been a consistent pitfall for developers developing for the Velocity platform.
In Velocity 2.0.0, we have refactored the ID system to be more consistent and require an explicit modern channel for every legacy channel. We want to explore other changes to the plugin messaging APIs, so open an issue and leave your feedback!
Another feature Velocity 2.0.0 now has is support for native localization thanks to integration with the localization features of Adventure, the “user interface” library we use for user-facing interactions. Velocity includes a default English localization (soon to be joined by French, German, Czech, Slovak, Dutch, and Spanish). Plugins can also add their own localizations to the global Adventure translation and use
TranslatableComponents to send localized messages - Velocity will render the messages in the user’s preferred language on the server side before sending it to the player.
So Much More!
Velocity 2.0.0 is projected to be a large release. Please stay tuned for updates.
When Can I Play With It?
Not now. The API is still in flux. We want to refine the API. In the meantime, for a more convenient look at how the API has changed, you can look at the Velocity 2.0.0 JavaDocs.
Velocity 2.0.0 is far from release. We can not provide a firm time when it will be released. Late 2021 or early 2022 is a reasonable guess, but we can’t promise that we will meet this target. Velocity is developed by a team of volunteers after all, so we are under no obligations to meet hard deadlines.