Spring Boot vs Spring Framework

Q: Is a Spring Boot application faster at runtime than a plain Spring application?

No. Both run the same Spring Framework code once started; Spring Boot's work happens mainly at startup. Real performance depends on choices such as pool sizes, caching, queries and JVM settings.

Q: Does Spring Boot use more memory than plain Spring?

Sometimes slightly, because starters may bring unused libraries and beans. Remove unused starters and exclude unneeded auto-configurations to close the gap, or build a GraalVM native image for a much smaller footprint.

Q: Can a Spring Boot application still use XML configuration?

Yes. Load existing XML bean definitions with @ImportResource on the main class. It is mainly useful during migration; new code is clearer with Java configuration.

Q: Does Spring Boot use different annotations from the Spring Framework?

Mostly not. Everyday annotations such as @Component, @Service, @Autowired, @RestController, @GetMapping and @Transactional come from the Spring Framework. Spring Boot adds a few of its own, including @SpringBootApplication, @ConfigurationProperties, the conditional annotations and test annotations like @SpringBootTest.

Q: How are Spring Boot and Spring Framework versions connected?

Each Spring Boot generation is built on a specific Spring Framework generation: Boot 2.x on Framework 5.x (Java 8+), Boot 3.x on Framework 6.x (Java 17+), and Boot 4.x on Framework 7.x (Java 17+). Upgrading Boot upgrades the Framework; let Boot manage that version.

Q: Can I use Spring Framework features that Spring Boot does not configure?

Yes. Spring Boot only auto-configures common features and never prevents using anything else in the Spring Framework. Declare additional beans yourself exactly as in plain Spring; mixing auto-configured and hand-written beans is normal.

Q: Do companies still use plain Spring without Spring Boot?

Yes, mainly in older applications built before Spring Boot or deployed on traditional application servers. New projects usually choose Spring Boot, and knowing Spring Boot plus the underlying Spring concepts prepares you for both.

Q: Which should I focus on for job interviews?

Learn Spring Boot to build applications and the Spring Framework to understand them. Interviews commonly cover dependency injection, bean scopes and lifecycle, transactions and AOP from Spring, plus auto-configuration, starters, Actuator and profiles from Spring Boot, and the difference between them.

Q: Does Spring Boot change how dependency injection works?

No. Dependency injection is a Spring Framework feature that Spring Boot uses unchanged. Boot simply makes more beans available, such as DataSource, JdbcTemplate and ObjectMapper, through auto-configuration, so you can inject them without defining them.

Q: Can a plain Spring application run with an embedded server, like Spring Boot?

Technically yes, by starting embedded Tomcat from your own main method and registering DispatcherServlet manually, but you must maintain that startup code, server settings and JAR packaging yourself. That rebuilds part of Spring Boot, so using Spring Boot is simpler and better tested.

“Should I learn Spring or Spring Boot?” is one of the most common questions from Java developers, and it rests on a small misunderstanding. Spring Boot is not a competitor to the Spring Framework; it is built on top of it. Every Spring Boot application is a Spring application.

This tutorial explains what each one is, shows the same application built both ways so you can see the difference in real code, compares them feature by feature, and explains when each one makes sense.

1. The Quick Answer

	Spring Framework	Spring Boot
What it is	The foundation: dependency injection, web, data access, transactions	A layer on top of Spring that sets it up for you
Main job	Provides the features	Makes those features quick and easy to use
Configuration	You write it	Mostly automatic, with sensible defaults
Runs as	A WAR file on a separate server, typically	A self-contained JAR with a built-in server
Relationship	Works on its own	Always uses the Spring Framework underneath

In one sentence: the Spring Framework provides the tools, and Spring Boot assembles and configures them for you.

2. What Is the Spring Framework?

The Spring Framework, first released in 2003, is the foundation of the Spring ecosystem. Its central idea is dependency injection: instead of objects creating the things they need, a container creates and connects them. Around that core, it offers modules for most enterprise needs:

Module	Provides
Core container	Dependency injection and the application context (beans)
AOP	Code that runs around many methods, such as logging or security checks
Data access	JDBC support, transaction management, integration with JPA and Hibernate
Spring MVC	Building web applications and REST APIs
Spring WebFlux	Reactive, non-blocking web applications
Testing	Support for testing Spring components

The Spring Framework is flexible and powerful, but it is unopinionated: it does not choose a web server, a JSON library or a connection pool for you, and it does not configure them. You decide and wire everything together yourself.

