Lessons- Java

Lessons learnt from all the source code reviews here in Java

Java Basics

• Java is the language that runs on the JVM (Java Virtual Machine). Your code becomes classes (bytecode) that the JVM loads and runs.

• Spring is a Java framework that helps build apps by managing object creation and wiring for you (so you don’t new everything yourself).

• The ApplicationContext is Spring’s main container: it holds all the application objects (called beans), configures them, and runs lifecycle hooks. When you call SpringApplication.run(...) in Spring Boot, you create and populate an ApplicationContext.

• JVM (Java Virtual Machine): runtime that executes Java bytecode. You run programs with java -jar app.jar.

• Class: blueprint for objects. Stored in .class files (bytecode).

• Object / instance: runtime version of a class — created with new SomeClass() in plain Java.

• main() method: every standalone Java program generally starts at public static void main(String[] args). That method runs on the JVM thread that launched the program.

• Packages & classpath: classes are grouped in packages (e.g., com.example.app). The JVM finds classes on the classpath or inside jars.

• JAR: Java ARchive — a zip containing .class files and resources; runnable jars can bundle an application.

What is Spring (conceptually)?

Spring is a large, widely used framework for building Java applications. Two core ideas to understand:

1. Inversion of Control (IoC) — you don’t new everything yourself; Spring creates objects for you and manages them.

2. Dependency Injection (DI) — when an object (A) needs another object (B), Spring injects B into A for you (via constructor, setter, or field injection).

Why this helps:

• Decouples components (A doesn’t need to know how to create B).

• Makes testing and configuration easier.

• Allows the framework to apply cross-cutting concerns (transactions, security, etc.).

Spring Boot builds on Spring and provides opinionated defaults so apps start quickly (embedded web server, auto-configuration).

The ApplicationContext — plain language

Think of the ApplicationContext as:

a registry (a “container”) that holds all the runnable parts of your app — their instances, configuration, and relationships — and manages their lifecycle.

More concretely:

• It discovers bean definitions (via annotations, configuration classes, or XML).

• It creates instances of those beans (calls constructors, wiring dependencies).

• It injects dependencies so objects get references to what they need.

• It runs lifecycle callbacks (@PostConstruct, InitializingBean, CommandLineRunner, etc.).

• It provides services to beans (message/resource lookup, events, property access).

• It keeps track of scopes (singleton, prototype, request, session).

When the ApplicationContext starts, you get the app wired up and ready. When it stops, it disposes beans and runs shutdown hooks.

How Spring Boot starts (step-by-step, typical lifecycle)

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

1. Bootstrap: SpringApplication initializes environment and configuration (profiles, properties).

2. Create ApplicationContext: usually an AnnotationConfigApplicationContext or a SpringApplication-specific context for web apps.

3. Component scanning / registration: Spring scans your packages for annotated classes like @Controller, @Service, @Component, @Configuration, @Repository, and registers bean definitions for them.

4. Instantiation & wiring: Spring constructs bean instances (calling constructors) and injects dependencies (fields/constructors/setters).

5. Post-processing: BeanPostProcessors and AOP proxies get applied (this is how things like @Transactional work).

6. Lifecycle callbacks: @PostConstruct methods run; CommandLineRunner beans are executed.

7. Start server (for web apps): Embedded servlet container (Tomcat/Jetty/Undertow) starts and registers DispatcherServlet to handle incoming HTTP requests.

8. Application is ready: controller methods are invoked only when HTTP requests arrive.

So: constructors run during step 4 (startup). Controller methods (like @GetMapping) run only when requests arrive after step 7.

Key Spring concepts with short examples

Bean

An object managed by Spring.Spring will create an instance of MyService for you.

@Component
public class MyService {
    public String hello() { return "hi"; }
}

Dependency Injection (constructor example — recommended)

@Service
public class MyAppService {
    private final MyService myService;
    public MyAppService(MyService myService) {
        this.myService = myService; // Spring injects the instance
    }
}

Controller (handles HTTP)

@Controller
public class MainController {
    @GetMapping("/")
    public String home() {
        return "index"; // returns view name or response
    }
}

Spring creates MainController at startup; home() is called later for HTTP GET /.

@PostConstruct

Method that runs after bean creation and injection:

@PostConstruct
public void init() {
    // runs once at startup (after DI)
}

Minimal Diagram

START: java -jar app.jar
  ↓
main() -> SpringApplication.run()
  ↓
Create ApplicationContext
  ↓
Scan packages -> find @Controller, @Service, @Component ...
  ↓
Instantiate beans (constructors called here)
  ↓
Inject dependencies, run @PostConstruct
  ↓
Start embedded web server (Tomcat)
  ↓
Wait for HTTP requests -> DispatcherServlet routes to controller methods
  ↓
Controller.method(...) executes on incoming request

Apache Pulsar:

When reviewing similar code, here are the red flags and fix patterns you should apply:

✅ Check how file paths are constructed.

• If you see new File(base, entryName), ask: What if entryName has ../?

• Ensure Path.resolve().normalize() and boundary checks are used.

✅ Always enforce extraction boundaries.

• Verify target.startsWith(base) after normalization.

✅ Prefer ZipFile over JarFile when unpacking archives.

• ZipFile gives better control and is the general-purpose class.

✅ Log and abort on malicious input.

• Don’t silently skip invalid entries; fail early.

✅ Security smells in the old code:

• No validation on entry names.

• Trusting archive contents blindly.