Forem: William

When to Use LinkedList vs. ArrayList in Java: A Practical Guide with a Spring Boot Example

William — Tue, 19 Aug 2025 19:01:56 +0000

Introduction

In the Java ecosystem, collections are fundamental for managing data efficiently. Two of the most common implementations of the List interface are ArrayList and LinkedList. Both allow storing ordered elements with support for duplicates and index-based access, but they differ significantly in their internal structure and performance. Choosing the right implementation can drastically impact an application’s performance, especially in scenarios involving high data volumes or frequent operations.

Key Differences

ArrayList: Based on a dynamic array. Elements are stored in contiguous memory locations. When the array reaches its capacity, a new, larger array is created, and elements are copied (resize).
LinkedList: Based on a doubly linked list. Each element is a node containing the value and references to the previous and next nodes. No contiguous allocation, allowing flexible expansion without massive copying.

Advantages and Disadvantages

ArrayList

Advantages: Excellent for sequential iteration (via enhanced for-loop or iterator) and random access. More CPU cache-friendly due to memory locality.
Disadvantages: Insertions and removals at the start or middle require shifting elements, which can be costly for large lists.

LinkedList

Advantages: Constant-time operations at the start or end. Implements Queue and Deque, making it versatile for queues or stacks.
Disadvantages: Slow random access due to list traversal. Higher memory usage.

When to Use ArrayList

Frequent random access: If you need to access elements by index often (e.g., paginating results in an API).
Read-heavy lists: Applications where the list is populated once and read/iterated multiple times, like configuration lists or query results.
Fixed or predictable size: When the number of elements is stable, avoiding frequent resizes.
Real-world examples: Product lists in an e-commerce system (access by ID), search query results, or static data caches. Avoid ArrayList if there are many insertions/removals in the middle, as the O(n) cost can degrade performance.

When to Use LinkedList

Frequent insertions/removals at ends: Ideal for FIFO (Queue) or LIFO (Stack) scenarios, like task queues.
Dynamic lists with constant changes: When order matters, but access is sequential or at the ends.
Versatility as Queue/Deque: Useful for message queues, navigation histories, or asynchronous task processing.
Real-world examples: Job queues in scheduling systems, media playlists (add/remove songs at ends), or stream processing buffers. Avoid LinkedList for large lists with random access, as the O(n) traversal can be inefficient.

Real-World Example

Let’s apply these concepts in a practical example: a simple REST API in Spring Boot for an e-commerce system. We’ll use:

ArrayList for storing available products (frequent random access, e.g., lookup by ID).
LinkedList for a queue of pending orders (FIFO: process in order of arrival, with insertions at the end and removals at the start).

Model Classes

public class Order {
    private Long id;
    private String description;

    public Order(Long id, String description) {
        this.id = id;
        this.description = description;
    }

    // Getters and Setters
}

public class Product {
    private Long id;
    private String name;

    public Product(Long id, String name) {
        this.id = id;
        this.name = name;
    }

    // Getters and Setters
}

Service Class

import java.util.ArrayList;
import java.util.LinkedList;
import java.util.List;
import org.springframework.stereotype.Service;

@Service
public class EcommerceService {

    private final List<Product> products = new ArrayList<>();
    private final List<Order> orderQueue = new LinkedList<>();

    public EcommerceService() {
        products.add(new Product(1L, "Product A"));
        products.add(new Product(2L, "Product B"));
        products.add(new Product(3L, "Product C"));
    }

    public Product getProductById(Long id) {
        int index = id.intValue() - 1; // Simulating mapping
        if (index >= 0 && index < products.size()) {
            return products.get(index); // Fast access O(1)
        }
        return null;
    }

    public void addOrder(Order order) {
        orderQueue.addLast(order);
    }

    public Order processNextOrder() {
        if (!orderQueue.isEmpty()) {
            return orderQueue.removeFirst();
        }
        return null;
    }

    public List<Order> getOrderQueue() {
        return new LinkedList<>(orderQueue);
    }
}

Controller Class

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/ecommerce")
public class EcommerceController {

    @Autowired
    private EcommerceService service;

    @GetMapping("/product/{id}")
    public Product getProduct(@PathVariable Long id) {
        return service.getProductById(id);
    }

    @PostMapping("/order")
    public String addOrder(@RequestBody Order order) {
        service.addOrder(order);
        return "Order added to queue!";
    }

    @GetMapping("/process")
    public Order processOrder() {
        return service.processNextOrder();
    }

    @GetMapping("/queue")
    public List<Order> viewQueue() {
        return service.getOrderQueue();
    }
}

ArrayList for Products: Used for static or semi-static items. The /product/{id} endpoint accesses directly by index (simulated), leveraging O(1) for fast lookups. In a real e-commerce system, this is efficient for large catalogs where users search products by ID or paginate results.
LinkedList for Orders: Acts as a FIFO Queue. Orders are added at the end (addLast) via POST /order and processed from the start (removeFirst) via GET /process. This ensures order-of-arrival processing, ideal to prevent new orders from jumping ahead. In real systems, this could integrate with a message broker like Kafka, but here it’s a simple in-memory queue.

Run the application
Add orders via POST: Use Postman to send JSON { "id": 1, "description": "Urgent Order" } to http://localhost:8080/ecommerce/order.
Process: GET http://localhost:8080/ecommerce/process.
View queue: GET http://localhost:8080/ecommerce/queue.
Fetch product: GET http://localhost:8080/ecommerce/product/1.

Three Ways to Perform Queries in Spring Boot

William — Tue, 19 Aug 2025 17:11:28 +0000