3. What Is Spring Boot?

Spring Boot, first released in 2014, is a project that makes the Spring Framework fast to use. It follows convention over configuration: if you accept sensible defaults, almost no setup is needed. It adds:

Feature	What it gives you
Auto-configuration	Configures Spring and its libraries based on what is on your classpath
Starters	Single dependencies that bring tested, compatible sets of libraries
Embedded server	Tomcat (or Jetty) built into your application; run it with `java -jar`
Externalized configuration	Settings in `application.properties`, environment variables or arguments
Actuator	Health checks, metrics and monitoring endpoints out of the box
Developer tools	Automatic restarts during development

For a beginner-friendly walkthrough, see the Spring Boot Introduction.

4. How They Fit Together

Think of a Spring Boot application as layers, each building on the one below:

Layers

┌──────────────────────────────────────────────┐
│  Your code: controllers, services, entities  │
├──────────────────────────────────────────────┤
│  Spring Boot: auto-configuration, starters,  │
│  embedded server, Actuator                   │
├──────────────────────────────────────────────┤
│  Spring Framework: dependency injection,     │
│  MVC, transactions, AOP, data access         │
├──────────────────────────────────────────────┤
│  Java (JDK)                                  │
└──────────────────────────────────────────────┘

Your code talks mostly to the Spring Framework, through annotations such as @Service, @RestController and @Transactional. Spring Boot works mostly behind the scenes, setting everything up so those annotations just work.

5. The Same Application, Built Both Ways

The clearest way to see the difference is to build the same small application twice: a REST endpoint that reads products from a PostgreSQL database.

5.1 The shared code

The controller and service are identical in both versions, because they use only Spring Framework features:

ProductController.java

@RestController
@RequestMapping("/api/products")
public class ProductController {

    private final ProductService productService;

    public ProductController(ProductService productService) {
        this.productService = productService;
    }

    @GetMapping
    public List<Product> list() {
        return productService.findAll();
    }
}

ProductService.java

@Service
public class ProductService {

    private final JdbcTemplate jdbcTemplate;

    public ProductService(JdbcTemplate jdbcTemplate) {
        this.jdbcTemplate = jdbcTemplate;
    }

    @Transactional(readOnly = true)
    public List<Product> findAll() {
        return jdbcTemplate.query("SELECT id, name, price FROM products",
                (rs, row) -> new Product(rs.getLong("id"), rs.getString("name"), rs.getBigDecimal("price")));
    }
}

5.2 With the plain Spring Framework

First, you choose every library and a compatible version yourself:

pom.xml (plain Spring)

<packaging>war</packaging>

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-webmvc</artifactId>
        <version>6.2.0</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-jdbc</artifactId>
        <version>6.2.0</version>
    </dependency>
    <dependency>
        <groupId>com.fasterxml.jackson.core</groupId>
        <artifactId>jackson-databind</artifactId>
        <version>2.18.0</version>
    </dependency>
    <dependency>
        <groupId>com.zaxxer</groupId>
        <artifactId>HikariCP</artifactId>
        <version>6.0.0</version>
    </dependency>
    <dependency>
        <groupId>org.postgresql</groupId>
        <artifactId>postgresql</artifactId>
        <version>42.7.4</version>
    </dependency>
    <dependency>
        <groupId>jakarta.servlet</groupId>
        <artifactId>jakarta.servlet-api</artifactId>
        <version>6.0.0</version>
        <scope>provided</scope>
    </dependency>
</dependencies>

Next, a class that registers Spring’s DispatcherServlet with the external server:

WebAppInitializer.java

public class WebAppInitializer extends AbstractAnnotationConfigDispatcherServletInitializer {

    @Override
    protected Class<?>[] getRootConfigClasses() {
        return new Class<?>[] { AppConfig.class };
    }

    @Override
    protected Class<?>[] getServletConfigClasses() {
        return new Class<?>[] { WebConfig.class };
    }

    @Override
    protected String[] getServletMappings() {
        return new String[] { "/" };
    }
}

Then the web configuration and the application configuration, where you create the infrastructure beans by hand:

WebConfig.java

@Configuration
@EnableWebMvc
@ComponentScan("com.javabytechie.shop.web")
public class WebConfig implements WebMvcConfigurer {
}

AppConfig.java

@Configuration
@EnableTransactionManagement
@ComponentScan("com.javabytechie.shop.service")
@PropertySource("classpath:app.properties")
public class AppConfig {

