Core Java & Backend Prerequisites

This is a quick revision, not a complete Java course. You should recognize the basic shapes that appear in backend code: primitive values such as int, long, double, boolean, and char; reference values such as String and List; variables, conditions, loops, and methods. If any of these feels unfamiliar, pause here and practice the small example before continuing.

1
2
3
4
5
6
7
8
9
10
11

final class JavaSyntaxRefresh {
    static int countOpen(String[] statuses) {
        int openCount = 0;
        for (String status : statuses) {
            if ("OPEN".equals(status)) {
                openCount++;
            }
        }
        return openCount;
    }
}

This example deliberately stays small: it uses an array, a String, an int variable, a condition, an enhanced for loop, and a method. The goal is to recognize Java syntax, not to teach collections, streams, money, or exception design yet.

Spring Boot does not change Java semantics. A service is still an object, a dependency is still another object it collaborates with, and a request eventually becomes an ordinary method call. Before learning annotations, you should be able to read a small object graph and identify which object owns each rule. The Task example starts with a normal class so you can see fields, constructors, methods, and encapsulation before records are introduced.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

enum TaskStatus { OPEN, COMPLETED }

final class Task {
    private final long id;
    private final String title;
    private final TaskStatus status;

    Task(long id, String title, TaskStatus status) {
        if (id <= 0) throw new IllegalArgumentException("id must be positive");
        if (title == null || title.isBlank()) {
            throw new IllegalArgumentException("title is required");
        }
        this.id = id;
        this.title = title;
        this.status = status;
    }

    long id() { return id; }
    String title() { return title; }
    TaskStatus status() { return status; }

    Task complete() {
        if (status == TaskStatus.COMPLETED) return this;
        return new Task(id, title, TaskStatus.COMPLETED);
    }
}

The constructor protects the object at creation time, so downstream code can trust that every Task has a positive id and nonblank title. The fields are private and final, but this class is only shallowly immutable if it later contains mutable components. The complete method returns a new value instead of exposing a public setter. That is encapsulation: the type owns the transition and callers ask for an operation rather than manipulating its fields.

A useful class should receive the collaborators it needs instead of constructing concrete infrastructure internally. This keeps the business operation independent of storage and makes the object graph visible at the program boundary. Spring calls this dependency injection, but the underlying Java is simply one constructor receiving another object.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

import java.util.Optional;

interface TaskRepository {
    Optional<Task> findById(long id);
    Task save(Task task);
}

final class TaskNotFoundException extends RuntimeException {
    TaskNotFoundException(long id) {
        super("task " + id + " was not found");
    }
}

final class TaskService {
    private final TaskRepository tasks;

    TaskService(TaskRepository tasks) {
        this.tasks = tasks;
    }

    Task complete(long id) {
        Task task = tasks.findById(id)
                .orElseThrow(() -> new TaskNotFoundException(id));
        return tasks.save(task.complete());
    }
}

The interface describes what the use case needs: lookup and save. It does not promise SQL, JPA, or an in-memory map. Optional<Task> makes the missing case part of the method signature, and orElseThrow converts that absence into a domain-level failure. Later, Spring can supply a repository implementation to the same constructor without changing TaskService.

Backend signatures often carry more meaning in their types than in their method names. Read List<Task> as an ordered collection containing only Task values, Map<Long, Task> as a lookup from ids to tasks, and Optional<Task> as zero or one Task. Generics allow those guarantees to be checked by the compiler instead of rediscovered through casts at runtime.

1
2
3
4
5
6
7
8
9

import java.util.List;

List<String> openTitles(List<Task> tasks) {
    return tasks.stream()
            .filter(task -> task.status() == TaskStatus.OPEN)
            .map(Task::title)
            .toList();
}
}

A stream is a pipeline over values: select open tasks, project each one to its title, and collect the results. It does not automatically make work parallel, faster, or database-backed. When a Spring Data method returns a collection or Optional, first understand the Java type; only then ask how the repository obtained it.

Exceptions carry failed control flow. Catch an exception only where you can add context, recover, translate it into another contract, or release a resource. Logging and rethrowing at every layer creates duplicates; swallowing a failure destroys the evidence needed to diagnose it. Later, an HTTP exception handler will translate TaskNotFoundException into a 404 response.

A framework-free unit test should construct the object graph directly and observe a meaningful outcome. The fake repository below is intentionally small: it gives the service controllable state without pretending to be PostgreSQL. This test proves the use-case rule; later integration tests will separately prove database mapping and transaction behavior.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

import static org.junit.jupiter.api.Assertions.assertEquals;
import java.util.HashMap;
import java.util.Map;
import java.util.Optional;
import org.junit.jupiter.api.Test;

class TaskServiceTest {
    @Test
    void completes_an_open_task() {
        var repository = new InMemoryTasks(
                new Task(42, "Read Module 0", TaskStatus.OPEN));
        var service = new TaskService(repository);

        Task completed = service.complete(42);

        assertEquals(TaskStatus.COMPLETED, completed.status());
        assertEquals(TaskStatus.COMPLETED, repository.findById(42).orElseThrow().status());
    }

    static final class InMemoryTasks implements TaskRepository {
        private final Map<Long, Task> data = new HashMap<>();
        InMemoryTasks(Task task) { data.put(task.id(), task); }
        public Optional<Task> findById(long id) {
            return Optional.ofNullable(data.get(id));
        }
        public Task save(Task task) {
            data.put(task.id(), task);
            return task;
        }
    }
}

The test contains arrange, act, and assert without requiring those labels. It controls the initial task, calls one public behavior, and checks both the returned value and saved state. If this shape feels unfamiliar, pause for the Core Java classes, interfaces, collections, generics, exception-handling, and modern-Java lessons linked from the course.

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

You are ready for Module 1 when you can explain the preceding program without framework vocabulary and change it safely. You do not need reflection internals, advanced concurrency, JVM tuning, or annotation processing yet. Those topics matter later, when a production symptom creates a reason to learn them.

1. 01Trace JavaSyntaxRefresh: name the types, follow each conditional, and explain how the loop builds the returned value.
2. 02Explain why TaskService depends on an interface and where the concrete repository is chosen.
3. 03Read Optional<Task> and List<String> aloud and describe the empty cases.
4. 04Add a failing test for an unknown task and predict the exception before running it.
5. 05Explain which responsibility belongs to Java, which will belong to HTTP, and which will belong to SQL.