Spring Data JPA provides three powerful methods to perform SELECT queries: standard repository methods, @Query annotations, and custom queries with EntityManager. Each approach offers unique advantages and built-in protections against SQL Injection. Below, I’ll demonstrate these using a Product entity, ensuring secure and efficient queries.

Standard Repository Methods

Spring Data JPA repositories provide built-in methods and allow custom queries through method naming conventions, with automatic query generation.

Example: Fetch products by category or name.

import org.springframework.data.jpa.repository.JpaRepository;
import java.util.List;

public interface ProductRepository extends JpaRepository<Product, Long> {
    List<Product> findByCategory(String category);
    List<Product> findByNameContainingIgnoreCase(String name);
}

Usage in Service

@Service
public class ProductService {
    @Autowired
    private ProductRepository productRepository;

    public List<Product> getProductsByCategory(String category) {
        return productRepository.findByCategory(category);
    }
}

Spring Data JPA uses prepared statements, binding inputs like category as parameters. This ensures malicious inputs (e.g., "; DROP TABLE products; --") are treated as data, not executable SQL, preventing injection attacks.

Using @Query Annotation

The @Query annotation enables custom JPQL or native SQL queries with explicit control over the query structure.

import com.example.demo.model.Product;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.data.jpa.repository.Query;
import org.springframework.data.repository.query.Param;

import java.util.List;

public interface ProductRepository extends JpaRepository<Product, Long> {

    @Query(value = "SELECT * FROM Product WHERE stock < :stock", nativeQuery = true)
    List<Product> findLowStockProducts(@Param(value = "stock") Integer stock);
}

Usage in Service

public List<Product> getExpensiveProducts(Double price) {
    return productRepository.findProductsAbovePrice(price);
}

Custom Queries with EntityManager

EntityManager is ideal for dynamic queries where conditions vary based on runtime inputs.

Example: Dynamically filter products by category and price.

import com.example.demo.model.Product;
import jakarta.persistence.EntityManager;
import jakarta.persistence.PersistenceContext;
import jakarta.persistence.TypedQuery;
import org.springframework.stereotype.Repository;

import java.util.ArrayList;
import java.util.List;

@Repository
public class CustomQuery {

    @PersistenceContext
    private EntityManager entityManager;

    public List<Product> findProductsByCriteria(String category, Double minPrice) {
        StringBuilder jpql = new StringBuilder("SELECT p FROM Product p WHERE 1=1");
        List<Object> params = new ArrayList<>();

        if (category != null) {
            jpql.append(" AND p.category = ?1");
            params.add(category);
        }
        if (minPrice != null) {
            jpql.append(" AND p.price >= ?").append(params.size() + 1);
            params.add(minPrice);
        }

        TypedQuery<Product> query = entityManager.createQuery(jpql.toString(), Product.class);
        for (int i = 0; i < params.size(); i++) {
            query.setParameter(i + 1, params.get(i));
        }

        return query.getResultList();
    }
}

Key Practices to Avoid SQL Injection

Use parameter binding: Always use prepared statements via Spring’s mechanisms or setParameter.
Avoid string concatenation: Never embed user input directly into queries.
Validate inputs: Check inputs (e.g., ensure minPrice is a number) for added safety.
Limit database permissions: Restrict database roles to minimize damage from potential vulnerabilities.

Proxy Design Pattern with Caching Example in Java

William — Sat, 02 Aug 2025 17:42:11 +0000

Imagine an application that repeatedly queries a database for user data, causing performance bottlenecks due to slow database operations. How can we optimize this without modifying the core logic? The Proxy Design Pattern offers a solution by introducing an intermediary that controls access to the real object, enabling optimizations like caching.

Solution: Proxy Pattern with Caching

The Proxy Pattern introduces a Proxy class that sits between the client and the real service, adding caching to reduce database calls. We'll implement this in pure Java for simplicity, demonstrating a caching proxy for user data.

Interface: UserService
public interface UserService {
    String getUserData(String userId);
}

Real Service: RealUserService
public class RealUserService implements UserService {
    @Override
    public String getUserData(String userId) {
        // Simulate a slow database query
        try {
            Thread.sleep(2000); // 2-second delay
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return "Data for user: " + userId;
    }
}

//Proxy Service: UserServiceProxy
import java.util.HashMap;
import java.util.Map;

public class UserServiceProxy implements UserService {
    private final UserService realUserService;
    private final Map<String, String> cache = new HashMap<>();

    public UserServiceProxy(UserService realUserService) {
        this.realUserService = realUserService;
    }