    @Bean
    public DataSource dataSource(Environment env) {
        HikariDataSource dataSource = new HikariDataSource();
        dataSource.setJdbcUrl(env.getProperty("db.url"));
        dataSource.setUsername(env.getProperty("db.username"));
        dataSource.setPassword(env.getProperty("db.password"));
        return dataSource;
    }

    @Bean
    public JdbcTemplate jdbcTemplate(DataSource dataSource) {
        return new JdbcTemplate(dataSource);
    }

    @Bean
    public PlatformTransactionManager transactionManager(DataSource dataSource) {
        return new DataSourceTransactionManager(dataSource);
    }
}

Finally, you build a WAR file and deploy it to a Tomcat server that you have installed and configured separately.

5.3 With Spring Boot

Two starters replace the whole list of dependencies, and Spring Boot chooses compatible versions:

pom.xml (Spring Boot)

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.5.0</version>
</parent>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-jdbc</artifactId>
    </dependency>
    <dependency>
        <groupId>org.postgresql</groupId>
        <artifactId>postgresql</artifactId>
        <scope>runtime</scope>
    </dependency>
</dependencies>

One small class replaces the initializer and both configuration classes:

ShopApplication.java

@SpringBootApplication
public class ShopApplication {

    public static void main(String[] args) {
        SpringApplication.run(ShopApplication.class, args);
    }
}

And the database connection is just three properties:

application.properties

spring.datasource.url=jdbc:postgresql://localhost:5432/shop
spring.datasource.username=shop
spring.datasource.password=secret

Run it with ./mvnw spring-boot:run or java -jar. There is no server to install.

5.4 What changed

	Plain Spring	Spring Boot
Dependencies to choose and version	6, each with a version	3, no versions
Configuration classes	3 (initializer, web, app)	1 (the main class)
Infrastructure beans written by hand	`DataSource`, `JdbcTemplate`, transaction manager	None
Server	Installed and configured separately	Built in
Controller and service code	Same	Same

The business code did not change at all. Spring Boot removed only the setup around it.

6. Core Differences Explained

6.1 Configuration

With the plain Spring Framework, you configure infrastructure yourself, usually with Java configuration classes; older projects often use XML. With Spring Boot, auto-configuration creates sensible defaults, and you change only what you need through properties or your own beans.

6.2 Dependency management

With plain Spring, you pick a version for every library and make sure they work together. A wrong combination can cause confusing runtime errors. Spring Boot’s starters and its managed version list give you combinations that are tested together.

6.3 Running and deploying

A classic Spring web application is packaged as a WAR file and deployed to an external server such as Tomcat or WebLogic. A Spring Boot application usually includes its server and runs as one JAR file, which fits containers and cloud platforms naturally:

Terminal

java -jar target/shop-0.0.1-SNAPSHOT.jar

6.4 Auto-configuration

Plain Spring creates only the beans you declare. Spring Boot looks at your classpath, your properties and your existing beans, and creates the missing infrastructure automatically, stepping back whenever you define something yourself. See Spring Boot Auto-Configuration for the details.

6.5 Production readiness

With plain Spring, you add health checks and metrics yourself, for example by integrating Micrometer by hand. Spring Boot Actuator adds health, metrics and info endpoints with one dependency. See the Spring Boot Actuator tutorial.

6.6 Testing

Spring Framework provides the core test support. Spring Boot adds convenient test annotations, such as @SpringBootTest, @WebMvcTest and @DataJpaTest, plus a single spring-boot-starter-test dependency that brings JUnit 5, Mockito and AssertJ.

7. Feature Comparison Table

Feature	Spring Framework	Spring Boot
Dependency injection and AOP	Yes (provides them)	Yes (uses Spring’s)
Spring MVC, transactions, data access	Yes (provides them)	Yes (configures them)
Auto-configuration	No	Yes
Starter dependencies	No	Yes
Managed library versions	Spring’s own modules only	Hundreds of libraries
Embedded web server	No (possible, but manual)	Yes, Tomcat by default
Runnable JAR	No	Yes
Externalized configuration	Basic (`@PropertySource`)	Rich: profiles, YAML, environment variables, type-safe properties
Health checks and metrics	Manual setup	Actuator
Developer tools	No	DevTools
Setup effort	High	Low
Fit for microservices and containers	Possible, more work	Excellent

8. What Stays the Same

Because Spring Boot sits on top of the Spring Framework, everything you learn about Spring applies directly:

