Anticheat Plugin Won't Start: PacketEvents and Java Errors

How do I fix an anticheat that will not start?

An anticheat that will not enable usually has one of four causes. PacketEvents is missing or is the wrong release, the Java runtime does not match your server software, the server jar is not the build you meant to run, or plugins load in an order that breaks a dependency. Check them in that order, starting with the first error in the console.

Step 1: Confirm PacketEvents is present and correct

FairPlay's install guide states: "PacketEvents is required to run FairPlay." Check that both jars are in the same plugins folder before the first start.

• Open the plugins folder and confirm the PacketEvents jar and the anticheat jar are both present.
• Download PacketEvents from its official release page. The FairPlay listing links to PacketEvents on Modrinth.
• Use the release that the anticheat and PacketEvents docs recommend. A mismatched release is a common cause of class-loading errors.
• Remove duplicate copies of either plugin, since two copies of one plugin can conflict.

Step 2: Check the Java runtime

Confirm which Java runtime starts the server, then compare it with the minimum your server software requires and with both plugins' release notes. This article does not list a Java version for FairPlay or PacketEvents, so read those notes rather than trusting a number from a forum.

java -version

Step 3: Confirm you run the right server jar

A plugin built for one server platform may fail on another. Check the start script or service file to see which jar it launches, then confirm that jar matches the platform your anticheat release lists. Folia has its own compatibility requirements, so read the Folia guidance before you start a Folia server.

Wrong-jar problems often come from a leftover script that still points at an old file after an upgrade. Search the start script and any service unit for the jar name, and make sure only one server jar sits in the folder the script uses.

Step 4: Read the startup log

Work through the log in this order. Restart the server only after you have saved the log from the failed start.

• Stop the server, then copy logs/latest.log to a dated file so the next start does not overwrite it.
• Find the first line marked WARN, ERROR, or SEVERE that names the anticheat or PacketEvents. Later errors often follow from that first one.
• Find the exception class name and any Caused by line under it.
• Match the exception to a cause. A NoClassDefFoundError or ClassNotFoundError points to a missing dependency or a version mismatch. An UnsupportedClassVersionError points to a Java runtime that is older than the build requires. A line about an invalid plugin description or a plugin that could not load points to a wrong or corrupt jar.
• Record the server software, build, Java version, and the versions of both plugins.

Step 5: Fix load order and dependencies

Change one thing at a time. After each change, restart and read the first error again. If you change several things at once, you cannot tell which one fixed the problem.

Confirm that PacketEvents enables before the anticheat in the startup log. If PacketEvents shows its own errors, fix those first, because the anticheat cannot start without it.

Do not infer load order from jar file names. Read the enable lines in the log for each plugin on your server, because that log is the record of what actually loaded.

Step 6: Escalate with a useful report

Send the seller or project support the first error, the full log file, your server software and build, the Java version, the plugin versions, and the steps you already tried. A report with those items lets support reproduce the problem instead of asking for them.

Attach the log from the failed start, not a log from a later restart. A later log may show a clean start after you changed something, which hides the original cause.

How do I know the anticheat is actually active?

After a clean start, check the anticheat's own status output before you trust it. Run its help or status command with a staff account, then confirm that the checks you expect are listed and enabled. A plugin that enabled but has a disabled check group behaves differently from one with every check on.

Then join with a clean test account and perform one legit action per check group. Expect no alerts, and confirm that a deliberately suspicious test on staging produces the alert you expect. This takes longer than reading the log, but it is the step that shows the plugin is doing its job.

What have we not verified?

We have not tested these steps against specific server builds, so the log wording in your console may differ. The FairPlay statements in this article come from its installation documentation. Startup success does not show that alerts are correct. Test legit and cheat cases on staging afterward.