    @Override
    public String getUserData(String userId) {
        // Check cache first
        if (cache.containsKey(userId)) {
            System.out.println("Retrieved from cache: " + userId);
            return cache.get(userId);
        }
        // Fetch from real service and cache the result
        String data = realUserService.getUserData(userId);
        cache.put(userId, data);
        System.out.println("Fetched from database and cached: " + userId);
        return data;
    }
}

//Main Application
public class ProxyPatternDemo {
    public static void main(String[] args) {
        UserService realUserService = new RealUserService();
        UserService proxy = new UserServiceProxy(realUserService);

        // Test the proxy
        System.out.println(proxy.getUserData("user1")); // Hits database
        System.out.println(proxy.getUserData("user1")); // Hits cache
        System.out.println(proxy.getUserData("user2")); // Hits database
        System.out.println(proxy.getUserData("user2")); // Hits cache
    }
}

How It Works

Interface: UserService defines the contract for both the real service and the proxy.
Real Service: RealUserService simulates a slow database query with a 2-second delay.
Proxy: UserServiceProxy intercepts calls, checks a HashMap cache, and only calls RealUserService if the data isn't cached.
Main Class: Demonstrates the proxy in action, showing how repeated requests leverage the cache.

When you run, the first call to getUserData("user1") hits the database (slow), but subsequent calls for the same userId retrieve data from the cache (fast).

Benefits

Performance: Caching reduces database calls, improving response times.
Transparency: The client uses the same interface, unaware of the proxy.
Extensibility: The proxy can be extended for additional features like logging or access control.

Conclusion

The Proxy Pattern elegantly solves the problem of inefficient database access by introducing a caching layer without altering the core service. In this Java example, we used a simple HashMap for caching, significantly improving performance for repeated requests.
In a real-world project, caching approaches would be more robust like Redis.

Additionally, the Proxy Pattern is versatile beyond caching. It can be used for logging, capturing method calls, parameters, and execution times for debugging or auditing. For example, you could extend UserServiceProxy to log each request to a file or monitoring system, enhancing observability without changing the core service logic. This makes the Proxy Pattern a powerful tool for optimizing and extending system behavior transparently.

The Decorator Pattern in Java

William — Sat, 02 Aug 2025 17:04:51 +0000

Imagine you need to display text with various formatting options, like bold or italic, but you want to keep the core text-display logic unchanged. Modifying the base class for each new style can quickly become messy and violate the Open-Closed Principle. How do we add functionality dynamically without altering existing code? The Decorator Pattern is the answer!

Solution: The Decorator Pattern

The Decorator Pattern allows us to wrap a core component with additional responsibilities dynamically. In Java, this is achieved using an interface, a base component, and decorator classes that implement the same interface while holding a reference to the component they enhance. This enables stacking behaviors without modifying the original object.
Below is a practical example in Java demonstrating the Decorator Pattern to add text formatting.

// Component Interface
interface Text {
    String display();
}

// Concrete Component
class SimpleText implements Text {
    private String content;

    public SimpleText(String content) {
        this.content = content;
    }

    @Override
    public String display() {
        return content;
    }
}

// Abstract Decorator Class
abstract class TextDecorator implements Text {
    protected Text decoratedText;

    public TextDecorator(Text decoratedText) {
        this.decoratedText = decoratedText;
    }

    @Override
    public String display() {
        return decoratedText.display();
    }
}

// Concrete Decorator: Bold
class BoldTextDecorator extends TextDecorator {
    public BoldTextDecorator(Text decoratedText) {
        super(decoratedText);
    }

    @Override
    public String display() {
        return "<b>" + super.display() + "</b>";
    }
}

// Concrete Decorator: Italic
class ItalicTextDecorator extends TextDecorator {
    public ItalicTextDecorator(Text decoratedText) {
        super(decoratedText);
    }

    @Override
    public String display() {
        return "<i>" + super.display() + "</i>";
    }
}

// Demo Class
public class DecoratorPatternDemo {
    public static void main(String[] args) {
        Text simpleText = new SimpleText("Hello, World!");
        Text boldText = new BoldTextDecorator(simpleText);
        Text italicText = new ItalicTextDecorator(simpleText);
        Text boldItalicText = new BoldTextDecorator(new ItalicTextDecorator(simpleText));

        System.out.println("Plain Text: " + simpleText.display());
        System.out.println("Bold Text: " + boldText.display());
        System.out.println("Italic Text: " + italicText.display());
        System.out.println("Bold and Italic Text: " + boldItalicText.display());
    }
}

The Text interface defines the core operation (display()).
SimpleText is the concrete component that holds the base text.
TextDecorator is an abstract class that implements Text and holds a reference to a Text object via its constructor.
Concrete decorators (BoldTextDecorator, ItalicTextDecorator) extend TextDecorator to add specific formatting.
The main method shows how decorators can be stacked to combine behaviors (e.g., bold + italic).

Output:
Plain Text: Hello, World!
Bold Text: <b>Hello, World!</b>
Italic Text: <i>Hello, World!</i>
Bold and Italic Text: <b><i>Hello, World!</i></b>

Conclusion

The Decorator Pattern solves the problem of adding responsibilities to objects flexibly and reusably. By using an interface and passing the component through the decorator’s constructor, we can stack behaviors dynamically without modifying the core class. This approach adheres to the Open-Closed Principle and makes the system extensible for future enhancements, like adding new decorators for underlining or colors. Try it out in your Java projects to keep your code clean and modular!

Strategy Design Pattern

William — Mon, 21 Jul 2025 02:07:31 +0000

Imagine you are building an e-commerce platform, and you need to handle multiple payment methods like credit cards, PayPal, and bank transfers. Each method has its own processing logic, but you want to keep your code flexible and maintainable.
How do you manage these different payment methods without cluttering your code with conditionals? The Strategy Design Pattern is the solution, allowing you to define a family of algorithms, encapsulate each one, and make them interchangeable.

What is the Strategy Pattern?

The Strategy Pattern is a behavioral design pattern that enables you to define a set of algorithms, encapsulate them in separate classes, and switch between them dynamically. This makes your code more modular, easier to extend, and avoids hard-coded logic.

Code Example

// Strategy Interface
interface PaymentStrategy {
    boolean processPayment(double amount);
}

// Concrete Strategy: Credit Card
class CreditCardPayment implements PaymentStrategy {
    private String cardNumber;

    public CreditCardPayment(String cardNumber) {
        this.cardNumber = cardNumber;
    }

