quarkusio/quarkus · error · RuntimeException

Unable to handle class: ${applicationClass}

Error message

Unable to handle class: ${applicationClass}

What it means

After selecting the Application class, the scanner instantiates it via TCCL loadClass + newInstance to read its getClasses()/getSingletons() output. If loading, constructing, or reflectively invoking the class fails (ClassNotFoundException, InstantiationException, IllegalAccessException, NoSuchMethodException, InvocationTargetException), the underlying cause is wrapped in this RuntimeException.

Source

Thrown at independent-projects/resteasy-reactive/common/processor/src/main/java/org/jboss/resteasy/reactive/common/processor/scanning/ResteasyReactiveScanner.java:120

                application = (Application) appClass.getConstructor().newInstance();
                Set<Class<?>> classes = application.getClasses();
                if (!classes.isEmpty()) {
                    for (Class<?> klass : classes) {
                        allowedClasses.add(klass.getName());
                    }
                    filterClasses = true;
                }
                classes = application.getSingletons().stream().map(Object::getClass).collect(Collectors.toSet());
                if (!classes.isEmpty()) {
                    for (Class<?> klass : classes) {
                        allowedClasses.add(klass.getName());
                        singletonClasses.add(klass.getName());
                    }
                    filterClasses = true;
                }
            } catch (ClassNotFoundException | InstantiationException | IllegalAccessException | NoSuchMethodException
                    | InvocationTargetException e) {
                throw new RuntimeException("Unable to handle class: " + applicationClass, e);
            }
            // collect default behaviour, making sure that we don't have multiple contradicting annotations
            int numAnnotations = 0;
            if (applicationClassInfo.hasDeclaredAnnotation(ResteasyReactiveDotNames.BLOCKING)) {
                blocking = BlockingDefault.BLOCKING;
                numAnnotations++;
            }
            if (applicationClassInfo.hasDeclaredAnnotation(ResteasyReactiveDotNames.NON_BLOCKING)) {
                blocking = BlockingDefault.NON_BLOCKING;
                numAnnotations++;
            }
            if (applicationClassInfo.hasDeclaredAnnotation(ResteasyReactiveDotNames.RUN_ON_VIRTUAL_THREAD)) {
                blocking = BlockingDefault.RUN_ON_VIRTUAL_THREAD;
                numAnnotations++;
            }
            if (numAnnotations > 1) {
                throw new DeploymentException("JAX-RS Application class '" + applicationClassInfo.name()
                        + "' contains multiple conflicting @Blocking, @NonBlocking and @RunOnVirtualThread annotations.");

View on GitHub (pinned to e1c734241f)

Solutions

1. Ensure the Application class has a public no-argument constructor.
2. Check the wrapped cause (getCause()) and fix the exception thrown inside the Application constructor.
3. Verify the Application class and everything it references are on the runtime classpath.
4. Remove heavy initialization from the constructor; keep it side-effect free.

Example fix

// before
class MyApp extends Application {
    MyApp(SomeService s) { ... } // no no-arg ctor
}
// after
class MyApp extends Application {
    public MyApp() { }
}

Class<?> c = Class.forName(appClassName, false, loader);
if (!Application.class.isAssignableFrom(c)) throw new IllegalStateException("Not an Application");
if (c.getConstructors().length == 0 || java.lang.reflect.Modifier.isPublic(c.getModifiers()) == false)
    throw new IllegalStateException("Application needs a public no-arg ctor");

try {
    new MyApp();
} catch (ExceptionInInitializerError | NoClassDefFoundError | InvocationTargetException e) {
    log.error("Application class init failed", e.getCause());
}

When it happens

Trigger: scanForApplicationClass calls Thread.currentThread().getContextClassLoader().loadClass(applicationClass) and appClass.getConstructor().newInstance(), and any of those reflective steps throws.

Common situations: Application class has no public no-arg constructor; its constructor throws (e.g. depends on an uninitialized service); class references classes missing from the runtime classpath; classloader cannot see the class in the current thread context.

Related errors

• Unable to handle class: ${applicationClass}
• The class (${name}) cannot be created during deployment.
• Failed to load the condition class ${testClassName} for capa
• Invalid Flyway callback. It shouldn't be abstract and must h
• Unable to load class [<className>]

AI-assisted analysis of quarkusio/quarkus@e1c734241f (2026-09-05). Data as JSON: /api/errors/96fc22d5625588c7. Report an issue: GitHub.