alibaba/nacos · error · NestedIoException

ASM ClassReader failed to parse class file - probably due to

Error message

ASM ClassReader failed to parse class file - probably due to a new Java class file version that isn't supported yet: {resource}

What it means

Thrown by DefaultPackageScan.getClassReader() when ASM's ClassReader cannot parse a .class file, surfacing as an IllegalArgumentException from ASM that the scan wraps as NestedIoException. The classic cause is a class file compiled for a newer Java bytecode version than the bundled ASM recognizes.

Source

Thrown at common/src/main/java/com/alibaba/nacos/common/packagescan/DefaultPackageScan.java:86

                }
            }
        } catch (IOException | ClassNotFoundException e) {
            LOGGER.error("scan path: {} failed", packageSearchPath, e);
        }
        return set;
    }
    
    private Class<?> getClassByResource(Resource resource) throws IOException, ClassNotFoundException {
        String className = getClassReader(resource).getClassName();
        return Class.forName(ClassUtils.resourcePathToConvertClassName(className));
    }
    
    private static ClassReader getClassReader(Resource resource) throws IOException {
        try (InputStream is = resource.getInputStream()) {
            try {
                return new ClassReader(is);
            } catch (IllegalArgumentException ex) {
                throw new NestedIoException("ASM ClassReader failed to parse class file - "
                        + "probably due to a new Java class file version that isn't supported yet: " + resource, ex);
            }
        }
    }
    
}

View on GitHub (pinned to 9b989acdf1)

Solutions

Align the build/compile JDK target with the runtime JDK, or lower -target to a bytecode version ASM supports.
Upgrade the ASM dependency (or the transitively-pulled version) to one that supports the class file major version in use.
Exclude the offending jar/package from the scan scope so ASM never reads the unsupported class file.
Recompile the offending library against an older bytecode level if you control it.

Example fix

// before — classes compiled at bytecode 65 (JDK 21) scanned by older ASM
// -> ASM ClassReader failed to parse class file

// after — compile at a supported level
// javac --release 17 ...   or in maven:
// <maven.compiler.release>17</maven.compiler.release>

Defensive patterns

Strategy: validation

Validate before calling

// ensure compiled bytecode <= what ASM supports
// compile with --release 17, or verify ASM version supports the major version
int major = readClassMajorVersion(classFile);
if (major > ASM_SUPPORTED_MAJOR) {
    throw new IllegalStateException("class file version " + major + " too new for ASM");
}

Try / catch

try {
    scan.scan(packages);
} catch (NestedIoException e) {
    if (e.getCause() instanceof IllegalArgumentException) {
        log.error("Unsupported class file version — upgrade ASM or lower --release", e);
    }
    throw e;
}

Prevention

Pin the build --release to a bytecode level your runtime ASM supports.
Upgrade ASM when adopting a newer JDK.
Narrow scan scopes to packages you control to avoid third-party jars with newer bytecode.

When it happens

Trigger: Running a package scan (DefaultPackageScan.scan / resource scanning used to discover subscribers, plugins, or SPI types) over classes compiled with a Java version newer than the ASM library supports; scanning jars built on a newer JDK.

Common situations: Building with JDK 21+ but running Nacos/your app on a runtime whose ASM is older; depending on a third-party jar compiled with preview features or a newer class-file major version; the bundled spring/asm version predates the target JDK.

Understand the failure class

Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.

Related errors

AI-assisted analysis of alibaba/nacos@9b989acdf1 (2026-08-14). Data as JSON: /api/errors/ed483cd58a519e22. Report an issue: GitHub.