What the error means
Java's own documentation describes NoSuchMethodError as thrown when an application calls a method that a class no longer has, and notes that the compiler normally catches this: it can only happen at run time if a class has changed incompatibly since the calling code was built.
On a modded server that change is usually a version mismatch. A mod was compiled against one version of Minecraft, the loader or a library mod, and a different version is installed. The error can appear during startup or later, the first time the code that makes the call runs.
The three spellings
| What the log says | What is missing |
|---|---|
| java.lang.NoSuchMethodError | A method the caller expected. The class is there; the method is not, or it has a different signature. |
| java.lang.NoSuchFieldError | A field the caller expected, for example a named constant. |
| java.lang.AbstractMethodError | A method the mod itself should provide. The interface it implements gained a method after the mod was built, and the mod has no version of it. |
The text after the colon names the missing member and the class that was supposed to own it. Depending on the Java version it is printed as a Java-style signature in quotes, such as 'void com.example.lib.Api.doThing(int)', or in the JVM's descriptor form, such as com.example.lib.Api.doThing(I)V. Both carry the same two facts: the owner class and the member.
Read the owner, then the caller
- Find the first NoSuchMethodError, NoSuchFieldError or AbstractMethodError in the crash report or latest.log. If it is wrapped in another exception, look for the Caused by: line that carries it.
- Read the owner's package. It tells you which side changed (see the table below).
- Read the first line beginning at under the error that is not in a java., net.minecraft. or loader package. That frame is the code that made the call, and its package belongs to the mod that is out of step. One exception: if the line directly under the error is in a net.minecraft class but its method name starts with handler$, that code was added to Minecraft by a mod's mixin, and the mod in the next frame may be an innocent caller. Treat that case as a mixin problem and find which mod patches that class.
- Match that package to a jar in your mods folder. Stack traces on modern Forge and NeoForge often end each line with the jar name in square brackets, which saves the search.
| Owner of the missing member | What changed | Usual fix |
|---|---|---|
| net.minecraft or com.mojang | The Minecraft version. The mod was built for a different release. | Install the mod's build for your exact Minecraft version. |
| net.minecraftforge, net.neoforged, net.fabricmc or org.quiltmc | The loader version, or the loader itself. | Use the loader version the pack specifies, and the mod's build for that loader. |
| Another mod's package | A library mod is a different version from the one the calling mod was built against. | Match the library to the version the caller needs, or the caller to the library you have. |
| sun.security or jdk.internal | The Java runtime. Usually an old loader build on a newer Java. | A newer build of the loader for the same Minecraft version, not a different mod. |
Tip
Two copies of the same library in the mods folder can produce the same errors when the copy that loads is not the one a mod was built against. Sort the folder by name and look for the same mod twice before downloading anything.
Two copies of one mod usually stop a Forge or NeoForge server earlier, with a duplicate-mod error of its own.
Read the duplicate mods guideHow to fix it
- Back up the world folder first. Everything below swaps jars, and the backup is what makes that reversible.
- Identify the caller (the out-of-step mod) and the owner (what it expected) with the steps above.
- If the owner is Minecraft or the loader, replace the caller with the build published for your exact Minecraft version and loader.
- If the owner is another mod, check the caller's page for the version of that library it needs, then install that version, or a build of the caller made for the library you have.
- If the error started right after you updated one mod, roll that mod back to the version you had. The mods that depend on it were built against the old one.
- If the pack shipped this way and fails on first boot, reinstall it cleanly before blaming a mod. A pack that was partly updated by hand produces exactly this error.
Warning
Deleting the library usually swaps this error for a missing-dependency one, because the mods that need it still need it. Fix the version, not the presence.
What MineXHost's launcher does with this crash
MineXEngine, our launcher, matches all three spellings with one crash pattern and handles them conservatively, because blaming the wrong jar here would be worse than blaming none. It only attributes the crash to a mod when the stack trace clearly involves one: a jar in the mods folder, or a frame outside Minecraft, the loaders, the Mixin library and Java itself. A trace that sits entirely in that code is not pinned on any mod.
When the missing method belongs to Minecraft, the engine first looks at the mod whose code made the call, the first frame directly under the error, and names that jar when exactly one jar in the mods folder contains that class. On a customer server it then goes on to read the rest of the stack trace as well, so your console can name more than one jar. Treat every jar it names as a suspect to check, starting with the one that made the call. When the missing member belongs to Java's own internals (sun.security or jdk.internal), it does not blame the mod that happened to be loading at that moment, because the fault lies between the loader and the Java runtime.
On your server, nothing is removed for you for this crash. Crash recovery is identify-only on customer servers: the engine names the jar in your console as the one to update or remove, and leaves your mods folder as you installed it. For this crash, the one exception is a client-only mod that fails while the loader is constructing mods (the invalid dist DEDICATED_SERVER case): such a mod can never load on a dedicated server, so it is moved to mods/.quarantined/, where you can move it back.
One case it stops on rather than retrying: a missing method or field inside Forge's own FML classes means a mod and that Forge build cannot run together, and nothing on the server side changes that, so the engine ends the attempt and reports the crash instead of restarting into it again.
Not every pack boots on a server. Our test results page shows how many public modpacks pass on each MineXEngine version, and how they were tested.
See the modpack test resultsMineXHost runs Forge, NeoForge, Fabric and Quilt packs on MineXEngine. Our launcher detects the modpack, picks the right Minecraft loader and Java version, tunes the JVM for your RAM, and auto-recovers from the crashes that normally end a modded server's evening. Pick your RAM, paste the pack, and play.
See hosting plansFrequently asked questions
What does java.lang.NoSuchMethodError mean in Minecraft?
A java.lang.NoSuchMethodError in Minecraft means a mod called a method that the installed version of Minecraft, the loader or another mod does not have, because the mod was built against a different version of that code. The error names the missing method and its owner class, and the first mod frame in the stack under it names the mod that made the call. The fix is matching versions, not more memory or a restart.
How do I find which mod causes a NoSuchMethodError?
Find the error in the crash report, then read the first line beginning with at beneath it whose package is not Java, Minecraft or the loader, because that frame is the code that made the call and its package belongs to the mod at fault. Match the package to a jar in your mods folder. Modern Forge and NeoForge traces often print the jar name in square brackets at the end of the line.
What is the difference between NoSuchMethodError and NoSuchFieldError?
NoSuchMethodError means the missing piece is a method and NoSuchFieldError means it is a field, such as a named constant, but both have the same cause: code built against one version of a class is running against another version that no longer has that member. AbstractMethodError is the third of the family, raised when a mod lacks a method that a newer interface expects. All three are fixed by matching versions.
Why did NoSuchMethodError start after I updated one mod?
Updating one mod can cause NoSuchMethodError because other mods in the pack were built against its old version, and a library that renames or removes a method breaks every mod still calling the old name. Roll the updated mod back to the version you had, or update the mods that depend on it to builds made for the new version. Updating a single library inside a finished modpack is a common way to trigger this.
Does MineXHost remove the mod that causes a NoSuchMethodError?
MineXHost does not remove the mod on a customer server: MineXEngine traces the error to the jar whose code made the call and names it in your console, but crash recovery is identify-only, so your mods folder stays as you installed it. The engine attributes the crash only when the trace clearly involves a mod, and it does not blame a mod for a fault between the loader and Java. For this crash, the one exception to identify-only is a client-only mod that fails during mod construction, which is moved to mods/.quarantined/.