Class NmsVersion

java.lang.Object
com.kamikazejam.kamicommon.nms.NmsVersion
public class NmsVersion extends Object
Version detection and management utility for the KamiCommon NMS system.

This class serves as the foundation for all cross-version compatibility in KamiCommon, providing precise Minecraft version detection and standardized version formatting that enables the provider system to select appropriate implementations across 13+ years of Minecraft evolution. It is fundamental to the entire NMS abstraction architecture.

Core Functionality:

  • Version Detection: Extracts precise Minecraft version from Bukkit server
  • Version Formatting: Converts semantic versions to comparable integers
  • Server Type Detection: Identifies specialized server implementations
  • Caching: Optimizes repeated version queries for performance

How the version is obtained:
Server#getMinecraftVersion() where it exists, reflectively because the 1.8.8 API predates it, falling back to the leading component of Server#getBukkitVersion(). Package based detection ("vX_XX_RX" from the CraftBukkit package) is not used and has not been reliable since Paper stopped relocating that package in 1.20.5.

Formatted Integer System:
Versions are packed into an integer that sorts in release order, so a provider can write if (ver <= f("1.16.5")) instead of comparing strings. There are two eras, because Minecraft left 1.x versioning behind after 1.21.11 and moved to calendar versions: 

Version                | Integer | Note
1.8                    |    1080 | absent patch reads as 0
1.8.8                  |    1088 |
1.16.5                 |    1165 | hex colour support arrives
1.17.1                 |    1171 |
1.20.4                 |    1204 |
1.21                   |    1210 |
1.21.9                 |    1219 |
1.21.10                |   12110 | FIVE digits, see below
1.21.11                |   12111 | the last 1.x release
26.1.1                 |  260101 | calendar era begins
26.2                   |  260200 | reads as 26|02|00
26.2.build.120-stable  |  260200 | trailing junk is ignored
26.10.1                |  261001 |

The legacy packing is textual, not arithmetic. 1.21.10 is "1" + "21" + "10", which is 12110 and not 1220. That is why the result is not a fixed width and must never be assumed to be four digits: it is four for most 1.x releases, five once the patch reaches two digits, and six for every calendar version. Compare it, do not slice it.

The two eras cannot collide. Legacy packing tops out at "1" + "99" + "99", which is 19999, and every calendar value is at least 260000. So ver < 260000 is the same question as "is this a 1.x server", and if (ver < f("26"))) is the correct way to write a fallthrough that must not catch 26.x. Prefer that over pinning the last release you happened to know about: a guard written as ver <= f("1.21.11") silently excludes a future 1.21.12.

Critical Dependencies:
This class is used by every provider in the system for version-specific implementation selection. Any changes to version detection logic directly impact the entire NMS abstraction layer and should be thoroughly tested across all supported versions.

See Also:

  • Constructor Details

    • NmsVersion

      public NmsVersion()

  • Method Details

    • getMCVersion

      public static String getMCVersion()
      Retrieves the precise Minecraft version of the current server.

      This method extracts the semantic version directly from Bukkit's version string, providing the foundation for all version-specific provider selection throughout the NMS system. The result is cached for optimal performance during provider initialization and repeated version checks.

      Two sources, in order:

      1. Server#getMinecraftVersion(), called reflectively because the 1.8.8 API does not declare it. This is the authoritative answer where it exists.
      2. Otherwise the leading component of Server#getBukkitVersion(), split on "-".

      The fallback is not always semver shaped. Paper 26.x reports its Bukkit version as "26.2.build.120-stable", so after the split the caller can be handed "26.2.build.120". NmsVersionParser reads the leading numeric components and ignores the rest, which is why that tolerance exists rather than being cosmetic.

      Examples: 

      Reported by server              | Extracted MC Version
"1.8.8-R0.1-SNAPSHOT"           | "1.8.8"
"1.16.5-R0.1-SNAPSHOT"          | "1.16.5"
"1.20.4-R0.1-SNAPSHOT"          | "1.20.4"
"1.21-R0.1-SNAPSHOT"            | "1.21"
"26.2.build.120-stable"         | "26.2.build.120"

      Returns:
      the Minecraft version string (e.g., "1.8.8", "1.16.5", "1.20.4", "26.2.build.120")

    • getFormattedNmsInteger

      public static int getFormattedNmsInteger()
      Converts the Minecraft version to an integer that sorts in release order.

      The width is not fixed. Earlier versions of this documentation described a "4-digit integer" with a single patch digit, which was wrong for 1.21.10 and for every calendar version. See the class javadoc for the full table. In short: four digits for most 1.x releases, five once the patch reaches two digits, six for 26.x and later. Treat the result as an opaque ordered value. Compare it, do not slice digits out of it or assume a range.

      Two eras:

      • Legacy (1.x): textual packing, so 1.21.10 is "1" + "21" + "10" = 12110. Reproduced digit for digit from the original scheme, so every f("1.x.y") threshold that ever existed keeps the value it always had.
      • Calendar (>= 2.x): major*10_000 + minor*100 + patch, so 26.2 is 260200 and reads as 26|02|00.
      The legacy branch cannot exceed 19999 and the calendar branch starts at 260000, so the two never overlap and no offset is needed.

      Writing version guards: 

      if (ver >= f("1.16.2")) { ... }   // a feature that arrived in a known release
if (ver < f("26"))      { ... }   // everything before the calendar era
      Prefer ver &lt; f("26") to naming the newest release you know of. A fallthrough written as ver &lt;= f("1.21.11") quietly stops covering a future 1.21.12.

      Performance Note:
      This value is computed once and cached indefinitely, as the server version cannot change during runtime. All providers rely on this method for version comparisons, making caching essential for optimal performance.

      Returns:
      the formatted NMS version as an order-preserving integer, of variable width
      See Also:

    • isWineSpigot

      public static boolean isWineSpigot()
      Determines if the current server is running WineSpigot implementation.

      WineSpigot is a specialized Minecraft server implementation that may require specific compatibility adjustments or alternative provider implementations. This detection helps the NMS system adapt to specialized server behaviors and ensure optimal compatibility across different server implementations.

      Usage in Provider Selection:
      Some providers may need to adjust their behavior for WineSpigot-specific quirks or optimizations. This method enables conditional logic within provider implementations to handle implementation-specific differences.

      Performance Optimization:
      The result is cached after the first query to avoid repeated string comparisons during provider initialization and version-dependent operations.

      Returns:
      true if running on WineSpigot, false otherwise