    @Override
    public boolean processPayment(double amount) {
        System.out.println("Processing credit card payment of $" + amount);
        // Simulate card validation and API call
        return true;
    }
}

// Concrete Strategy: PayPal
class PayPalPayment implements PaymentStrategy {
    private String email;

    public PayPalPayment(String email) {
        this.email = email;
    }

    @Override
    public boolean processPayment(double amount) {
        System.out.println("Processing PayPal payment of $" + amount);
        // Simulate PayPal API call
        return true;
    }
}

// Context Class
class PaymentProcessor {
    private PaymentStrategy paymentStrategy;

    public void setPaymentStrategy(PaymentStrategy paymentStrategy) {
        this.paymentStrategy = paymentStrategy;
    }

    public boolean process(double amount) {
        if (paymentStrategy == null) {
            throw new IllegalStateException("Payment strategy not set");
        }
        return paymentStrategy.processPayment(amount);
    }
}

// Usage Example
public class Main {
    public static void main(String[] args) {
        PaymentProcessor processor = new PaymentProcessor();

        // Paying with Credit Card
        processor.setPaymentStrategy(new CreditCardPayment("1234-5678-9012-3456"));
        processor.process(100.0);

        // Switching to PayPal
        processor.setPaymentStrategy(new PayPalPayment("user@example.com"));
        processor.process(50.0);
    }
}

The PaymentStrategy interface defines the contract for all payment methods.
Each concrete strategy (CreditCardPayment, PayPalPayment) encapsulates its own logic.
The PaymentProcessor context class delegates the payment processing to the current strategy.
At runtime, you can swap strategies (e.g., switch from Credit Card to PayPal) without modifying the PaymentProcessor.

Benefits

Flexibility: Add new payment methods by creating new strategy classes without changing existing code.
Maintainability: Each payment method is encapsulated, reducing code complexity.
Reusability: Strategies can be reused across different contexts.

The Strategy Pattern solves the problem of handling multiple payment methods by making them interchangeable and encapsulated. By using this pattern, your e-commerce platform can easily support new payment methods, keeping your codebase clean and scalable.

Spring Cloud Function

William — Tue, 15 Jul 2025 01:02:07 +0000

Imagine you're building a microservices architecture, and you need a lightweight, flexible way to handle business logic without being tied to specific server frameworks or deployment models. The problem? Traditional approaches often involve heavy boilerplate code and rigid configurations, making development and deployment complex. Spring Cloud Function solves this by providing a functional programming model for building cloud-native applications. Let’s explore what it is, what problems it solves, where it’s used, and a simple example.

What is Spring Cloud Function?

Spring Cloud Function is a framework within the Spring ecosystem that enables developers to write business logic as functions—simple, reusable, and stateless units of code. It abstracts away the underlying infrastructure, allowing you to deploy functions to various platforms, such as serverless environments (e.g., AWS Lambda, Azure Functions) or traditional servers, with minimal configuration.

What Problems Does It Solve?

Simplifies Development: It reduces boilerplate code by letting you focus on writing pure functions (e.g., Function), decoupled from web frameworks or server concerns.
Platform Flexibility: Functions can be deployed to serverless platforms, Kubernetes, or traditional servers without code changes.
Event-Driven Architecture: It seamlessly integrates with event streams (e.g., Kafka, RabbitMQ), making it ideal for reactive, event-driven systems.
Scalability: Functions are stateless, enabling easy scaling in cloud environments.

Spring Cloud Function is used in:

Serverless Applications: Deploying lightweight functions to AWS Lambda, Azure Functions, or Google Cloud Functions.
Microservices: Handling specific tasks in distributed systems.
Event-Driven Systems: Processing messages from Kafka, RabbitMQ, or other message brokers.
Enterprise Applications: Simplifying business logic in Spring-based projects, especially in cloud-native environments.

Dependencies

<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-function-web</artifactId>
        <version>4.1.3</version>
    </dependency>
</dependencies>

Basic Example

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import java.util.function.Function;

@SpringBootApplication
public class SquareFunctionApplication {

    @Bean
    public Function<Integer, Integer> square() {
        return number -> number * number;
    }

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

The square function takes an Integer input and returns its square using a lambda expression (number -> number * number).
The Bean annotation registers the function with Spring’s context.
The spring-cloud-starter-function-web dependency enables HTTP support for local testing or serverless deployment.
To test locally, run the application and send a POST request to http://localhost:8080/square with a JSON payload like 5. The response will be 25.

For serverless deployment, configure the function for platforms like AWS Lambda using Spring Cloud Function’s adapters.

Conclusion

Spring Cloud Function tackles the challenge of building scalable, lightweight applications by letting developers write business logic as functions. It simplifies development, supports flexible deployments, and integrates with event-driven systems. The square calculation example demonstrates how to process numerical data in a reusable, deployable function. By using Spring Cloud Function, you can streamline microservices or serverless projects, solving complexity and boosting productivity.
See more in the official documentation

Advanced Use of Predicate, Function, Consumer, and Comparator in Java

William — Tue, 15 Jul 2025 00:28:49 +0000

Suppose you are building a Java application to manage a product inventory. You need to filter products by category, transform them into a formatted report, perform actions like logging, and sort them by price. Traditionally, this requires verbose loops and anonymous classes, leading to code that's hard to read and maintain. How can we handle this elegantly? Java’s functional interfaces: Predicate, Function, Consumer, and Comparator, combined with lambda expressions and the Stream API, provide a concise, functional solution.

Example Scenario

Imagine a Product class with name, category, and price.

class Product {
    private String name;
    private String category;
    private double price;

    public Product(String name, String category, double price) {
        this.name = name;
        this.category = category;
        this.price = price;
    }

