Introduction

This ClassNotFoundException usually means your Spring Boot and Spring Framework versions are out of alignment. The class org.springframework.core.metrics.ApplicationStartup exists in newer Spring Framework releases, so if your application or one of its dependencies expects it but an older spring-core jar ends up on the runtime classpath, the application fails during startup. The real fix is to restore dependency consistency, not to add random jars manually.

Why This Class Goes Missing

ApplicationStartup was introduced in newer generations of Spring Framework and then used by corresponding Spring Boot versions. If you are running code that expects that class but the classpath contains an older Spring Core, Java throws ClassNotFoundException when the application starts or a configuration path tries to reference it.

This typically happens in one of these situations:

• Boot version upgraded, but transitive Spring dependencies were pinned manually to older versions
• multiple Spring versions appear in the dependency graph
• a parent BOM is missing or overridden incorrectly
• an old container or fat jar is still being used at runtime

So the problem is usually dependency resolution, not the source code that mentions ApplicationStartup.

Let Spring Boot Manage Spring Versions

The simplest protection is to let Spring Boot manage the Spring dependency set through its BOM or starter parent.

A normal Maven setup looks like this:

1<parent>
2    <groupId>org.springframework.boot</groupId>
3    <artifactId>spring-boot-starter-parent</artifactId>
4    <version>2.7.18</version>
5    <relativePath/>
6</parent>
7
8<dependencies>
9    <dependency>
10        <groupId>org.springframework.boot</groupId>
11        <artifactId>spring-boot-starter-web</artifactId>
12    </dependency>
13</dependencies>

The important point is not that exact version. The important point is that Boot should control the matching Spring versions unless you have a very strong reason to override them.

Find the Actual Version Conflict

When this exception appears, inspect the resolved dependency graph instead of guessing.

For Maven:

mvn dependency:tree | grep spring-core

For Gradle:

./gradlew dependencies --configuration runtimeClasspath

You are looking for multiple Spring versions or an older spring-core that should not be there. In a healthy Boot application, the Spring jars should line up consistently with the Boot release.

A Typical Bad Configuration

A common anti-pattern is mixing Boot starters with manually pinned Spring dependencies.

1<dependency>
2    <groupId>org.springframework</groupId>
3    <artifactId>spring-core</artifactId>
4    <version>5.2.0.RELEASE</version>
5</dependency>

If the Boot version expects a newer Spring release, this manual pin can quietly downgrade the runtime classpath and trigger the missing-class error.

In most Boot apps, the clean fix is to remove that manual Spring version override.

Clean and Rebuild the Runtime Artifact

Sometimes the dependency graph is fixed but the running artifact is stale. Rebuild the application completely and make sure the deployed JAR or container image actually contains the new dependency set.

A clean rebuild helps rule out leftover packaging issues:

mvn clean package

or:

./gradlew clean bootJar

This matters especially when Docker layers, CI caches, or older fat JARs can keep the wrong runtime in circulation.

Watch for IDE and Test Classpaths Too

The application may succeed from the command line but fail in the IDE, or the reverse, if different classpaths are used. Tests can also pull in different dependency combinations from the main runtime.

So check the failing environment specifically:

• production runtime
• local IDE launch
• test runtime
• container image

The same exception message can come from different dependency graphs in each of those contexts.

Do Not Fix This by Copying One Class or Jar

A tempting but incorrect response is to manually add one Spring jar until the missing class disappears. That is risky because Spring modules are version-coupled. If one class is missing due to version skew, there are often more incompatibilities waiting behind it.

The durable solution is to get the whole Spring stack back onto a compatible set.

Common Pitfalls

The most common mistake is manually overriding Spring Framework module versions in a Spring Boot application that should be using Boot-managed dependencies.

Another mistake is checking only compile-time dependencies and not the runtime artifact that actually gets launched.

Teams also fix the build file but forget to rebuild or redeploy the final JAR or container image, leaving the stale classpath in place.

Summary

• This exception usually means Spring Boot and Spring Framework versions are out of sync.
• 'ApplicationStartup is present only in newer Spring versions expected by matching Boot releases.'
• Let Spring Boot manage Spring dependency versions whenever possible.
• Inspect the dependency tree to find older spring-core jars or version conflicts.
• Fix the dependency set as a whole, then cleanly rebuild the artifact that is actually running.