Summary
Every cow death throws NoSuchMethodError on Minecraft 26.2, so the death is never logged and a stack trace is printed each time. 81 occurrences over four days on a normal survival server.
Versions
- CoreProtect
24.0 (dev build b92)
- Paper
26.2 (build 92, paper-api-26.2.build.92-stable)
- Java 25
Stack trace
[ERROR]: Could not pass event EntityDeathEvent to CoreProtect v24.0
java.lang.NoSuchMethodError: 'org.bukkit.entity.Cow$Variant org.bukkit.entity.AbstractCow.getVariant()'
at net.coreprotect.bukkit.Bukkit_v1_21_5.getEntityMeta(Bukkit_v1_21_5.java:25)
at net.coreprotect.listener.entity.EntityDeathListener.logEntityDeath(EntityDeathListener.java:560)
at net.coreprotect.listener.entity.EntityDeathListener.onEntityDeath(EntityDeathListener.java:655)
at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:71)
Reproduction
- Run Paper 26.2
- Kill any cow
- Stack trace above; the death is not recorded in
/co lookup
Chickens and pigs appear unaffected.
What seems to be happening
Bukkit_v26_2 extends Bukkit_v1_21_5 and overrides neither getEntityMeta nor setEntityMeta:
public class Bukkit_v26_2 extends Bukkit_v1_21_5 {
public Bukkit_v26_2() { this.initializeBlockGroups(); }
private void initializeBlockGroups() {
BlockGroup.TRACK_TOP_BOTTOM.add(Material.SULFUR_SPIKE);
}
}
So the inherited Bukkit_v1_21_5.getEntityMeta runs, and its cow.getVariant() call was compiled when getVariant()/setVariant() were declared on AbstractCow. On 26.2 those moved down to Cow, and AbstractCow is now an empty interface:
$ javap -p org/bukkit/entity/AbstractCow.class # paper-api 26.2.build.92-stable
public interface org.bukkit.entity.AbstractCow extends org.bukkit.entity.Animals {
}
$ javap -p org/bukkit/entity/Cow.class
public interface org.bukkit.entity.Cow extends org.bukkit.entity.AbstractCow {
public abstract org.bukkit.entity.Cow$Variant getVariant();
public abstract void setVariant(org.bukkit.entity.Cow$Variant);
...
}
setEntityMeta has the same cow.setVariant(...) call, so rollbacks that restore a cow variant would presumably hit this too.
Something that argues against the above
I want to flag this clearly, because it suggests the explanation may be incomplete.
I tried patching Bukkit_v26_2 to override both methods, recompiled against paper-api 26.2.build.92-stable, and confirmed in the resulting bytecode that the call targets the new location:
15: invokeinterface #32, 1 // InterfaceMethod org/bukkit/entity/Cow.getVariant:()Lorg/bukkit/entity/Cow$Variant;
With that class in place the error persisted, unchanged, now attributed to my override's line rather than the inherited one — still naming AbstractCow.getVariant(), even though the compiled method contains no reference to AbstractCow at all.
Things I ruled out:
- Only one jar on the server contains
net/coreprotect/ classes, so no duplicate/shaded copy
- The runtime
paper-api is byte-identical to the one I compiled against (same md5), and declares getVariant() on Cow
paper-api 26.1.2 also declares it on Cow, so a stale API on the classpath would not produce this message either
- No Paper remapped-plugin cache present
I reverted to the stock build and I'm not claiming to understand it. Someone familiar with how the Bukkit_vX adapters are selected and loaded will likely see the cause faster than I did — I'm reporting the crash and my observations rather than a confident diagnosis.
Summary
Every cow death throws
NoSuchMethodErroron Minecraft 26.2, so the death is never logged and a stack trace is printed each time. 81 occurrences over four days on a normal survival server.Versions
24.0(dev buildb92)26.2(build 92,paper-api-26.2.build.92-stable)Stack trace
Reproduction
/co lookupChickens and pigs appear unaffected.
What seems to be happening
Bukkit_v26_2extendsBukkit_v1_21_5and overrides neithergetEntityMetanorsetEntityMeta:So the inherited
Bukkit_v1_21_5.getEntityMetaruns, and itscow.getVariant()call was compiled whengetVariant()/setVariant()were declared onAbstractCow. On 26.2 those moved down toCow, andAbstractCowis now an empty interface:setEntityMetahas the samecow.setVariant(...)call, so rollbacks that restore a cow variant would presumably hit this too.Something that argues against the above
I want to flag this clearly, because it suggests the explanation may be incomplete.
I tried patching
Bukkit_v26_2to override both methods, recompiled againstpaper-api 26.2.build.92-stable, and confirmed in the resulting bytecode that the call targets the new location:With that class in place the error persisted, unchanged, now attributed to my override's line rather than the inherited one — still naming
AbstractCow.getVariant(), even though the compiled method contains no reference toAbstractCowat all.Things I ruled out:
net/coreprotect/classes, so no duplicate/shaded copypaper-apiis byte-identical to the one I compiled against (same md5), and declaresgetVariant()onCowpaper-api 26.1.2also declares it onCow, so a stale API on the classpath would not produce this message eitherI reverted to the stock build and I'm not claiming to understand it. Someone familiar with how the
Bukkit_vXadapters are selected and loaded will likely see the cause faster than I did — I'm reporting the crash and my observations rather than a confident diagnosis.