skip to content

What is the difference between @AutoConfigureBefore/@AutoConfigureAfter and @AutoConfigureOrder?

level: middleimportance: should knowfreq 40%

answer

  1. Before/After = relational to a named class
  2. Order = absolute int, lower first, default 0
  3. Sorter: alphabetical -> order -> before/after topological
  4. Before/after applied last => wins over order
  5. @Order semantics: low value = high priority

basics

~10 s

@AutoConfigureBefore/After express a relationship to a specific named auto-config class. @AutoConfigureOrder is a coarse numeric priority (lower runs earlier, default 0), like @Order, with no reference to any particular class.

solid answer

~40 s

@AutoConfigureBefore(X.class) and @AutoConfigureAfter(X.class) are *relative* constraints: 'process me before/after X' where X is another auto-configuration class. @AutoConfigureOrder(int) is an *absolute* priority number — lower means earlier, default 0 — analogous to @Order, and it does not point at any specific class. They also apply at different stages of AutoConfigurationSorter: it first sorts alphabetically by class name for determinism, then re-sorts by @AutoConfigureOrder, then finally enforces the before/after constraints via a topological sort. So before/after wins over order when they conflict, because it is applied last. Use before/after when your class genuinely depends on another class being processed first; use order only for a broad 'this whole family should tend to run early/late' nudge. Prefer explicit relationships — order values are brittle and easy to collide.

code

java · 8 lines
java
// Relational: I must be processed after DataSourceAutoConfiguration
@AutoConfiguration(after = DataSourceAutoConfiguration.class)
public class CacheWarmerAutoConfiguration { }

// Positional: coarse priority; lower value = earlier. Default is 0.
@AutoConfiguration
@AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE) // Integer.MIN_VALUE => runs very early
public class EarlyAutoConfiguration { }

go deeper

for a junior

May only know both exist without the sorter detail.

for a middle

Should articulate relational vs positional and the low-value-first rule.

for a senior

Should know the three sorter stages and that before/after is applied last.

for a principal

Should advise teams to prefer explicit relationships and avoid order-value collisions across starters.

**Two different kinds of ordering input.** - `@AutoConfigureBefore` / `@AutoConfigureAfter` are **relational**: they name *other auto-configuration classes* (by `Class` via `value`, or by string via `name`/`beforeName`/`afterName`). They say nothing about global position — only 'me relative to that one'. - `@AutoConfigureOrder(int)` is **positional/priority-based**: a single integer, **lower = earlier**, default `0`, exactly like `org.springframework.core.annotation.Order`. It has no target class. **How AutoConfigurationSorter combines them.** The sorter builds the final order in three passes: 1. **Alphabetical by fully-qualified class name** — establishes a deterministic baseline so the result never depends on classpath scan order. 2. **Sort by `@AutoConfigureOrder`** — reorders the alphabetical list by priority value. 3. **Topological sort applying `@AutoConfigureBefore`/`@AutoConfigureAfter`** — walks the constraint graph and emits classes respecting every before/after edge. Because the before/after topological pass runs **last**, an explicit before/after relationship effectively overrides a mere order value when they disagree. Within any set of classes that the constraints leave unordered, the earlier alphabetical + order result is preserved (stable sort). **Why the alphabetical baseline exists.** Without it, two auto-config classes with no constraints between them could be emitted in whatever order the classpath happened to yield — non-reproducible builds and flaky conditional back-off. Alphabetical fallback makes 'unconstrained' still mean 'deterministic'. **Choosing between them.** - Reach for **before/after** when correctness depends on a specific other class (e.g., your bean uses `@ConditionalOnMissingBean` against a bean another auto-config defines — you must be processed *after* it, or *before* it if you want to win). - Reach for **@AutoConfigureOrder** only for coarse grouping where no single class is the anchor (rare in app code; more common inside framework internals). **Gotchas.** - `@AutoConfigureOrder` default is `0`, and lower runs first — people frequently invert this (it is *not* 'higher = more important'). - Mixing a numeric order that fights an explicit before/after constraint is confusing; the constraint wins, so the order value looks 'ignored'. - All of this only affects auto-configuration classes, and referenced classes must themselves be auto-configurations.

  • If a class has both a low @AutoConfigureOrder and an @AutoConfigureAfter that conflict, which wins?
    The @AutoConfigureAfter constraint. The topological before/after pass runs last in AutoConfigurationSorter, so it overrides the position implied by the order value.
  • For @AutoConfigureOrder, does a higher number run earlier?
    No. Like @Order, lower values have higher precedence and run earlier; the default is 0.

saying these in an interview costs you the question

  • Saying higher @AutoConfigureOrder runs first (it is the opposite)
  • Claiming @AutoConfigureOrder targets a specific class like before/after does
  • Believing order value overrides an explicit before/after relationship

context

resolving links…