I've seen this exact snippet in countless code reviews from developers moving from standard Java SE to their first enterprise project. They understand the logic, but they haven't yet grasped the "magic" of the container. Take a look at this:

@Service
public class UserPaymentService {
    @Autowired
    private PaymentGateway gateway;

    public void processPayment(double amount) {
        gateway.charge(amount);
    }
}

// In the Main class or another service
public class OrderController {
    public void checkout() {
        UserPaymentService paymentService = new UserPaymentService(); 
        paymentService.processPayment(100.00);
    }
}

The NullPointerException of Managed Beans

If you run this, it'll crash instantly with a NullPointerException the moment gateway.charge(amount) is called. Why? Because the gateway field is null. The learner usually says, "But I put @Autowired right there!"

Here is the disconnect: @Autowired (or @Inject in Jakarta EE) is not a magic spell that works on every object in your JVM. It is a directive for the Container. When you use the new keyword, you are bypassing the Spring or Jakarta container entirely. You've created a plain old Java object (POJO), and the framework has no idea that object even exists, so it never performs the dependency injection.

Letting the Container Take the Wheel

To fix this, we have to stop acting like the boss of object creation. We need to let the framework manage the lifecycle. Instead of new UserPaymentService(), we ask the container to give us the instance it already knows about.

@RestController
public class OrderController {
    @Autowired
    private UserPaymentService paymentService; // Let the container inject this

    public void checkout() {
        paymentService.processPayment(100.00); // Now this works!
    }
}

By marking OrderController as a managed component (like a @RestController), the container sees that it needs a UserPaymentService, finds the one it managed, injects the PaymentGateway into that service, and then injects the whole thing into your controller. This is Inversion of Control (IoC), and it's the bedrock of the entire Java Enterprise ecosystem.

Jakarta EE: The Official Blueprint

When we talk about the "Enterprise Ecosystem," we're usually talking about a few different players. First is Jakarta EE (formerly Java EE). Think of this as the industry standard. It's a set of specifications—basically a big book of rules—that says "A Java enterprise server must provide a way to do Web Services, Persistence (JPA), and Dependency Injection (CDI)."

Because Jakarta EE is a specification, different vendors build "Application Servers" that implement those rules. You've probably heard names like GlassFish, WildFly, or Payara. If you write code strictly to the Jakarta EE spec, you can (theoretically) move your app from one server to another without changing your code. It's designed for stability and long-term corporate lifecycles.

Spring: The Ecosystem Giant

Then there's Spring. If Jakarta EE is the official blueprint, Spring is the powerhouse that decided to build the house its own way. For a long time, Spring was a wrapper around Java EE, but it evolved into its own massive ecosystem. Today, Spring Boot is the dominant force in the industry.

The big difference you'll notice is that Spring is opinionated. It doesn't just give you a specification; it gives you "Starters" that pre-configure your app. While Jakarta EE is often associated with heavy application servers, Spring Boot promotes the "fat JAR" approach—embedding the server (like Tomcat) directly into your application. It's faster to develop with, but it ties you more closely to the Spring ecosystem.

The Rise of the Cloud-Native Frameworks

Lately, you'll hear about Quarkus, Micronaut, or Helidon. These are the "new school." Traditional enterprise Java has a reputation for being "heavy"—slow to start and consuming a lot of RAM. That's fine for a server that runs for three years without restarting, but it's terrible for a Kubernetes pod that needs to scale up in milliseconds.

These modern frameworks use a technique called "Ahead-of-Time" (AOT) compilation. Instead of doing all that @Autowired scanning and proxying while the app is starting up (which is what Spring and Jakarta traditionally do), they do it during the build phase. This allows them to compile to native binaries via GraalVM, resulting in boot times of milliseconds and a fraction of the memory usage. If you're heading into serverless or microservices, this is where you'll likely spend your time.

📋 Practical Task

Exercise: Migrating Manual Dependencies to Spring Injection

You have been handed a legacy InventoryManager class that is causing NullPointerExceptions because the developer was manually instantiating services instead of using the Spring container.

Your Task: Modify the provided code to remove the new keywords and implement proper Dependency Injection using @Autowired. Ensure that both the InventoryService and the DatabaseConnector are managed by the Spring container.

// --- FILE: DatabaseConnector.java ---
@Component
public class DatabaseConnector {
    public void connect() { 
        System.out.println("Connected to DB"); 
    }
}

// --- FILE: InventoryService.java ---
@Service
public class InventoryService {
    @Autowired
    private DatabaseConnector db;

    public void updateStock() {
        db.connect();
        System.out.println("Stock updated");
    }
}

// --- FILE: InventoryManager.java ---
@Component
public class InventoryManager {
    // BUG: This is manually instantiated and will cause 
    // the internal DatabaseConnector in InventoryService to be null.
    private InventoryService service = new InventoryService();

    public void runMaintenance() {
        service.updateStock();
    }
}

Requirements:

• Remove the new InventoryService() instantiation from InventoryManager.
• Apply the correct annotation to InventoryManager to allow Spring to inject the InventoryService.
• Verify that the InventoryService is also properly marked as a managed component.