    public String getName() { return name; }
    public String getCategory() { return category; }
    public double getPrice() { return price; }

    @Override
    public String toString() {
        return name + " (" + category + ", $" + price + ")";
    }
}

We want to:

Filter products in the "Electronics" category with a price above $100.
Transform each product into a formatted report string.
Log each processed product to a list.
Sort the results by price in descending order.

Solution

public class ProductDemo {
    public static void main(String[] args) {

        List<Product> products = Arrays.asList(
                new Product("Phone", "Electronics", 499.99),
                new Product("Laptop", "Electronics", 999.99),
                new Product("Desk", "Furniture", 150.00),
                new Product("Headphones", "Electronics", 89.99),
                new Product("Tablet", "Electronics", 299.99)
        );


        Predicate<Product> isExpensiveElectronics = p ->
                p.getCategory().equals("Electronics") && p.getPrice() > 100;

        Function<Product, String> formatReport = p ->
                String.format("Product: %s, Price: $%.2f", p.getName(), p.getPrice());

        List<String> log = new ArrayList<>();
        Consumer<Product> logProduct = p -> log.add("Processed: " + p);

        Comparator<Product> byPriceDesc = (p1, p2) ->
                Double.compare(p2.getPrice(), p1.getPrice());


        List<String> report = products.stream()
                .filter(isExpensiveElectronics)
                .peek(logProduct)
                .sorted(byPriceDesc)
                .map(formatReport)
                .toList();

        System.out.println("Formatted Report:");
        report.forEach(System.out::println);

        System.out.println("\nAudit Log:");
        log.forEach(System.out::println);
    }
}

Explanation of the Code

Predicate: isExpensiveElectronicscombines two conditions (category and price) to filter electronics over $100.
Function: formatReport transforms each product into a formatted string for the report.
Consumer: logProduct adds each filtered product to an audit log using peek.
Comparator: byPriceDesc sorts products by price in descending order.
Stream Pipeline: Chains filter, peek, sorted, and map to process the list at once.

Output:

Formatted Report:
Product: Laptop, Price: $999.99
Product: Phone, Price: $499.99
Product: Tablet, Price: $299.99

Audit Log:
Processed: Laptop (Electronics, $999.99)
Processed: Phone (Electronics, $499.99)
Processed: Tablet (Electronics, $299.99)

Conclusion

Predicate, Function, Consumer, and Comparator address the challenge of complex data processing by enabling a concise, functional pipeline. In this inventory example, they filtered, transformed, logged, and sorted products efficiently, reducing boilerplate compared to traditional loops and classes. With no external dependencies and tight integration with Java’s Stream API, these interfaces make code modular, readable, and maintainable, solving real-world data processing problems in modern Java applications.

The Builder Design Pattern in Java

William — Thu, 10 Jul 2025 02:07:53 +0000

Creating complex objects, like a custom Car, often involves juggling multiple attributes: engine, wheels, color, etc. Using a single constructor with many parameters is cumbersome and error-prone. How can we build such objects cleanly and flexibly? The Builder Design Pattern in Java provides a solution by separating the construction process from the object's representation, enabling step-by-step assembly.

What is the Builder Pattern?

The Builder Pattern is a creational design pattern that constructs complex objects incrementally using a dedicated Builder class. This approach improves code readability, supports flexible configurations, and avoids bloated constructors.

Example in Java

Below is a Java implementation of the Builder Pattern for building a car object:

Create Car class.

public class Car {

    private String engine;
    private int wheels;
    private String color;

    private Car() {}

    protected Car(CarBuilder builder) {
        this.engine = builder.engine;
        this.wheels = builder.wheels;
        this.color = builder.color;
    }

    @Override
    public String toString() {
        return "Car with " + engine + " engine, " + wheels + " wheels, and " + color + " color";
    }

    //get set
}

Create CarBuilder class in the same package of Car.

public class CarBuilder {

    protected String engine;
    protected int wheels;
    protected String color;

    public CarBuilder setEngine(String engine) {
        this.engine = engine;
        return this;
    }

    public CarBuilder setWheels(int wheels) {
        this.wheels = wheels;
        return this;
    }

    public CarBuilder setColor(String color) {
        this.color = color;
        return this;
    }

