关于java.lang.VerifyError异常的求助：Jetty类重写final方法问题

Hey there, let's figure out this java.lang.VerifyError you're dealing with. First, let's look at the core issue from your stack trace:

Exception in thread "Thread-2" java.lang.VerifyError: class org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection overrides final method toString.()Ljava/lang/String;
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.n...

原因分析 #

This error is straightforward: the class org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection is trying to override a final method—specifically toString(). In Java, final methods are locked down; subclasses aren't allowed to redefine them. When the class loader validates the bytecode and spots this violation, it throws the VerifyError.

Common scenarios that cause this:

• Jetty version conflicts: Your project has multiple dependencies pulling in different versions of Jetty WebSocket components. For example, one dependency uses an older Jetty version where the parent class didn't mark toString() as final, while another uses a newer version where it does—leading to a mismatch when the subclass tries to override it.
• Bytecode manipulation gone wrong: If you're using tools like ASM, CGLIB, or any bytecode enhancement plugins, they might have accidentally modified the Jetty class's method definitions, creating this invalid override.
• Corrupted dependencies: The Jetty jar files in your local repository could be incomplete or damaged, resulting in invalid bytecode that fails validation.

解决方法 #

Here are actionable steps to fix this:

• Resolve version conflicts
  1. Use your build tool's dependency tree command to spot inconsistencies:
     • For Maven: Run mvn dependency:tree
     • For Gradle: Run ./gradlew dependencies
  2. Align all Jetty WebSocket-related dependencies (like jetty-websocket-common, jetty-websocket-api) to the same compatible version. Stick to a consistent Jetty release line (e.g., all 9.4.x or all 11.x versions).
• Check bytecode enhancement tools
  Temporarily disable any bytecode manipulation plugins or tools in your build. If the error goes away, you'll know the issue is with how those tools are modifying Jetty's classes—you'll need to configure them to exclude Jetty's packages from enhancement.
• Refresh your dependencies
  Delete the Jetty-related directories from your local repository (e.g., .m2/repository/org/eclipse/jetty for Maven) and rebuild your project. This forces your build tool to re-download fresh, uncorrupted copies of the dependencies.
• Adjust class loading order
  In some cases, incorrect class loading priority can cause an older version of Jetty's classes to load first, conflicting with newer versions. If you're running in an application server, check its class loading settings to ensure the correct Jetty version is loaded first.

内容的提问来源于stack exchange，提问作者Kadir SALKI