Version Compatibility

Version Compatibility

EverNifeCore runs across a very wide Minecraft range - roughly 1.7.10 through 1.21 - on Bukkit, Spigot, Paper and their Forge hybrids (for example Crucible on 1.7.10). It does this without compiling against any CraftBukkit jar: version-specific behavior is either gated behind a runtime version check or resolved through reflection at runtime.

Detecting the running version

Two enums describe the server's Minecraft version.

MCDetailedVersion is the fine-grained one - every NMS revision from v1_7_R1 to v1_21_R1. It detects the current version once at class-load from the server's package name and caches it:

import br.com.finalcraft.evernifecore.minecraft.version.MCDetailedVersion;

MCDetailedVersion current = MCDetailedVersion.getCurrent();  // e.g. v1_16_R3
current.getShortVersion();  // "v1_16"

MCVersion is the coarse one - the "family" buckets used for the common comparisons (v1_7_10, v1_12, v1_13, v1_16, v1_19, v1_20, v1_21). Its static helpers compare the running server against a bucket or a detailed revision:

import br.com.finalcraft.evernifecore.minecraft.version.MCVersion;

if (MCVersion.isHigherEquals(MCVersion.v1_13)) {
    // flattening-era code
}
if (MCVersion.isLowerEquals(MCVersion.v1_12)) {
    // legacy numeric-id code
}

The comparison helpers - isLower, isLowerEquals, isEqual, isHigher, isHigherEquals - accept either an MCVersion bucket or an MCDetailedVersion revision, so you can check as coarsely or as precisely as you need. MCVersion.getCurrent() returns the current MCDetailedVersion.

How detection works (and its fallback)

MCDetailedVersion reads the last segment of the server implementation's package name (the classic org.bukkit.craftbukkit.v1_16_R3 versioned package) and matches it to an enum constant. If no constant matches, it assumes the newest known version and logs a notice. This matters on modern Paper (1.20.5+) and current Spigot, which dropped the versioned package segment: on those servers the exact R revision can no longer be read from the package, so detection reports the newest known revision. Family-level checks (MCVersion.isHigherEquals(MCVersion.v1_20)) stay reliable; do not rely on the precise R revision on an unversioned-package server.

Writing version-aware code

The idiom is to gate a call behind a version check so the same JAR runs everywhere. The item builder does exactly this - custom model data only exists from 1.13, so it is guarded:

if (MCVersion.getCurrent().isHigherEquals(MCDetailedVersion.v1_14_R1)) {
    meta.setCustomModelData(modelData);
}

Some features are registered conditionally at startup for the same reason - for example the enchantment item data part is only registered on 1.21+, and enchant-glow uses a durability enchantment on 1.7.10 where the modern approach is unavailable.

CraftBukkit access by reflection

Nothing in EverNifeCore compiles against net.minecraft.* or org.bukkit.craftbukkit.*. Where the core genuinely needs an implementation class (a handful of spots, such as resolving CraftPlayer), it builds the class name as a string and looks it up at runtime - the class resolves against the real server, so no compile-time jar is needed. This is why the build needs no CraftBukkit dependency at all - see Building from Source.

The compatibility modules

Under minecraft/modules/ sit three version-specific modules: v1_7_10, v1_12_2 and v1_16_5. Despite their names, these are WorldGuard / WorldEdit compatibility layers, not NMS code - they wrap the region and cuboid APIs of those plugins, whose shapes changed across WorldGuard 6 / 7 and WorldEdit 6 / 7. The core selects the right wrapper for the running server so the protection and world-edit integrations present one stable interface regardless of the installed WorldGuard/WorldEdit generation.

Because they touch neither net.minecraft.* nor org.bukkit.craftbukkit.*, these modules are pure plugin-API compatibility shims. They compile to Java 8 bytecode for the 1.7.10 floor - see Java Versions and Toolchains.

Practical range notes

• 1.7.10 is the oldest supported floor (validated on Crucible + Java 21). Item/GUI NBT depends on the bundled Item-NBT-API resolving the server's mappings; on some non-standard forks the NBT self-test may report a failure at boot, in which case only item/GUI NBT is affected - see Items and NBT.
• 1.8 - 1.20 run on Spigot/Paper with versioned packages, so precise revision detection works.
• 1.20.5, 1.20.6, 1.21 dropped the versioned package; family-level checks are the reliable ones there.

See also

• Items and NBT - version-gated item features and the NBT self-test.
• Integrations - WorldGuard/WorldEdit, which the compatibility modules back.
• Java Versions and Toolchains - the Java 8 bytecode floor and Jabel.
• Building from Source - why no CraftBukkit jar is required.