junit-team/junit5 · error · JUnitException

This class must not be instantiated

Error message

This class must not be instantiated

What it means

Thrown as a JUnitException by the private constructor of the inner sentinel class MethodOrderer.Default. Like ClassOrderer.Default, this class exists only to be referenced by Class literal in @TestMethodOrder(MethodOrderer.Default.class) to mean 'use the configured default method orderer'; it is a marker and must never be instantiated.

Source

Thrown at junit-jupiter-api/src/main/java/org/junit/jupiter/api/MethodOrderer.java:151

	 * ordering should be applied.
	 *
	 * <p>If the {@value #DEFAULT_ORDER_PROPERTY_NAME} is set, specifying this
	 * {@code MethodOrderer} has the same effect as referencing the configured
	 * class directly. Otherwise, it has the same effect as not specifying any
	 * {@code MethodOrderer}.
	 *
	 * <p>This class can be used to reset the {@code MethodOrderer} for a
	 * {@link Nested @Nested} class and its {@code @Nested} inner classes,
	 * recursively, when a {@code MethodOrderer} is configured using
	 * {@link TestMethodOrder @TestMethodOrder} on an enclosing class.
	 *
	 * @since 6.0
	 */
	@API(status = EXPERIMENTAL, since = "6.0")
	final class Default implements MethodOrderer {

		private Default() {
			throw new JUnitException("This class must not be instantiated");
		}

		@Override
		public void orderMethods(MethodOrdererContext context) {
			// never called
		}
	}

	/**
	 * {@code MethodOrderer} that sorts methods alphanumerically based on their
	 * names using {@link String#compareTo(String)}.
	 *
	 * <p>If two methods have the same name, {@code String} representations of
	 * their formal parameter lists will be used as a fallback for comparing the
	 * methods.
	 *
	 * @since 5.7
	 */

View on GitHub (pinned to 956246301e)

Solutions

1. Reference by literal: @TestMethodOrder(MethodOrderer.Default.class); never call new MethodOrderer.Default().
2. When scanning for MethodOrderer subtypes, skip classes named 'Default' or with a private constructor.
3. Pass a supplier/factory rather than reflectively instantiating arbitrary subtypes.

Example fix

// before
MethodOrderer o = ReflectionSupport.newInstance(MethodOrderer.Default.class);

// after
@TestMethodOrder(MethodOrderer.Default.class)
class MyTests {}

Class<?> candidate = /* scanned MethodOrderer */;
if (candidate == org.junit.jupiter.api.MethodOrderer.Default.class) {
    return; // sentinel, do not instantiate
}

static boolean isInstantiableOrderer(Class<?> c) {
    return MethodOrderer.class.isAssignableFrom(c)
        && c != MethodOrderer.Default.class
        && !Modifier.isAbstract(c.getModifiers());
}

When it happens

Trigger: Reflective instantiation of MethodOrderer.Default (ReflectionSupport.newInstance / Constructor.newInstance after setAccessible). Normal @TestMethodOrder usage references only the .class literal.

Common situations: Generic reflective factory code that tries to instantiate every MethodOrderer subtype found on the classpath; copying an instantiation pattern from a real orderer (MethodName, OrderAnnotation, Random) onto the Default marker.

Related errors

• This class must not be instantiated
• LocaleProvider instance could not be constructed because of
• Could not instantiate TimeZoneProvider because of exception
• Assumption failed:
• Assumption failed

AI-assisted analysis of junit-team/junit5@956246301e (2026-08-04). Data as JSON: /data/errors/c890217f133d30f9.json. Report an issue: GitHub.