oracle/graal · error · GraalError

Resolution of %s constant pool entries not supported by %s

Error message

Resolution of %s constant pool entries not supported by %s

What it means

The constant-pool parser tolerates MethodHandle, MethodType, Dynamic, and InvokeDynamic entries by skipping their bytes and recording a ClassfileConstant.Unsupported placeholder. If anything later actually needs to load the referenced type of such an entry, loadReferencedType throws GraalError naming the entry kind and ClassfileBytecodeProvider.

Source

Thrown at compiler/src/jdk.graal.compiler/src/jdk/graal/compiler/replacements/classfile/ClassfileConstant.java:277

        final String value;

        Utf8(String value) {
            super(CONSTANT_Utf8);
            this.value = value;
        }
    }

    static class Unsupported extends ClassfileConstant {
        final String name;

        Unsupported(byte tag, String name) {
            super(tag);
            this.name = name;
        }

        @Override
        public void loadReferencedType(ClassfileConstantPool cp, int index, int opcode) {
            throw new GraalError("Resolution of " + name + " constant pool entries not supported by " + ClassfileBytecodeProvider.class.getSimpleName());
        }
    }

    static ResolvedJavaMethod resolveMethod(ClassfileBytecodeProvider context, ResolvedJavaType c, String name, String descriptor, boolean isStatic) {
        ResolvedJavaMethod method = context.findMethod(c, name, descriptor, isStatic);
        if (method != null) {
            return method;
        }
        if (!c.isJavaLangObject() && !c.isInterface()) {
            method = resolveMethod(context, c.getSuperclass(), name, descriptor, isStatic);
            if (method != null) {
                return method;
            }
        }
        for (ResolvedJavaType i : c.getInterfaces()) {
            method = resolveMethod(context, i, name, descriptor, isStatic);
            if (method != null) {
                return method;

View on GitHub (pinned to a66e9ccd1d)

Solutions

Eliminate the construct that created the entry (lambda -> anonymous class, method reference -> direct call, '+' concat -> StringBuilder).
Verify the cleaned class with javap -c: no invokedynamic/CONSTANT_MethodHandle entries should remain in snippet classes.

Defensive patterns

Strategy: validation

Prevention

Avoid MethodHandle/MethodType/condy usage in any class processed by ClassfileBytecodeProvider.
Treat this error and the INVOKEDYNAMIC ones as one root cause: rewrite the snippet without indy constructs.

When it happens

Trigger: A class parsed by ClassfileBytecodeProvider contains method-handle/method-type/condy/indy entries AND the graph builder forces eager loading of the types those entries reference (the usual trigger is lambda or method-reference code inside snippet classes).

Common situations: Same family as the INVOKEDYNAMIC errors: functional-interface sugar, indy string concat, or MethodHandle use inside replacements/snippets re-parsed from class files.

Related errors

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