Dependency injection, beans and the application context.
Stereotype annotations: @Component, @Service, @Repository, @Controller.
Web annotations: @RestController, @GetMapping, @RequestBody and the rest.
Transactions with @Transactional.
AOP, events, scheduling, caching and validation.

The Spring Boot Annotations tutorial covers these, and almost all of them come from the Spring Framework itself.

9. When to Use Each

Situation	Better choice	Why
A new REST API or web application	Spring Boot	Working app in minutes, production features included
Microservices or cloud deployment	Spring Boot	One runnable JAR per service; easy to containerize
Maintaining an existing classic Spring app	Keep plain Spring, or migrate gradually	Rewriting working configuration has little value on its own
Company requires deployment to an existing application server	Either; Spring Boot can also build a WAR	Spring Boot supports WAR packaging too
Building a library used inside other applications	Spring Framework modules	A library should not bring its own server or auto-configuration choices
Learning Spring today	Spring Boot	Start fast, then learn the Spring concepts underneath

For almost all new applications, the answer is Spring Boot. Plain Spring remains relevant for existing systems and for libraries.

10. Moving a Spring Application to Spring Boot

Existing Spring applications can move to Spring Boot step by step:

Upgrade to a recent Spring Framework version that matches the Spring Boot version you plan to use.
Add the Spring Boot parent and starters, and remove the individual dependency versions they now manage.
Add a main class with @SpringBootApplication in the top-level package.
Keep your existing configuration working: Java configuration classes keep working, and XML files can be loaded with @ImportResource.
Remove configuration that Spring Boot now provides, one piece at a time, such as the DataSource or the DispatcherServlet setup, testing after each step.
Move settings into application.properties.
Decide on packaging: switch to a runnable JAR, or keep a WAR by extending SpringBootServletInitializer.

LegacyShopApplication.java

@SpringBootApplication
@ImportResource("classpath:legacy-beans.xml")   // existing XML keeps working during the move
public class LegacyShopApplication extends SpringBootServletInitializer {

    public static void main(String[] args) {
        SpringApplication.run(LegacyShopApplication.class, args);
    }
}

11. Common Misconceptions

Myth	Fact
“Spring Boot replaces the Spring Framework.”	It is built on top of Spring and cannot run without it.
“Spring Boot is a different framework to learn.”	You write the same Spring code; Boot mainly removes setup.
“Spring Boot apps are slower than plain Spring apps.”	At runtime it is the same Spring code. Unused features can be left out.
“Spring Boot only works for microservices.”	It works equally well for large single applications.
“With Spring Boot you lose control.”	Every default can be changed with a property, your own bean or an exclusion.
“Plain Spring needs XML.”	Modern Spring uses Java configuration; XML is optional.

12. Real-World Analogy

Think of building a computer:

	Spring Framework	Spring Boot
Like	Buying high-quality parts: processor, memory, motherboard	Buying a pre-built computer made from those same parts
You get	Full control over every choice	A machine that works the moment you switch it on
You must	Choose compatible parts and assemble them	Only customize what you want to change
Under the hood	The parts	The very same parts

A pre-built computer is not a different kind of computer; it is the same parts, already assembled well. You can still open it up and swap any part.

13. Interview One-Liners

The Spring Framework provides the features; Spring Boot makes them quick to use.
Spring Boot = Spring Framework + auto-configuration + starters + embedded server + production features.
Spring Boot is not a replacement for Spring; every Spring Boot application is a Spring application.
The programming model, including dependency injection, annotations, MVC and transactions, is identical in both.
Spring favours flexibility and explicit configuration; Spring Boot favours convention over configuration.

14. Summary

The Spring Framework is the foundation: dependency injection, web support, transactions and data access. Spring Boot is the layer that assembles and configures that foundation for you, with auto-configuration, starters, an embedded server and production-ready features. The side-by-side example shows the difference clearly: the business code is identical, but Spring Boot removes the dependency list, the configuration classes and the server setup. Learn Spring Boot to be productive quickly, and learn the Spring Framework concepts underneath to understand what it does for you.

15. Frequently Asked Questions (FAQ)

Q1. Is a Spring Boot application faster at runtime than a plain Spring application?

No, they perform the same. Once started, both run the same Spring Framework code: the same dependency injection, the same MVC request handling, the same transaction management. Spring Boot’s work happens mostly at startup, when it decides what to configure.

Real performance differences come from your choices, such as connection pool size, caching, queries and JVM settings, not from whether you use Spring Boot.

Q2. Does Spring Boot use more memory than plain Spring?