    public Car build() {
        return new Car(this);
    }
}

Use CarBuilder to return a instance of Car.

public class Main { 
    public static void main(String[] args) { 
        Car car = new CarBuilder()
                .setEngine("V8")
                .setWheels(4)
                .setColor("Red")
                .build();
        System.out.println(car); 
        // Output: Car with V8 engine, 4 wheels, and Red color 
    }
}

Advantages of the Builder Pattern

Readability: Method chaining creates a clear, fluent API for object construction.
Flexibility: Easily add or omit optional attributes without modifying the core class.
Immutability: The Car object is immutable, as all fields are final, enhancing thread safety.
Separation of Concerns: Construction logic is isolated in the Builder, keeping the Car class focused on its data.

Disadvantages of the Builder Pattern

Increased Code: Requires a separate Builder class, adding boilerplate code.
Overkill for Simple Objects: For objects with few attributes, the pattern may be unnecessarily complex.
Maintenance: Changes to the Car class (e.g., adding new fields) require corresponding updates to the Builder.

Spring Boot Example with Builder

In Spring Boot, the Builder Pattern is commonly used in configuration classes. Below is an example of a RestTemplate configuration using a custom RestTemplateBuilder to configure HTTP client settings:

@Configuration
public class RestTemplateConfig {

    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplateBuilder()
                .setConnectTimeout(Duration.ofSeconds(5))
                .setReadTimeout(Duration.ofSeconds(10))
                .build();
    }
}

Conclusion

The Builder Pattern in Java, including in Spring Boot, solves the problem of constructing complex objects by providing a clean, step-by-step approach. Whether building a Car or configuring a RestTemplate, it ensures readability, flexibility, and maintainability. While it introduces some code overhead, its benefits make it invaluable for complex systems, especially in Spring Boot applications where configuration objects are common.

Creating an API Gateway with Spring Boot

William — Mon, 07 Jul 2025 02:54:33 +0000

An API Gateway acts as a single entry point for client requests, routing them to appropriate backend services. It simplifies client interactions, enhances security, and provides features like load balancing, authentication, and monitoring.

What is an API Gateway and Why Use It?

An API Gateway(design pattern) is a server that handles incoming API requests and directs them to the relevant microservices. It serves as a reverse proxy, abstracting the complexity of a microservices architecture. Common use cases include:

Routing: Directing requests to the correct service.
Authentication/Authorization: Centralizing security checks.
Rate Limiting: Controlling request volumes.
Monitoring: Tracking API usage and performance.

Pros of Using an API Gateway

Simplifies client-side code by providing a unified interface.
Centralizes cross-cutting concerns like security and logging.
Improves scalability by distributing requests efficiently.
Enhances maintainability by decoupling clients from services.

API Gateway with Spring Boot

Spring Boot, combined with Spring Cloud Gateway, is a powerful choice for building an API Gateway due to its simplicity and robust ecosystem. Below, we’ll walk through the setup, including Maven dependencies and basic configuration.
The version of spring boot will be 3.4.3 and spring cloud 2024.0.1.

Step 1: Maven Dependencies
To get started, create a Spring Boot project and include the necessary dependencies in your pom.xml.

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

Step 2: Basic Configuration

Configure the API Gateway in the application.yml file and Eureka Server.

Information about the port, application name and Eureka server.

server:
  port: 8080
spring:
  application:
    name: api-gateway
eureka:
  instance:
    preferIpAddress: true
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka
    fetch-registry: true
    register-with-eureka: true

To exposes actuator endpoints for monitoring:

management:
  endpoints:
    web:
      exposure:
        include: health,info,gateway

Step 3: Route

Create a Bean RouterLocator to configure the route from Api Gateway to microservice, is possible to configure your circuit break and Header here.

@Bean
public RouteLocator routeConfig(RouteLocatorBuilder routeLocatorBuilder) {
    return routeLocatorBuilder.routes()
            .route(p -> p
                    .path("/<PATH_FROM_CLIENT>/**")
                    .filters( f -> f.rewritePath("/<PATH_FROM_CLIENT>/(?<segment>.*)","/${segment}")
                            .addResponseHeader("X-Response-Time", LocalDateTime.now().toString())
                    .uri("lb://<MICROSERVICE_APP_NAME>"))
            .build();
}

PATH_FROM_CLIENT: Inform the path that clients will call
MICROSERVICE_APP_NAME: Inform spring.application.name of the microservice of destination. With the help of Eureka Server, API Gateway will find the given microservice.

In this post the microservice name will be client-service and path client-service, but could be any value you desire.

Step 4: Test

With the Bean RouteLocator now all request send to /client-service/** will be redirect to microservice called client-service.

If you test request direct to client-service, not using API Gateway, will have the same result.

In the production application, the client service will be exposed only in the private network, and only through the Api Gateway will it be exposed.

Conclusion

An API Gateway is a vital component in a microservices architecture, simplifying client interactions and centralizing concerns like routing and security. With Spring Boot and Spring Cloud Gateway, setting up a basic API Gateway is straightforward, requiring minimal dependencies and configuration.
By following the steps above, you can quickly create a gateway to route requests to your services, paving the way for advanced features like authentication and rate limiting in future iterations.

Build optimized Docker images with JIB Maven Plugin

William — Tue, 01 Jul 2025 13:30:00 +0000

Jib is a plugin that builds optimized Docker images for Java applications. It organizes image layers efficiently, separating dependencies, resources, and application code, which reduces image size and speeds up rebuilds. with Maven, Jib is configured in the pom.xml file, enabling seamless integration into the build lifecycle.

How it works:

Project analysis: Jib reads the pom.xml to identify dependencies, classes, and resources.
Image building: Creates optimized layers (dependencies, resources, classes) and assembles the Docker image.
Publishing (optional): Pushes the image to a configured registry, such as Docker Hub.
Local execution (optional): Can run the image locally if Docker is available.

Jib doesn’t require a Dockerfile but allows customization through the pom.xml. It supports fast builds with reusable layers and is ideal for CI/CD pipelines.

Advantages of Jib with Maven

No Dockerfile: Simple configuration in pom.xml.
Fast builds: Reuses unchanged layers.
Portability: Doesn’t depend on a local Docker daemon.
Security: Supports authentication for private registries.
CI/CD integration: Compatible with tools like Jenkins and GitHub Actions.

Basic Configuration Example

Let’s set up Jib in a Maven project to create a Docker image for a simple Spring Boot application and publish it to Docker Hub.

Prerequisites:

Maven project with Java (Spring Boot).
Docker Hub account (for publishing).
Maven installed.

Step 1: Configure the pom.xml

<project>
  ...
  <build>
    <plugins>
      <plugin>
        <groupId>com.google.cloud.tools</groupId>
        <artifactId>jib-maven-plugin</artifactId>
        <version>3.4.3</version>
        <configuration>
          <from>
            <image>openjdk:17-jdk-slim</image>
          </from>
          <to>
<image>docker.io/youruser/${project.artifactId}:${project.version}</image>
          </to>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

Explanation:

from: Specifies the base image (here, openjdk:17-jdk-slim).
to: Defines the generated image name and registry (replace youruser with your Docker Hub username).

Step 2: Build the Image

Run the Maven command to build the image:

mvn compile jib:build

This compiles the project and builds the Docker image, pushing it directly to Docker Hub. If authentication isn’t configured, log in to Docker Hub.

Step 3: Test Locally (Optional)

To build the image without pushing to a registry, use:

mvn compile jib:dockerBuild

Then, run the image with:

docker run -p 8080:8080 youruser/my-app:latest

Conclusion

Jib streamlines Docker image creation for Java projects, integrating seamlessly with Maven to build and publish optimized images without Dockerfiles. Its simplicity and efficiency make it ideal for both small projects and complex CI/CD pipelines. Start using Jib to enhance your development workflow! 🚀

Official documentation: https://github.com/GoogleContainerTools/jib

@Valid + Jakarta with DTO in Spring Boot 3

William — Thu, 25 Jan 2024 03:28:42 +0000

Every API REST need validations, and to resolve the initial situations, can be use jakarta to help us to do it fast and don't necessarily create a IF for each atribute.

Add dependency

In the pom.xml put this new dependency to use jakarta.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-validation</artifactId>
</dependency>

Implement validations in DTO

In the DTO class, in this case only in record ProductCreateUpdate, put the annotations from jakarta before each variable.

package com.spring.models.dto;

import jakarta.validation.constraints.*;

public record ProductCreateUpdate(@NotBlank @Size(min = 2, max = 125) String name, @PositiveOrZero Double price, @Size(max = 500) String description) {
}

The annotations is not difficult understand, the name of each means what to do, it's possible use a combination in only one. You can figure out all annotations in this documentation.

For this validation to be used when receiving the body, it's necessary to use the @valid annotation in the controller method declaration.

import jakarta.validation.Valid;
public class ProductController {
[...]
    @PostMapping(consumes = MediaType.APPLICATION_JSON_VALUE,
            produces = MediaType.APPLICATION_JSON_VALUE)
    public ResponseEntity<Product> create(@RequestBody @Valid ProductCreateUpdate productCreate) {
        Product product = new Product();
        BeanUtils.copyProperties(productCreate, product);

        return ResponseEntity.status(HttpStatus.CREATED).body(service.create(product));
    }

    @PutMapping(path = "/{id}",
            consumes = MediaType.APPLICATION_JSON_VALUE,
            produces = MediaType.APPLICATION_JSON_VALUE)
    public ResponseEntity<Product> update(@PathVariable(value = "id") Long id, @RequestBody @Valid ProductCreateUpdate productUpdate) {
        Product product = new Product();
        BeanUtils.copyProperties(productUpdate, product);

        return ResponseEntity.status(HttpStatus.OK).body(service.update(product, id));
    }
[...]
}

How the body is of type ProductCreateUpdate, so put @valid before the body declaration. The validation is necessary only in the POST e PUT request, the validation will work equal for both.

Handle validation exception

To made the response of error look better when the data received is wrong, let's create a method to handle the MethodArgumentNotValidException in CustomizedResponseEntityExceptionHandler.

public class CustomizedResponseEntityExceptionHandler {
[...]
    @ExceptionHandler(MethodArgumentNotValidException.class)
    public final ResponseEntity<ExceptionResponse> handlerMethodArgumentValidExceptions(MethodArgumentNotValidException exception, WebRequest request) {
        var errors = exception.getFieldErrors().stream().map(fieldError -> "Field: " + fieldError.getField() + " Error: " + fieldError.getDefaultMessage()).toList();
        ExceptionResponse exceptionResponse = new ExceptionResponse(Instant.now(), errors.toString(), request.getDescription(false));

        return new ResponseEntity<>(exceptionResponse, HttpStatus.BAD_REQUEST);
    }

The method will take each message error from the list and put everything into a custom message.

Testing

In the postman make this request to create a Product.

POST localhost:8080/api/product

{
    "name": "",
    "price": -50.00,
    "description": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaA"
}

This test is to show all valiton working, look that the response code is 400 Bad Request and in the response, the message is easy to read and understand what is necessary to resolve.

Conclusion

In this post, we create a validation using only annotations by jakarta and that have many options to implement for each situation. Jakarta can be use to valid String, number, date, booleans...

Next Step

In the next step we will use Swagger to create a documentation about the API.

Using ResponseEntity with global exception handling in Spring Boot 3

William — Fri, 19 Jan 2024 01:48:35 +0000

Now that we already have one REST API working, let's improving with using a better response code and control all exception with a global class.

Create a global class to handle exceptions

First create a record class ExceptionResponse inside the new folder exceptions to return information about errors that occurred.

package com.spring.exceptions;

import java.time.Instant;

public record ExceptionResponse(Instant data, String message, String details) {
}

This record has a variable to return the instant that error occurred, and a message with details.

Now let's create a expeception ResourceNotFoundException
inside the folder exceptions to use when it isn't find a specific entity, in this case a Product.

package com.spring.exceptions;

import org.springframework.http.HttpStatus;
import org.springframework.web.bind.annotation.ResponseStatus;

@ResponseStatus(HttpStatus.NOT_FOUND)
public class ResourceNotFoundException extends RuntimeException {
    public ResourceNotFoundException(String messageError) {
        super(messageError);
    }
}

The @ResponseStatus annotation are used to inform the default return code for that exception, in this case NOT_FOUND = 404.

To finish this part, it's necessary create a global class, create a class CustomizedResponseEntityExceptionHandler inside the folder exceptions a new folder handler.

package com.spring.exceptions.handler;

import com.spring.exceptions.ExceptionResponse;
import com.spring.exceptions.ResourceNotFoundException;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.context.request.WebRequest;

import java.time.Instant;

@ControllerAdvice
@RestController
public class CustomizedResponseEntityExceptionHandler {

    @ExceptionHandler(Exception.class)
    public final ResponseEntity<ExceptionResponse> handlerAllExceptions(Exception exception, WebRequest request) {
        ExceptionResponse exceptionResponse = new ExceptionResponse(Instant.now(), exception.getMessage(), request.getDescription(false));
        return new ResponseEntity<>(exceptionResponse, HttpStatus.INTERNAL_SERVER_ERROR);
    }

    @ExceptionHandler(ResourceNotFoundException.class)
    public final ResponseEntity<ExceptionResponse> handlerNotFoundExceptions(Exception exception, WebRequest request) {
        ExceptionResponse exceptionResponse = new ExceptionResponse(Instant.now(), exception.getMessage(), request.getDescription(false));
        return new ResponseEntity<>(exceptionResponse, HttpStatus.NOT_FOUND);
    }

}

This class is using the @ControllerAdvice annotation to deal with all exceptions in the app, it's a way to control in only one place. In this part you decide with is better to control case a case or all in one.
This class is a Controller because use @RestController, and each method with @ExceptionHandler annotation means that when that exception occurs that method will be responsible for the treatment and return.

We are using a global Exception to deal with the global expection and ResourceNotFoundException for the situation mentioned before.

Use ResourceNotFoundException in ProductService

Now let's improve the methods, first with the method findById.

    public Product findById(Long id) {
        return repository.findById(id).orElseThrow(() -> new ResourceNotFoundException("Not found Product with this ID"));
    }

When not found a product with the given ID, exception will be thrown.

About the update and delete, only refractory to use findById.

    @Transactional
    public Product update(Product product, Long id) {
        var productPersisted = findById(id);

        BeanUtils.copyProperties(product, productPersisted, "id");

        return repository.save(productPersisted);
    }

    @Transactional
    public void delete(Long id) {
        var productPersisted = findById(id);
        repository.delete(productPersisted);
    }

Use ResponseEntity in ResponseEntity

All methods need to return a ResponseEntity with the perfect code to that situation, so look the below change.

    @PostMapping(consumes = MediaType.APPLICATION_JSON_VALUE,
            produces = MediaType.APPLICATION_JSON_VALUE)
    public ResponseEntity<Product> create(@RequestBody ProductCreateUpdate productCreate) {
        Product product = new Product();
        BeanUtils.copyProperties(productCreate, product);

        return ResponseEntity.status(HttpStatus.CREATED).body(service.create(product));
    }

    @GetMapping(path = "/{id}", produces = MediaType.APPLICATION_JSON_VALUE)
    public ResponseEntity<Product> findById(@PathVariable(value = "id") Long id) {
        return ResponseEntity.status(HttpStatus.OK).body(service.findById(id));
    }

    @GetMapping(produces = MediaType.APPLICATION_JSON_VALUE)
    public ResponseEntity<List<Product>> findAll() {
        var products = service.findAll();
        if (products.isEmpty()) return ResponseEntity.noContent().build();
        return ResponseEntity.status(HttpStatus.OK).body(products);
    }

    @PutMapping(path = "/{id}",
            consumes = MediaType.APPLICATION_JSON_VALUE,
            produces = MediaType.APPLICATION_JSON_VALUE)
    public ResponseEntity<Product> update(@PathVariable(value = "id") Long id, @RequestBody ProductCreateUpdate productUpdate) {
        Product product = new Product();
        BeanUtils.copyProperties(productUpdate, product);

        return ResponseEntity.status(HttpStatus.OK).body(service.update(product, id));
    }

    @DeleteMapping(path = "/{id}")
    public ResponseEntity<?> delete(@PathVariable(value = "id") Long id) {
        service.delete(id);
        return ResponseEntity.noContent().build();
    }

The ResponseEntity is used to return a entity declare in <>, to return a specific code, use the method .status() with enum HttpStatus, and a body use .body().
The method create will return a code CREATED = 201 and a entity Product.
The method findById and update return OK = 200 with the product, but if not find a Product with that ID, the return is NOT_FOUND.
The method findAll return OK if exist some value, else return NO_CONTENT = 204.
The method delete always return NO_CONTENT because don't have a product, but like the findById and update when not find a product return NOT_FOUND.

Testing

In Postman do this request to see the different codes.

Now when the POST localhost:8080/api/product is requested, the code return is 201 Created.

When the GET/PUT localhost:8080/api/product/1 is requested, the response code is 200 OK, but if put a ID that don't exist the return is 404 NOT FOUND.

The GET localhost:8080/api/product now return 200 OK when find some product, but if doesn't exist anyone, return 204 No Content.

To finish the DELETE in localhost:8080/api/product/1 return 204 No Content.

Noticed that when a custom exception error ResourceNotFoundException is returned, a return comes as created in the record class ExceptionResponse.

I don't do all possible return because they are like in class ProductController explanation, but feel free to test all.

Conclusion

In this post, we create the global class with @ControllerAdvice annotation to deal with all expectations.
Also improving the service and controller class to use ResponseEntity.

Next Step

In the next step we will create validations in the body of the request received.