What is Spring, and why does it exist?

If you've worked with Java on the back end, or hired someone who does, you've almost certainly heard the word Spring. It powers a huge share of the business systems behind banking, retail, logistics and government services. But what actually is it?

This is part 1 of our Understanding Spring series. We'll keep it practical and free of jargon where we can.

#The short answer

Spring is a framework for building Java applications. It handles the plumbing every serious application needs, such as creating and connecting objects, talking to databases, handling web requests, security and configuration, so your developers can focus on the parts that are unique to your business.

#The problem Spring solves

Imagine you're building an online store in plain Java. You'd have classes like these:

• OrderService, which places orders
• PaymentService, which charges cards
• EmailService, which sends confirmations
• OrderRepository, which saves orders to a database

OrderService needs the other three to do its job. In plain Java, it might create them itself:

public class OrderService {

    private final PaymentService payments = new PaymentService();
    private final EmailService email = new EmailService();
    private final OrderRepository orders = new OrderRepository();

    public void placeOrder(Order order) {
        payments.charge(order);
        orders.save(order);
        email.sendConfirmation(order);
    }
}

This works for a demo, but it causes real problems as the system grows:

1. Everything is tightly coupled. OrderService is welded to one specific PaymentService. Switching payment providers means editing and retesting this class.
2. Testing is painful. You can't test placeOrder without charging a real card or sending a real email, because the class builds its own real dependencies.
3. Setup is scattered. Database connections, API keys and settings end up hard-coded or repeated across dozens of classes.

Multiply this by hundreds of classes and you get software that's slow and risky to change.

#How Spring fixes it

Spring flips the responsibility around. Instead of each class building what it needs, Spring builds the objects and hands each one what it needs:

@Service
public class OrderService {

    private final PaymentService payments;
    private final EmailService email;
    private final OrderRepository orders;

    // Spring calls this constructor and passes in the right objects
    public OrderService(PaymentService payments,
                        EmailService email,
                        OrderRepository orders) {
        this.payments = payments;
        this.email = email;
        this.orders = orders;
    }

    public void placeOrder(Order order) {
        payments.charge(order);
        orders.save(order);
        email.sendConfirmation(order);
    }
}

OrderService no longer cares which payment service it gets, only that it gets one. In production Spring provides the real one. In a test you pass in a fake. Swapping providers becomes a configuration change rather than a rewrite.

This idea is called Inversion of Control (IoC), and the technique is called Dependency Injection (DI). The part of Spring that does the building and wiring is the IoC container. We'll unpack all three in part 2.

#Spring Framework vs Spring Boot

These two names get mixed up a lot.

A good way to think about it: Spring Framework is the engine, and Spring Boot is the car built around it. You can still open the bonnet, but you don't have to assemble the car before you drive.

A complete Spring Boot web app can start this small:

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

Running that starts a web server, scans your code for classes like OrderService, builds them and wires them together.

#The wider Spring ecosystem

Beyond the core, Spring has projects for most back-end needs, all designed to work together:

• Spring Web / Spring MVC for building websites and REST APIs
• Spring Data for talking to databases with far less boilerplate
• Spring Security for login, permissions and protecting APIs
• Spring Cloud for building and running distributed systems and microservices

#Where Spring fits next to plain Java

Spring doesn't replace Java. You still write normal Java classes. Spring adds structure around them. Plain Java is perfectly fine for small tools and scripts. Once an application has many moving parts, a database, users and a team working on it, Spring's structure tends to pay for itself quickly.

#What a business owner should take away

• Faster delivery. Developers spend their time on your features, not on reinventing plumbing.
• Cheaper change. Loosely connected parts mean swapping a payment provider or adding a feature is lower risk.
• Easier hiring and handover. Spring is one of the most widely used Java frameworks, so experienced developers are relatively easy to find and a new team can pick up the code.
• Proven at scale. It's been in heavy production use for many years across demanding industries.

#Coming up next

In part 2 we'll open up the IoC container: what "inversion of control" really means, how dependency injection works under the hood, and what Spring's ApplicationContext does when your app starts.

Building a Java or Spring system and want a second pair of eyes? Talk to Sense-Tech-Services.