What causes "Couldn't find method bridged by %s:%n%s" in oracle/graal?

Report a Graal issue including the exception and the disassembly text embedded in the message — it shows exactly the malformed bridge bytecode.

oracle/graal · error · InternalError

Couldn't find method bridged by %s:%n%s

Error message

Couldn't find method bridged by %s:%n%s

What it means

BridgeMethodUtils.getBridgeTarget scans a bridge method's bytecode for the INVOKESPECIAL/invokevirtual call to the method it forwards to; if no such call is found it throws this InternalError with a full disassembly of the bridge. It means the method was marked as a bridge (ACC_BRIDGE) by the class file producer, but its bytecode does not follow the javac bridge-method idiom Graal's scanner understands.

Source

Thrown at compiler/src/jdk.graal.compiler/src/jdk/graal/compiler/bytecode/BridgeMethodUtils.java:101

                        bridged = method;
                    } else if (method.getName().equals("<init>") && method.getDeclaringClass().getName().equals("Ljava/lang/AbstractMethodError;")) {
                        calledAbstractMethodErrorConstructor = true;
                    }
                    break;
                }
                case ATHROW: {
                    if (calledAbstractMethodErrorConstructor) {
                        // This is a miranda method
                        return null;
                    }
                }
            }
            stream.next();
            opcode = stream.currentBC();
        }
        if (bridged == null) {
            String dis = new BytecodeDisassembler().disassemble(bridge);
            throw new InternalError(String.format("Couldn't find method bridged by %s:%n%s", bridge.format("%R %H.%n(%P)"), dis));
        }
        return bridged;
    }

    @SuppressWarnings("all")
    private static boolean assertionsEnabled() {
        boolean enabled = false;
        assert enabled = true;
        return enabled;
    }

    /**
     * A helper that handles the absence of annotations on bridge methods where the bridged method
     * has annotations.
     */
    public static AnnotationValue getAnnotation(Class<? extends Annotation> annotationClass, ResolvedJavaMethod method) {
        AnnotationValue a = AnnotationValueSupport.getAnnotationValue(method, annotationClass);
        if (a == null && method.isBridge()) {

View on GitHub (pinned to a66e9ccd1d)

Solutions

Report a Graal issue including the exception and the disassembly text embedded in the message — it shows exactly the malformed bridge bytecode.
Identify the offending class from the '%H.%n(%P)' method descriptor in the message and check which tool generated it (Kotlin/Scala/instrumentation agent); upgrade or re-emit that library so bridges follow the standard idiom.
As a workaround, exclude the enclosing method or class from Graal compilation (-XX:CompileCommand=exclude) since reflection/bridge resolution paths may still work on the interpreter/C1.
If an instrumentation/coverage agent is attached, try disabling it to confirm it rewrote the bridge body.

Defensive patterns

Strategy: try-catch

Try / catch

ResolvedJavaMethod bridged = null;
try {
    bridged = BridgeMethodUtils.getBridgeTarget(bridge);
} catch (InternalError e) {
    // log the embedded disassembly and skip bridge optimization for this method
    LOG.warn("Unresolvable bridge: {}", e.getMessage(), e);
}

Prevention

When processing third-party bytecode defensively, wrap bridge-target resolution and degrade to plain reflection on failure.
Pin known-good versions of bytecode-transforming agents (coverage, obfuscators) in your build.
Include Kotlin/Scala-generated classes in compiler test corpora to catch bridge-idiom drift early.

When it happens

Trigger: Calling BridgeMethodUtils.getBridgeTarget(ResolvedJavaMethod) on a method with the ACC_BRIDGE flag whose body does not contain the expected call to the bridged method — e.g. miranda-method shapes that were already handled, bridges generated by non-javac compilers, or class files produced by newer/obfuscated toolchains whose bridge bodies were rewritten (dead-code elimination, stack-map rewriting, or security-manager-era accessor bodies).

Common situations: Running Graal on classes produced by Kotlin, Scala, Groovy, Android/D8-processed bytecode, coverage or instrumentation agents that strip or rewrite bridge bodies, or on class file versions whose compiler emits a new bridge idiom. Also seen after JVM/JDK upgrades that change how javac generates bridges for covariant returns or generic overrides.

Related errors

AI-assisted analysis of oracle/graal@a66e9ccd1d (2026-08-14). Data as JSON: /api/errors/262059311821d2e5. Report an issue: GitHub.