Sometimes a little, because starters may bring libraries and beans you do not actually use. A plain Spring application contains only what you added by hand, so it can be slightly leaner.

You can close most of the gap by removing unused starters and excluding auto-configurations you do not need. For the smallest footprint, Spring Boot also supports GraalVM native images, which use far less memory than either approach on a normal JVM.

Q3. Can a Spring Boot application still use XML configuration?

Yes. Spring Boot does not forbid XML; it simply does not need it. Load existing XML bean definitions with @ImportResource:

@SpringBootApplication
@ImportResource("classpath:integration-beans.xml")
public class ShopApplication { ... }

This is mainly useful while moving an older application to Spring Boot. For new code, Java configuration is clearer and checked by the compiler.

Q4. Does Spring Boot use different annotations from the Spring Framework?

Mostly not. The annotations you use every day, such as @Component, @Service, @Autowired, @RestController, @GetMapping and @Transactional, all come from the Spring Framework.

Spring Boot adds only a handful of its own:

Spring Boot annotation	Purpose
`@SpringBootApplication`	Marks the main class and switches on auto-configuration
`@ConfigurationProperties`	Binds groups of settings to a Java object
`@ConditionalOnClass` and similar	Conditions used by auto-configuration
`@SpringBootTest`, `@WebMvcTest`	Test support

Q5. How are Spring Boot and Spring Framework versions connected?

Each Spring Boot release is built on one specific Spring Framework generation, and manages that version for you:

Spring Boot	Spring Framework	Minimum Java
2.x	5.x	8
3.x	6.x	17
4.x	7.x	17

When you upgrade Spring Boot, you also upgrade the Spring Framework underneath. Do not override the Framework version yourself; let Spring Boot choose the matching one.

Q6. Can I use Spring Framework features that Spring Boot does not configure?

Yes, all of them. Spring Boot only configures common features automatically; it never stops you from using anything else in the Spring Framework. Declare the beans yourself, exactly as in a plain Spring application:

@Configuration
public class MessagingConfig {

    // A feature Spring Boot does not set up for you: define it as in plain Spring
    @Bean
    public ThreadPoolTaskScheduler reportScheduler() {
        ThreadPoolTaskScheduler scheduler = new ThreadPoolTaskScheduler();
        scheduler.setPoolSize(2);
        scheduler.setThreadNamePrefix("report-");
        return scheduler;
    }
}

Mixing auto-configured and hand-written beans is completely normal in Spring Boot applications.

Q7. Do companies still use plain Spring without Spring Boot?

Yes, mainly in older applications that were built before Spring Boot became popular, or that run on traditional application servers such as WebLogic or JBoss. Many of them work well and are maintained as they are.

For new projects, however, Spring Boot is the usual choice. In practice, knowing Spring Boot well, and understanding the Spring concepts underneath, prepares you for both situations.

Q8. Which should I focus on for job interviews?

Learn Spring Boot for building and the Spring Framework for understanding. Interviewers commonly ask about:

Dependency injection, bean scopes and the bean lifecycle (Spring Framework).
How auto-configuration and starters work (Spring Boot).
The difference between the two, which is exactly this page.
@Transactional behavior, proxies and AOP (Spring Framework).
Actuator, profiles and externalized configuration (Spring Boot).

Being able to explain what Spring Boot does for you shows a deeper understanding than only knowing how to use it.

Q9. Does Spring Boot change how dependency injection works?

No. Dependency injection is a Spring Framework feature, and Spring Boot uses it unchanged. Constructor injection, @Autowired, @Qualifier, @Primary and bean scopes behave exactly the same.

What Spring Boot adds is more beans to inject: because of auto-configuration, objects such as a DataSource, a JdbcTemplate or an ObjectMapper are already available, so you can inject them without defining them first.

Q10. Can a plain Spring application run with an embedded server, like Spring Boot?

Technically yes: you can start an embedded Tomcat from your own main method and register Spring’s DispatcherServlet by hand. But you then have to write and maintain that startup code, handle configuration of ports, threads and SSL yourself, and build a runnable JAR with a separate plugin.

That is essentially rebuilding part of Spring Boot. If you want an embedded server, using Spring Boot is the simpler and better-tested route.

Q11. How do Spring Data, Spring Security and other Spring projects relate to Spring Boot?

They are separate projects in the Spring ecosystem, each built on the Spring Framework:

Project	Purpose	Spring Boot starter
Spring Data	Database access with repositories	`spring-boot-starter-data-jpa`
Spring Security	Authentication and authorization	`spring-boot-starter-security`
Spring Batch	Large batch jobs	`spring-boot-starter-batch`
Spring for Apache Kafka	Kafka messaging	The `spring-kafka` dependency

You can use each of them without Spring Boot, but Spring Boot makes them much easier to set up, through starters and auto-configuration.

Q12. Is Spring Cloud part of Spring Boot?

No. Spring Cloud is a separate set of projects for distributed systems: service discovery, centralized configuration, API gateways and more. It is built on top of Spring Boot, so a Spring Cloud application is a Spring Boot application with extra libraries.

Each Spring Cloud release train supports specific Spring Boot versions, so check compatibility before upgrading either one.

Q13. Does Spring Boot lock me in?

Very little. Your business code uses Spring Framework annotations and APIs, which work with or without Spring Boot. Spring Boot’s contribution is mostly configuration that you could write yourself, as the side-by-side example on this page shows.

The parts most tied to Spring Boot are its properties file conventions, Actuator and the test annotations, and each has a plain Spring alternative if you ever need one.

Q14. Can I move a large Spring application to Spring Boot gradually?

Yes, and gradually is the safest way. Add the Spring Boot parent and a main class first, while keeping your existing configuration working through @ImportResource and your current configuration classes. Then remove pieces that auto-configuration now provides, one at a time, running your tests after each step.

If the application must keep running on an application server during the move, extend SpringBootServletInitializer and keep building a WAR until you are ready to switch to a JAR.

Q15. Does Spring Boot replace application servers like WebLogic or WildFly?

For most new applications, yes in practice. A Spring Boot application carries its own lightweight server, so there is no shared application server to install, patch and manage. Each application can be deployed, scaled and updated independently.

If an organization must keep using its application server, Spring Boot can still build a WAR for it. You keep most of Spring Boot’s benefits, such as auto-configuration and starters, while the server provides the runtime.

Q16. Why did imports change from javax to jakarta in Spring Boot 3?

Java’s enterprise specifications, such as Servlet, JPA and Bean Validation, moved from Oracle to the Eclipse Foundation and were renamed Jakarta EE. Their package names changed from javax.* to jakarta.*.

Spring Framework 6 and Spring Boot 3 adopted the new packages, so upgrading older code means changing imports:

// Spring Boot 2 / Spring Framework 5
import javax.persistence.Entity;
import javax.validation.constraints.NotBlank;

// Spring Boot 3+ / Spring Framework 6+
import jakarta.persistence.Entity;
import jakarta.validation.constraints.NotBlank;

This affects plain Spring and Spring Boot equally. IDEs and tools such as OpenRewrite can update the imports automatically.

Q17. What does “convention over configuration” mean?

It means the framework assumes sensible, common choices, and you only write configuration when you want something different. For example, Spring Boot assumes:

The web server runs on port 8080.
Settings live in application.properties or application.yml.
Static files are served from src/main/resources/static.
Your main class sits in the top-level package, so all your classes are found.

Follow these conventions and almost no setup is needed. The plain Spring Framework takes the opposite approach, configuration over convention, which gives full control but requires more decisions.

Q18. What does Spring Boot not do for me?

Spring Boot removes setup work, but it does not make design decisions for your application. You still need to:

Write the business logic and model your domain.
Design the database schema and write efficient queries.
Decide the security rules: who may access what.
Tune performance for your real load, such as pool sizes and caching.
Write tests and handle errors properly.

Its defaults are a good starting point, not a finished production setup. Review them for anything important to your application.

Q19. Is the Spring Framework still being developed, or only Spring Boot?

Both are actively developed, by the same organization. New Spring Framework generations bring core improvements, such as support for new Java versions, virtual threads, ahead-of-time compilation and observability, and Spring Boot then builds on them.

Because Spring Boot depends on the Framework, every Spring Boot release carries the latest compatible Spring Framework improvements to your application automatically.

Q20. If I know Spring Boot, can I work on a plain Spring project?

Yes, with a little extra learning. The business code will look familiar: the same annotations, services, controllers and transactions. What will be new is the setup code that Spring Boot normally hides:

Configuration classes that define the DataSource, transaction manager and other infrastructure beans.
A WebApplicationInitializer or web.xml that starts the DispatcherServlet.
Possibly XML bean definitions in older projects.
Deploying a WAR to an application server.

The side-by-side example in section 5 shows exactly these pieces, which makes it a good starting point.

Was this tutorial helpful?

Help Us Improve