Generative AI has unlocked solutions to problems previously considered impractical or even impossible to automate. Take email management, for example. The daily influx of client inquiries, meeting requests, and project updates, it can consume your entire workday. While simple AI solutions promise relief but they often fall short, generating generic and context-blind replies.

In this article, we will move beyond basic “one-shot” LLM prompts to build an intelligent email responder using Prompt Chaining, Context Engineering, and LangGraph for robust orchestration. We will build a sophisticated multi-step workflow that:

1. Extracts intent and key information from an incoming email
2. Generates a structured outline for the response
3. Drafts the complete email body
4. Rewrites the draft to match your desired tone (formal, friendly, etc.)

By the end, you will have a clear understanding of how to decompose complex AI tasks into reliable workflows.

But before we dive into implementation, we need to understand what Prompt Chaining, Context Engineering, and LangGraph are.

Prompt Chaining

What is Prompt Chaining?

Prompt chaining involves breaking down a complex task into a sequence of smaller, more manageable steps, with each step handled by a separate LLM prompt. The output from one prompt then serves as the input for the subsequent prompt, allowing the LLM to build a final solution incrementally. For example, one prompt could extract key entities from a document, and a second prompt could then use these entities to generate a summary.

Prompt chaining workflow

Prompt Chaining offers several advantages:

• Improved Accuracy: The main advantage of the chaining prompts is that it allows iterative refinements, improving accuracy of the final output. However the downside of this workflow is latency. It trade offs latency for higher accuracy.

• Scalability: Chaining prompts allow generation of long or detailed content by breaking down into smaller, and manageable parts.

Why Prompt Chaining Matters

This approach ensures each step has a focused responsibility, making the system more reliable and debuggable than a single monolithic prompt.

Examples where prompt chaining can be useful:

• Content Creation: Generating detailed articles, stories, or scripts by chaining related prompts.
• Language Translation: Translating text across multiple languages using a chain of prompts to ensure accuracy and fluency.

Context Engineering

LLMs are stateless, meaning they don’t retain memory of past interactions between calls. To get best results, we must provide an optimized context during each interaction.

Context refers to everything sent to the model in the prompt and can include:

• Instructions (what the model is supposed to do)
• User input or questions
• External data (RAG)
• State or history (e.g., tool calls, results from previous tool calls or prior messages in a conversation)
• Expected output structure (e.g., response format, schema, or constraints)

Context engineering is the process of curating, structuring, and managing the input (context window) provided to a language model in order to maximize its performance on a given task.

LangGraph

In this article, we’ll use LangGraph to build an intelligent email responder.

But what exactly is LangGraph?

LangGraph is an open-source AI agent framework, for building, deploying, and managing complex AI Agentic systems. It’s a low-level framework for building stateful, long-running, multi-actor agents and workflows.

Before we begin the implementation, let’s first understand the core concepts behind LangGraph.

Core Concepts of LangGraph

LangGraph is build on the concept of graph. In LangGraph, you build a graph, instead of linear chains (LangChain). This makes LangGraph better for complex workflows eg: loops, branching, retries, multi-agent coordination

Following are the core concepts in LangGraph:

1. State:

   • Unlike LangChain’s memory, LangGraph uses a state object that is passed and updated as nodes run.
   • A state is a dictionary (TypedDict) of all variables your workflow needs. Its a data structure/context passed between steps.
   • Example:

     class State(TypedDict):
       question: str
       classification: str | None
       answer: str | None
     

2. Nodes:

   • A node is a function that takes in state and returns the updates
   • Nodes can call LLMs, APIs, or some logic
   • Example:

     def classify_node(state):
         q = state["question"]
         if "hello" in q.lower():
             return {"classification": "greeting"}
         return {"classification": "question"}
     

3. Edges:

   • Edges connect nodes
   • They can be fixed (always go A → B) or conditional (branch depending on state)
   • LangGraph supports Control Flow:
     • Branching: if condition X, go to Node ‘A’; else, go to Node ‘B’
     • Loops: repeat until condition met (retry, re-ask user, refine)
     • Parallel: run multiple nodes on a list and merge (map-reduce)

4. Tools:

   • Tool is a function or action that your agents can use to get something done like calling an API, doing a calculation, searching a database, or accessing a file.
   • Think of tools as skills or abilities that you give your agent.

5. Durable execution & Checkpointing:

   • LangGraph can pause and resume workflows
   • Useful for long-running agents or workflows with human approval

6. StateGraph:

   • A graph that connects nodes and edges together
   • A StateGraph is a flowchart of steps (nodes) your AI agent goes through to complete a task

Setting up LangGraph

This section will guide you through the process of installing and configuring LangGraph in your development environment.

• First ensure that Python 3.12 or later is installed on your machine

• Create a Virtual Environment

  python -m venv .
  source langgraph_env/bin/activate 
  

• Install LangGraph dependencies

  pip install langgraph python-dotenv
  pip install langchain-openai   # integration package
  

  Set environment variable OPENAI_API_KEY.

  export OPENAI_API_KEY="your-api-key"
  

• Verify Installation

  import langgraph
  
  print(langgraph.__version__)
  

Implementation: Building Email Assistant Step by Step

Now that we understand the core concepts, let’s start building AI Email Assistant using LangGraph. We’ll model the email response process as a structured pipeline where each step builds upon the previous one.

Defining Processing Pipeline

Our AI assistant will transform incoming emails into thoughtful responses through four distinct stages:

• Input: Raw email text
• Step 1: Extract key information and intent
• Step 2: Generate a structured response outline
• Step 3: Draft the complete email body
• Step 4: Apply tone transformation (professional, friendly, casual, etc.)
• Output: Polished, context-aware email response

The chain will look like following

Chain:

1. Prompt 1 → “Extract intent and key info from incoming email”
2. Prompt 2 → “Generate a response outline”
3. Prompt 3 → “Draft complete email body”
4. Prompt 4 (Optional) → “Apply tone transformation (professional, friendly, casual, etc.)”

Implementation

1. Lets first define the tools and the model

   load_dotenv()
   
   @tool
   def last_unread_email() -> str:
       # your logic to retrieve last unread email
       return """
       From: adam@example.com
       Date: 2024, Dec 12 14:00
       Subject: Bulk Order Inquiry
   
       Hi Neha,
   
       I’m reaching out to inquire about the availability of your product in bulk.
       We are looking to order around 500 units and would like to know the pricing and delivery timeline.
       Please get back to me by the end of the week.
   
       Best Regards,
       Adam Willson
       """
   
   tools = [last_unread_email]
   tools_by_name = {tool.name: tool for tool in tools}
   llm = init_chat_model(model=os.getenv("MODEL_NAME"), model_provider=os.getenv("MODEL_PROVIDER"), temperature=0)
   

   Make sure to add .env file with two variables:

   MODEL_PROVIDER=<model-provider>
   MODEL_NAME=<model-name>
   

2. Next, we define the state, which will consist of five fields:

   • **email_text**: Represents the raw incoming email content.
   • **extraction**: A structured model that extracts the email’s intent, tone, questions, and urgency.
   • **reply_outline**: A preliminary outline for drafting a response.
   • **full_email**: The body of the drafted response.
   • **final_polished_email**: The polished version of the email ready for sending.

   At each stage of processing, the state will be used and updated by the nodes.

   class EmailIntentExtraction(BaseModel):
       intent: str
       questions: list[str]
       tone: str
       urgency: str
   
       @classmethod
       def empty(cls) -> "EmailIntentExtraction":
           return EmailIntentExtraction(intent="", questions=[], tone="", urgency="")
   
   class State(TypedDict):
       email_text: str
       extraction: EmailIntentExtraction
       reply_outline: str
       full_email: str
       final_polished_email: str
   

3. The next step is to define the nodes, which can be call to LLM (Large Language Model), external APIs, or custom logic.

   def get_last_unread_email(state: State) -> dict[str, Any]:
       llm_with_tools = llm.bind_tools(tools)
       message = llm_with_tools.invoke(
           [
               SystemMessage(content="You are a helpful assistant that can get unread emails."),
               HumanMessage(content="Get last unread mail from inbox"),
           ]
       )
   
       # unnecessary: message is of type BaseMessage
       if not isinstance(message, AIMessage):
           return {}
   
       result = []
   
       if message.tool_calls:
           for tool_call in message.tool_calls:
               tool = tools_by_name[tool_call["name"]]
               tool_result = tool.invoke(tool_call["args"])
               result.append(tool_result)
       else:
           result.append(message.content)
   
       return {"email_text": "\n".join(result)}
   
   
   def extract_intent_key_info(state: State) -> dict[str, Any]:
       extraction_prompt = f"""
       Extract the following information from the email below:
       1. Sender's intent
       2. Specific questions or requests
       3. Tone of the email
       4. Urgency or deadline
   
       Email:
       \"\"\"
       {state["email_text"]}
       \"\"\"
   
       Respond in JSON format.
       """
   
       llm_with_structured_output = llm.with_structured_output(EmailIntentExtraction)
   
       message = llm_with_structured_output.invoke(
           [
               SystemMessage(content="You are a helpful assistant that extracts structured data from emails."),
               HumanMessage(content=extraction_prompt),
           ]
       )
   
       return {"extraction": message}
   
   
   def generate_reply_outline(state: State) -> dict[str, Any]:
       extracted_info: EmailIntentExtraction = state["extraction"]
   
       outline_prompt = f"""
       You are an email assistant.
   
       Based on the following extracted info, generate a structured email **outline** with these parts:
       1. Greeting
       2. Acknowledgment of the sender's intent
       3. Answers to questions or information needed
       4. Next steps or follow-up
       5. Closing
   
       Make sure the tone is {extracted_info.tone} and mention that a response will be sent before
       {extracted_info.urgency.lower()}.
   
       Extracted Info:
       {extracted_info.model_dump_json()}
       """
   
       message = llm.invoke(
           [
               SystemMessage(
                   content="You are a helpful assistant that generates email outlines based on extracted intent."
               ),
               HumanMessage(content=outline_prompt),
           ]
       )
   
       return {"reply_outline": message.content}
   
   
   def generate_full_reply_email(state: State) -> dict[str, Any]:
       email_outline = state["reply_outline"]
       compose_prompt = f"""
       Using the following email outline, write a professional and polite email reply.
   
       Format it as a formal business email. Keep the tone professional.
   
       Outline:
       {email_outline}
       """
       message = llm.invoke(
           [
               SystemMessage(content="You are an AI that writes professional business emails based on outlines."),
               HumanMessage(content=compose_prompt),
           ]
       )
   
       return {"full_email": message.content}
   
   
   def __get_rewrite_prompt(email_text: str, tone: Literal["friendly", "formal", "casual", "firm"]):
       return f"""
       Rewrite the following email in a more **{tone}** tone.
       Keep all the original information intact, but adapt the language to fit the new tone.
   
       Email:
       \"\"\"
       {email_text}
       \"\"\"
       """
   
   
   def tone_rewriter(state: State) -> dict[str, Any]:
       full_email = state["full_email"]
       prompt = __get_rewrite_prompt(full_email, "formal")
   
       message = llm.invoke(
           [
               SystemMessage(
                   content=(
                       "You are an assistant that rewrites emails in different tones while keeping the original meaning."
                   )
               ),
               HumanMessage(content=prompt),
           ]
       )
   
       return {"final_polished_email": message.content}
   

4. Next, define the logic to determine whether to end the process (Conditional Gate). For example, you can check if the email contains at least 100 characters. You can also customize this logic to suit your specific requirements.

   def validate_incoming_email(state: State) -> str:
       if len(state["email_text"].strip()) >= 100:
           return "extract_intent_key_info"
       return END
   

5. Build workflow

   # Build workflow
   workflow = StateGraph(State)
   
   # Add nodes
   workflow.add_node("get_last_unread_email", get_last_unread_email)
   workflow.add_node("extract_intent_key_info", extract_intent_key_info)
   workflow.add_node("generate_reply_outline", generate_reply_outline)
   workflow.add_node("generate_full_reply_email", generate_full_reply_email)
   workflow.add_node("tone_rewriter", tone_rewriter)
   
   # Add edges to connect nodes
   workflow.add_edge(START, "get_last_unread_email")
   workflow.add_conditional_edges("get_last_unread_email", validate_incoming_email, ["extract_intent_key_info", END])
   workflow.add_edge("extract_intent_key_info", "generate_reply_outline")
   workflow.add_edge("generate_reply_outline", "generate_full_reply_email")
   workflow.add_edge("generate_full_reply_email", "tone_rewriter")
   workflow.add_edge("tone_rewriter", END)
   
   chain = workflow.compile()
   

6. Invoke the workflow

   initial_state = {
       "email_text": "",
       "extraction": EmailIntentExtraction.empty(),
       "reply_outline": "",
       "full_email": "",
       "final_polished_email": "",
   }
   messages = chain.invoke(initial_state)
   
   for key in messages:
       print(f"{key}: ")
       print(messages[key])
       print("---------------------------------------------")
   

7. Test

   # Input emails
   input_email = """
   From: adam@example.com
   Date: 2024, Dec 12 14:00
   Subject: Bulk Order Inquiry
   
   Hi Neha,
   
   I’m reaching out to inquire about the availability of your product in bulk.
   We are looking to order around 500 units and would like to know the pricing and delivery timeline.
   Please get back to me by the end of the week.
   
   Best Regards,
   Adam Willson
   """
   

   Response (tone “formal”)

   extraction:
   intent='Inquiring about bulk order' questions=['What is the pricing for 500 units?', 'What is the delivery timeline for 500 units?'] tone='Professional' urgency='End of the week'
   
   ---------------------------------------------
   
   reply_outline:
   Here is an email outline based on the information provided:
   
   **Subject: Re: Bulk Order Inquiry - 500 Units**
   
   1.  **Greeting**
       *   Dear [Sender Name],
   
   2.  **Acknowledgment of Sender's Intent**
       *   Thank you for reaching out to us regarding your interest in a bulk order. We appreciate you considering our products.
       *   We understand you are specifically inquiring about the pricing and delivery timeline for 500 units.
   
   3.  **Answers to Questions / Information Needed**
       *   We are currently compiling the detailed information regarding the pricing structure for 500 units and the estimated delivery timeline.
       *   Please be assured that we will send a comprehensive response addressing both of your questions before the end of the week.
   
   4.  **Next Steps / Follow-up**
       *   We look forward to providing you with the necessary details and assisting you further with your bulk order.
       *   Should you have any additional questions in the meantime, please do not hesitate to contact us.
   
   5.  **Closing**
       *   Sincerely,
       *   [Your Name/Company Name]
   
   ---------------------------------------------
   
   full_email: 
   Subject: Re: Bulk Order Inquiry - 500 Units
   
   Dear [Sender Name],
   
   Thank you for reaching out to us regarding your interest in a bulk order. We appreciate you considering our products and understand you are specifically inquiring about the pricing and delivery timeline for 500 units.
   
   We are currently compiling the detailed information regarding the pricing structure for 500 units and the estimated delivery timeline. Please be assured that we will send a comprehensive response addressing both of your questions before the end of the week.
   
   We look forward to providing you with the necessary details and assisting you further with your bulk order. Should you have any additional questions in the meantime, please do not hesitate to contact us.
   
   Sincerely,
   
   [Your Name/Company Name]
   
   ---------------------------------------------
   
   final_polished_email: 
   Subject: Re: Bulk Order Inquiry - 500 Units
   
   Dear [Sender Name],
   
   We acknowledge receipt of your inquiry regarding a bulk order. We appreciate your interest in our products and note your specific request concerning the pricing and estimated delivery timeline for 500 units.
   
   We are currently in the process of compiling the comprehensive details pertaining to the pricing structure for 500 units and the projected delivery schedule. Please be advised that a comprehensive response addressing both of your inquiries will be dispatched prior to the close of this week.
   
   We anticipate furnishing you with the requisite details and offering further assistance with your bulk order. Should you require any additional information or have further questions in the interim, please do not hesitate to contact us.
   
   Sincerely,
   
   [Your Name/Company Name]
   ---------------------------------------------
   

Conclusion

In this article, we’ve built a sophisticated AI Email Assistant that demonstrates the power of modern LLM orchestration. By decomposing the complex task of email response into manageable steps using Prompt Chaining, we created a system that is more reliable, and effective than a single monolithic prompt.

This approach doesn’t just apply to email assistants, the same pattern can be applied to countless other AI applications, from customer support systems to content generation pipelines.

It’s widely used and very flexible, perfect for cases where you want to avoid complex if-else or switch statements.

Use cases

• You want to replace conditionals (if-else or switch) with polymorphism.
• You need to switch behavior at runtime or make it configurable. Example: User selecting payment option
• You want to define multiple ways of doing something (e.g., sorting, compression, payment).

Core Concepts

The pattern consists of three main components:

1. Strategy: An interface or abstract class that defines a common method for all concrete strategies. The context uses this interface to call the algorithm.

2. Concrete Strategy: The classes that implement the Strategy interface. Each class provides a specific implementation of the algorithm.

3. Context: The class that holds a reference to a Strategy object. It uses the strategy’s method to perform a certain action. The context is unaware of the concrete strategy being used, it only interacts with the Strategy interface.

Example

Payment Strategy

1. Strategy Interface

public interface PaymentStrategy {
    void pay(double amount);
}

2. Concrete Strategies

public class CreditCardPayment implements PaymentStrategy {
    @Override
    public void pay(double amount) {
        System.out.println("Paid $" + amount + " using Credit Card.");
    }
}

public class PayPalPayment implements PaymentStrategy {
    @Override
    public void pay(double amount) {
        System.out.println("Paid $" + amount + " using PayPal.");
    }
}

public class CryptoPayment implements PaymentStrategy {
    @Override
    public void pay(double amount) {
        System.out.println("Paid $" + amount + " using Cryptocurrency.");
    }
}

3. Context Class

public class PaymentContext {
    private PaymentStrategy strategy;

    public PaymentContext() {}

    // optional - for example you want to provide default strategy 
    public PaymentContext(PaymentStrategy strategy) {
        this.strategy = strategy
    }

    // Strategy can be changed at runtime
    public void setStrategy(PaymentStrategy strategy) {
        this.strategy = strategy;
    }

    public void payAmount(double amount) {
        if (strategy == null) {
            throw new IllegalStateException("Payment strategy not set.");
        }
        strategy.pay(amount);
    }
}

Kotlin implementation (functional style strategy)

In kotlin, you can implement Strategy patten using OOP approach and functional style approach. OOP way is similar to how we implemented in java.

Function style strategy

typealias PaymentStrategy = (Double) -> Unit

class PaymentContext(private var strategy: PaymentStrategy) {
    fun setStrategy(strategy: PaymentStrategy) {
        this.strategy = strategy
    }

    fun pay(amount: Double) = strategy(amount)
}

fun main() {
    val creditCardPayment: PaymentStrategy = { amount ->
        println("Paid \$$amount using Credit Card.")
    }

    val paypalPayment: PaymentStrategy = { amount ->
        println("Paid \$$amount using PayPal.")
    }

    val cryptoPayment: PaymentStrategy = { amount ->
        println("Paid \$$amount using Cryptocurrency.")
    }

    val context = PaymentContext(creditCardPayment)
    context.setStrategy(paypalPayment)
    context.pay(100.0)
}

Real world use-cases

• Comparator<T> for sorting in Java

• ThreadPoolExecutor with RejectedExecutionHandler

• Logging frameworks (ConsoleLogger, FileLogger, RemoteLogger)

Drawbacks

• The pattern can lead to explosion of classes and objects. For every new algorithm, you need to create a new concrete strategy class.
• The client (or context) needs to be aware of the different available strategies to choose and instantiate the correct one.
• While the pattern simplifies the context by removing conditional logic, it can introduce more complexity overall.
• For very simple, straightforward algorithms, using a strategy interface and multiple classes can be overkill.

Parking Lot Problem

In this article, let’s take it a step further and solve the Parking Lot Problem using the Strategy Pattern.

Problem: Let’s say we want to design a Parking Lot system. It should assign an available parking spot to any vehicle that wants to park. The way spots are assigned can vary depending on different rules or criteria (eg: vehicle size, vip vehicle, ..). New requirements might also change how the system chooses a parking spot.

As you can see, there can be multiple ways to assign a parking spot. For example, larger vehicles like trucks may require dedicated spaces that differ from those used by regular cars. Also, we may get new requirements or there may be changes in the requirements. Using a traditional approach with multiple if-else or switch statements can quickly become hard to manage and scale. A better solution for this scenario is the Strategy Pattern, which allows us to define different spot assignment strategies based on specific criteria, making the system more flexible and maintainable.

Lets first define the strategy

1. Define Strategy

// implementations will be like Car, Truck, SUV, Bike ..
interface Vehicle {
  String name();
}

interface ParkingStrategy {
  int findAvailableSlot(Vehicle vehicle);
}

2. Concrete Strategies

Lets now define the Concrete Strategies. Let say we have 3 strategies:

• ClosestSpotParkingStrategy: Assign the nearest vacant spot to the entrance to reduce the time taken for vehicles to park.
• TypeBasedParkingStrategy: Reserve specific spots for different types of vehicles (e.g., compact cars, oversized vehicles).
• PriorityParkingStrategy: Implement priority parking for certain vehicles based on factors like membership status, VIP status, or special needs.

class ClosestSpotParkingStrategy implements ParkingStrategy {

  @Override
  public int findAvailableSlot(Vehicle vehicle) {
    System.out.println("Using closest spot parking strategy..");
    // fake spot number
    return 17; // implement closest spot parking logic
  }
}

class TypeBasedParkingStrategy implements ParkingStrategy {

  @Override
  public int findAvailableSlot(Vehicle vehicle) {
    System.out.println("Using type based parking strategy..");
    // fake spot number
    return 101; // implement type based spot parking logic
  }
}

class PriorityParkingStrategy implements ParkingStrategy {

  @Override
  public int findAvailableSlot(Vehicle vehicle) {
    System.out.println("Using priority parking strategy..");
    // fake spot number
    return 1011; // implement priority spot parking logic
  }
}

As you can see, we can easily create new strategies by implementing the ParkingStategy interface and implement the logic based on new requirements without modifying the existing code.

3. Define Context Class

class ParkingLot {
  // default strategy
  private ParkingStrategy strategy = new ClosestSpotParkingStrategy();

  public ParkingLot() {}

  // or provide default strategy
  public ParkingLot(ParkingStrategy strategy) {
    this.strategy = strategy;
  }

  public void setParkingStrategy(ParkingStrategy strategy) {
    this.strategy = strategy;
  }

  public int parkVehicle(Vehicle vehicle) {
    int slot = strategy.findAvailableSlot(vehicle);
    System.out.println("Parking " + vehicle.name() + " in slot -> " + slot + ".");
    return slot;
  }
}

4. Client code implementation

public class Application {

  public static void main(String[] args) {
    final var parkingLot = new ParkingLot();
    parkingLot.setParkingStrategy(new PriorityParkingStrategy());
    parkingLot.parkVehicle(new Car("Rolls-Royce"));
  }
}

### Conclusion

The Strategy Pattern is a powerful behavioral design pattern that promotes flexibility and maintainability in your code. By encapsulating algorithms into separate classes (strategies), it allows you to switch between them at runtime, eliminating the need for complex conditional statements.

While Strategy Pattern introduces more classes, the benefits of decoupling the algorithm from the context often outweigh this drawback, especially in complex applications where behavior needs to change dynamically.

Use case

Use the Builder Pattern when:

• An object has many optional fields or configurations.

• You want to avoid constructor telescoping (i.e., too many overloaded constructors).

• You need to create immutable objects step by step.

public class User {
    private String firstName;
    private String lastName;
    private int age;
    private String email;
    private String phone;

    public User(String firstName, String lastName) { ... }
    public User(String firstName, String lastName, int age) { ... }
    public User(String firstName, String lastName, int age, String email) { ... }

    // ...
}

In above example, you can see User class is hard to maintain and read.

Core Concepts

1. Product: The complex object being built. It’s typically a class with many fields.
2. Builder: An interface or abstract class that defines the steps to build the product.
3. ConcreteBuilder: A class that implements the Builder interface and provides specific implementation for building the product. It keeps track of the object being built and provides a method (build) to return the final product.

Note: The Builder pattern can be implemented with or without a formal Builder interface or abstract class. The core concept is the separate builder object, not the strict use of an interface.

Implementation

public class User {
    // Required fields 
    private final String firstName;
    private final String lastName;

    // Optional fields
    private final Integer age;
    private final String email;
    private final String phone;

    private User(Builder builder) {
        this.firstName = builder.firstName;
        this.lastName = builder.lastName;
        this.age = builder.age;
        this.email = builder.email;
        this.phone = builder.phone;
    }

    // Builder Class
    public static class Builder {
        private final String firstName;
        private final String lastName;

        private Integer age;
        private String email;
        private String phone;

        public Builder(String firstName, String lastName) {
            this.firstName = firstName;
            this.lastName = lastName;
        }

        public Builder age(int age) {
            this.age = age;
            return this;
        }

        public Builder email(String email) {
            this.email = email;
            return this;
        }

        public Builder phone(String phone) {
            this.phone = phone;
            return this;
        }

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

    @Override
    public String toString() {
        return "User{" +
                "firstName='" + firstName + '\'' +
                ", lastName='" + lastName + '\'' +
                ", age=" + age +
                ", email='" + email + '\'' +
                ", phone='" + phone + '\'' +
                '}';
    }
}

Client Code:

public class Main {
    public static void main(String[] args) {
        User user = new User.Builder("John", "Doe")
                .age(30)
                .email("john@example.com")
                .phone("1234567890")
                .build();

        System.out.println(user);
    }
}

Real world examples

• StringBuilder (JDK)
• java.time.LocalDateTime.Builder
• AlertDialog.Builder in Android
• Libraries like Lombok, Project Lombok @Builder

Drawbacks

• More boilerplate code
• Verbose
• Testing complexity
• Cannot enforce field dependencies easily

Kotlin Implementation (using DSL)

You can simplify builder creation using Kotlin’s function literals with receivers:

data class User(
    val firstName: String,
    val lastName: String,
    var age: Int? = null,
    var email: String? = null,
    var phone: String? = null
)

class UserBuilder(private val firstName: String, private val lastName: String) {
    var age: Int? = null
    var email: String? = null
    var phone: String? = null

    fun build() = User(firstName, lastName, age, email, phone)
}

fun buildUser(firstName: String, lastName: String, block: UserBuilder.() -> Unit): User {
    val builder = UserBuilder(firstName, lastName)
    builder.block()
    return builder.build()
}

Client Code

val user = buildUser("Jane", "Doe") {
    age = 28
    email = "jane@example.com"
    phone = "012356789"
}

Factory Pattern is creational pattern that delegate the instantiation of objects to a separate method or class.

The Factory design pattern provides an interface for creating objects in a superclass, but allows subclasses to alter the type of objects that’ll be created. This pattern helps to decouple the client code from the concrete classes it needs to instantiate.

Core Components

The Factory pattern has three main components:

1. Product: This is the interface that all objects created by the factory must implement.

2. Concrete Products: These are the actual implementations of the Product interface. The factory will create these objects.

3. Creator (Factory) : This class declares the method that returns a Product object.

Use cases

• When you need to create objects without exposing instantiation logic
• When your code needs to work with multiple related classes
• When object creation involves complex logic

Example

1. Create an Interface (Product)

public interface Shape {
    void draw();
}

2. Concrete Implementations (Concrete Products)

public class Circle implements Shape {
    public void draw() {
        System.out.println("Drawing a Circle");
    }
}

public class Rectangle implements Shape {
    public void draw() {
        System.out.println("Drawing a Rectangle");
    }
}

public class Square implements Shape {
    public void draw() {
        System.out.println("Drawing a Square");
    }
}

3. Factory Class (Creator)

public class ShapeFactory {

    // Factory method
    public Shape getShape(String shapeType) {
        if (shapeType == null) {
            return null;
        }

        switch (shapeType.toLowerCase()) {
            case "circle":
                return new Circle();
            case "rectangle":
                return new Rectangle();
            case "square":
                return new Square();
            default:
                throw new IllegalArgumentException("Unknown shape type: " + shapeType);
        }
    }
}

4. Client Code

public class Main {
    public static void main(String[] args) {
        ShapeFactory factory = new ShapeFactory();

        Shape shape1 = factory.getShape("circle");
        shape1.draw();

        Shape shape2 = factory.getShape("rectangle");
        shape2.draw();

        Shape shape3 = factory.getShape("square");
        shape3.draw();
    }
}

Kotlin Implementation

Using sealed classes improves type safety and ensures all cases are handled at compile time.

sealed class ShapeType {
    object Circle : ShapeType()
    object Square : ShapeType()
    object Rectangle : ShapeType()
}

interface Shape {
    fun draw()

    // Creator (Factory Method)
    companion object {
        fun create(type: ShapeType): Shape = when (type) {
            ShapeType.Circle -> Circle()
            ShapeType.Square -> Square()
            ShapeType.Rectangle -> Rectangle()
        }
    }
}

// concrete creators
class Circle : Shape {
    override fun draw() = println("Drawing a Circle")
}

class Square : Shape {
    override fun draw() = println("Drawing a Square")
}

class Rectangle : Shape {
    override fun draw() = println("Drawing a Rectangle")
}

// client code
fun main() {
    val shape = Shape.create(ShapeType.Rectangle)
    shape.draw()
}

Drawbacks

• Code can become bloated with many conditionals
• Not ideal for few object types

We can use Abstract Factory Pattern to fix code bloat.

Abstract Factory Design Pattern

The Abstract Factory Pattern is an extension of the Factory Method Pattern. Abstract Factory provides an interface for creating families of related or dependent objects without specifying their concrete classes.

Core Components

The Abstract Factory pattern consists of four main roles:

1. Abstract Product: These are the interfaces for each type of product in the family (e.g., Button, Checkbox).

2. Concrete Product: These are the actual implementations of the Abstract Products, grouped by their specific variant (e.g., AndroidButton, iOSButton).

3. Abstract Factory: This is an interface that declares the creation methods for each distinct product in the product family.

4. Concrete Factory: These classes implement the Abstract Factory interface, with each one corresponding to a specific variant or family of products. They are responsible for creating the concrete products.

Example

1. Product Interfaces

public interface Button {
    void click();
}

public interface Checkbox {
    void check();
}

2. Concrete Products

public class AndroidButton implements Button {
    public void click() {
        System.out.println("Android Button Clicked");
    }
}

public class AndroidCheckbox implements Checkbox {
    public void check() {
        System.out.println("Android Checkbox Checked");
    }
}

public class IOSButton implements Button {
    public void click() {
        System.out.println("iOS Button Clicked");
    }
}

public class IOSCheckbox implements Checkbox {
    public void check() {
        System.out.println("iOS Checkbox Checked");
    }
}

3. Abstract Factory Interface

public interface UIFactory {
    Button createButton();
    Checkbox createCheckbox();
}

4. Concrete Factories

public class AndroidUiFactory implements UIFactory {
    @Override
    public Button createButton() {
        return new AndroidButton();
    }
    @Override
    public Checkbox createCheckbox() {
        return new AndroidCheckbox();
    }
}

public class IOSUiFactory implements UIFactory {
    @Override
    public Button createButton() {
        return new IOSButton();
    }
    @Override
    public Checkbox createCheckbox() {
        return new IOSCheckbox();
    }
}

5. Client Code

public class Application {
    private Button button;
    private Checkbox checkbox;

    public Application(UIFactory factory) {
        this.button = factory.createButton();
        this.checkbox = factory.createCheckbox();
    }

    public void render() {
        button.click();
        checkbox.check();
    }

    public static void main(String[] args) {
        UIFactory factory;
        String osName = "iOS"; // This could be determined at runtime, like Platform.getName();

        if (osName.toLowerCase().contains("iOS", true)) {
            factory = new IOSUiFactory();
        } else {
            factory = new AndroidUiFactory();
        }

        Application app = new Application(factory);
        app.render();
    }
}

Kotlin Implementation

Instead of creating new factory instances, we can use use object for singleton-like factories.

// Product Interfaces
// We use a sealed interface to restrict the possible implementations of Button and Checkbox
// This allows for exhaustive 'when' expressions in consuming code.
sealed interface Button {
    fun click()
}

sealed interface Checkbox {
    fun check()
}

// Concrete Products
class AndroidButton : Button {
    override fun click() {
        println("Android Button Clicked")
    }
}

class AndroidCheckbox : Checkbox {
    override fun check() {
        println("Android Checkbox Checked")
    }
}

class IOSButton : Button {
    override fun click() {
        println("iOS Button Clicked")
    }
}

class IOSCheckbox : Checkbox {
    override fun check() {
        println("iOS Checkbox Checked")
    }
}

// Abstract Factory Interface
sealed interface UIFactory {
    fun createButton(): Button
    fun createCheckbox(): Checkbox
}

// Concrete Factories
// We use 'object' declarations for stateless, singleton factories.
// This is more concise and thread-safe than a class with a companion object.
object AndroidUiFactory : UIFactory {
    override fun createButton(): Button = AndroidButton()
    override fun createCheckbox(): Checkbox = AndroidCheckbox()
}

object IOSUiFactory : UIFactory {
    override fun createButton(): Button = IOSButton()
    override fun createCheckbox(): Checkbox = IOSCheckbox()
}

// Client Code
// Remains similar to the Java version.
class Application(private val factory: UIFactory) {
    private val button: Button = factory.createButton()
    private val checkbox: Checkbox = factory.createCheckbox()

    fun render() {
        button.click()
        checkbox.check()
    }
}

fun main() {
    val osName = "iOS" // This would be determined dynamically in a real app

    val factory: UIFactory = when (osName.lowercase()) {
        "ios" -> IOSUiFactory
        else -> AndroidUiFactory
    }

    val app = Application(factory)
    app.render()
}

Abstract Factory vs Factory Method

Common Implementations

• Lazy Initialization: ensures instance is created only when it is first requested.
• Eager Initialization: instance is created when the class is loaded.
• Thread-Safe Implementations: ensures the singleton works correctly in multi-threaded environments, such as using synchronized methods or double-checked locking. (though double-checked locking has nuances and is sometimes considered an anti-pattern in modern Java)

Use Cases

• Logging
• Configuration settings
• Thread pools
• Caches
• Device drivers

Examples

Eager initialization

public class Singleton {
    private static final Singleton instance = new Singleton();

    private EagerInitializedSingleton(){}

    public static Singleton getInstance() {
        return instance;
    }
}

• Useful if your singleton class is not using a lot of resources.

Using synchronized method (Lazy initialization)

public class Singleton {

    // Volatile ensures visibility and prevents reordering
    private static volatile Singleton instance;

    private Singleton() {
    }

    // Thread-safe with method-level synchronization
    public static synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }

    public void example() {
        System.out.println("Hello from Singleton!, (using synchronized method)");
    }
}

• Lazily initialization the instance.
• synchronized ensures that only one thread can enter the method at a time.
• It ensures lazy initialization — Singleton instance is created only when needed.
• Performance overhead: Every call to getInstance() acquires a lock, even after the instance has been initialized. This is unnecessary and can be expensive under heavy load.

Double-Checked Locking (Lazy initialization)

public class Singleton {

    private static volatile Singleton instance;

    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) { // <- Double-check
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }

    public void example() {
        System.out.println("Hello from Singleton!, (double-check)");
    }

}

• Lazily initialization the instance.
• double check aims to minimize the overhead of synchronization.
• Complex

Bill Pugh (Inner Class) - Recommended Approach

public class Singleton {
    private Singleton() {
        // Prevent reflection attack
        if (SingletonHelper.INSTANCE != null) {
            throw new RuntimeException("Use getInstance() method to get the single instance of this class");
        }
    }

    private static class SingletonHelper {
        private static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getInstance() {
        return SingletonHelper.INSTANCE;
    }

    public void example() {
        System.out.println("Hello from Singleton!, (Bill Pugh)");
    }
}

• Static inner helper class is loaded only when getInstance() is called.
• Class loading is thread-safe.
• No need for synchronized, and lazy initialization is achieved.

Drawbacks

Despite its utility, the Singleton pattern is sometimes criticized as an anti-pattern because it can:

• Creates global state: Leading to tight coupling and potential side effects.
• Makes Testability difficult: Making unit testing challenging due to hidden dependencies.
• Violate the Single Responsibility Principle: When the singleton takes on responsibilities beyond managing its own instance.

Spring Boot 4.0 is a major release of the Spring Boot framework, introducing significant enhancements for developers.

Key features and improvements in Spring Boot 4 includes:

Core Enhancements

Spring Boot 4.0 is built upon Spring Framework 7.0 which is major upcoming release of Spring Framework (projected for General Availability in November 2025).

1. Java 17+ Baseline

   • Spring Boot 4 will require Java 17 or higher while at the same time recommending JDK 25 as the latest LTS release.
   • This baseline enables Spring Boot 4 to leverage the modern features of Java like pattern matching, sealed classes/interfaces, records, virtual threads and includes JVM level performance improvements.

2. Jakarta EE 11+

   Spring Boot 4 supports Jakarta EE 11 and later, which means you have to move away from older javax.* and use jakarta.* instead.

3. Enhanced Native Compilation with AOT

   Spring Boot 4 further refines native image generation using GraalVM and Ahead-of-Time (AOT) processing.

4. Kotlin 2.2+ Support

   Spring Boot 4 introduces support for Kotlin 2.2+, enabling developers to leverage the latest features and improvements in the Kotlin language.

5. Micrometer 2.0+ Support

   Spring Boot 4 is bundled with Micrometer 2.0+, offering better metrics, and improved observability support.

6. Spring Security 7 Integration

   Includes enhanced security with OAuth 2.1 and OpenID Connect protection.

7. Improved Configuration Properties

   Includes smarter record-based configuration with native hints for GraalVM and built-in validation.

   @ConfigurationProperties("app.database")
   public record DatabaseProperties(String url, String username, String password, int poolSize) {}
   

8. Null-Safety Improvements

   The framework adopts JSpecify annotations to declare the null-safety of its API.

Other notable improvements

API Version Control

The new update introduces streamlined support for API Versioning through annotations. This simplifies API evolution and maintenance.

Example:

@RestController()
@RequestMapping("/greet")
class DemoController {
    @GetMapping("", version = "1")
    fun greetV1(): Map<String, String> = mapOf("message" to "Hello! from greetV1()")

    @GetMapping("", version = "2")
    fun greetV2(): Map<String, String> = mapOf("message" to "Hello! from greetV2()")
}

To make above code work, you need to provide the ApiVersionStrategy. If you run above code without providing ApiVersionStrategy, app will throw:

Caused by: java.lang.IllegalStateException: API version specified, but no ApiVersionStrategy configured

Providing ApiVersionStrategy:

@Configuration
class WebConfiguration : WebMvcConfigurer {
	override fun configureApiVersioning(configurer: ApiVersionConfigurer) {
		configurer.useRequestHeader("X-API-Version")
	}
}

When calling api you have to provide the request header X-API-Version

curl -H "X-API-Version: 2"  http://0.0.0.0:8080/greet

# Response: {"message":"Hello! from greetV2()"}

Programmatic Bean Registration (BeanRegistrar)

Spring Framework 7.0 introduces a new mechanism to register the bean programmatically using BeanRegistrar interface. This provides a more flexible approach to register a bean.

There are various benefits of providing the bean programmatically, for example, registering a bean based on some runtime conditions like active profiles.

Example:

class Foo()
data class Bar(val value: String)

// you can also use BeanRegistrarDsl in Kotlin
class FooBarBeanRegistrar : BeanRegistrar {
    override fun register(
        registry: BeanRegistry,
        env: Environment
    ) {
        registry.registerBean("foo", Foo::class.java)

        // Register a bean with a custom supplier, potentially conditionally
        if (env.matchesProfiles("dev")) {
            registry.registerBean(Bar::class.java) { spec ->
                spec.supplier { Bar("Bar_001") }
                    .prototype()
                    .lazyInit()
                    .description("Bar 001 description")
            }
        }
    }
}

Importing FooBarBeanRegistrar

@Configuration
@Import(FooBarBeanRegistrar::class)
class AppConfig(
    private val foo: Foo,
    private val bar: Bar,
) {
    private val logger: Logger = LoggerFactory.getLogger(AppConfig::class.java)

    @Bean
    fun provideCommandLine(): CommandLineRunner = CommandLineRunner { args ->
        logger.info("foo = $foo")
        logger.info("bar = $bar")
    }
}

Declarative HTTP interface

Spring Boot 4 introduces enhanced support for declarative HTTP clients, building upon the existing RestClient and WebClient options.

It allows defining HTTP client interfaces using annotations, similar to Feign client. Spring generates the implementation at runtime, reducing boilerplate code for making HTTP requests.

Example:

@HttpExchange("https://jsonplaceholder.typicode.com")
interface TodoClient {
    @GetExchange("/todos")
    fun getTodos(): List<Todo>

    @GetExchange("/todos/{id}")
    fun getTodoById(@PathVariable id: Long): Todo?

    @PostExchange("/todos")
    fun createTodo(@RequestBody todo: Map<String, String>)
}

@Configuration
@ImportHttpServices(TodoClient::class)
class ClientsConfiguration

Conclusion

Spring Boot 4 aims to be a transformative release, introducing numerous enhancements to the Spring Framework that significantly simplify application development.

This feature is a powerful tool for domain modeling, enhancing security, and working with pattern matching in switch expressions.

What are Sealed Classes?

A sealed class restricts which other classes can inherit from it. This provides better control over the class hierarchy, making your code more robust and maintainable.

Syntax:

public sealed class Vehicle permits Car, Truck {
    // class body
}

In this example, Vehicle is a sealed class, and only Car and Truck are permitted to extend it.

Rules for Subclasses

Any class that extends a sealed class must:

1. Be listed in the permits clause of the sealed class.
2. Be in the same module or package as the sealed class.
3. Explicitly declare itself as either:
   • final: Cannot be extended further.
   • sealed: Can be extended, but only by the classes it permits.
   • non-sealed: Removes the sealing restriction, allowing any class to extend it.

Example Hierarchy:

// Car is final and cannot be extended
public final class Car extends Vehicle {
    // ...
}

// Truck is non-sealed, so any class can extend it
public non-sealed class Truck extends Vehicle {
    // ...
}

What are Sealed Interfaces?

Similarly, a sealed interface restricts which classes or interfaces can implement or extend it.

Syntax:

public sealed interface Shape permits Circle, Rectangle, Square {
    // interface body
}

Here, only Circle, Rectangle, and Square are allowed to implement the Shape interface.

Rules for Implementers

The same rules for subclasses of sealed classes apply to classes that implement a sealed interface. They must be final, sealed, or non-sealed.

Example Hierarchy:

public final class Circle implements Shape { /* ... */ }
public final class Rectangle implements Shape { /* ... */ }

// A record is implicitly final
public record Square(int side) implements Shape { /* ... */ }

Sealed Types and Pattern Matching

One of the biggest benefits of sealed types is how they enhance pattern matching in switch expressions. When you switch over a sealed type, the compiler knows all the permitted subtypes. This allows it to perform an exhaustive check, ensuring that you have handled all possible cases.

If you cover all the permitted subtypes, you don’t need a default clause, which makes your code safer and more readable.

Example with an Enhanced switch

sealed interface Vehicle permits Car, Truck, Bike {}

final class Car implements Vehicle {
    public int getNumberOfSeats() { return 4; }
}

final class Truck implements Vehicle {
    public int getLoadCapacity() { return 5000; }
}

record Bike(String type) implements Vehicle {}

public class VehicleProcessor {
    public static String processVehicle(Vehicle vehicle) {
        // The switch is exhaustive because Vehicle is sealed.
        // No default case is needed.
        return switch (vehicle) {
            case Car c -> "Processing a car with " + c.getNumberOfSeats() + " seats.";
            case Truck t -> "Processing a truck with a load capacity of " + t.getLoadCapacity() + " kg.";
            case Bike b -> "Processing a " + b.type() + " bike.";
        };
    }

    public static void main(String[] args) {
        System.out.println(processVehicle(new Car()));
        System.out.println(processVehicle(new Truck()));
        System.out.println(processVehicle(new Bike("Mountain")));
    }
}

If a new subtype were added to the Vehicle interface’s permits list, the compiler would flag the switch expression as an error until it is updated to handle the new type.

Key Benefits of Sealed Types

• Controlled Inheritance: Prevents unintended extensions, making your class hierarchy predictable.
• Enhanced Security: Restricts who can implement sensitive APIs.
• Improved Readability: Clearly defines the intended inheritance structure.
• Exhaustive Compiler Checks: Enables exhaustive checks in switch expressions, eliminating the need for a default case and reducing bugs.
• Precise Domain Modeling: Helps create more accurate and explicit domain models.
• Better Maintainability: Makes code easier to understand, refactor, and evolve.

To ensure an interface is a functional interface, you can use the @FunctionalInterface annotation. The compiler will then trigger an error if the interface does not meet the requirements.

Here’s a simple example:

@FunctionalInterface
interface MyFunctionalInterface {
    void execute(String message); // The single abstract method
}

public class FunctionalInterfaceExample {
    public static void main(String[] args) {
        // Using a lambda expression to implement the interface
        MyFunctionalInterface myLambda = (msg) -> System.out.println("Executing: " + msg);
        myLambda.execute("Hello, Functional World!");
    }
}

Core Functional Interfaces in java.util.function

Java 8 introduced a set of standard functional interfaces in the java.util.function package. These are widely used and cover most common use cases. Let’s explore the four main ones.

1. Consumer<T>

A Consumer “consumes” an input value and performs an operation on it without returning any result.

• Abstract Method: void accept(T t)
• Use Case: Ideal for operations with side effects, such as printing to the console, logging, or modifying an object.

Example:

import java.util.function.Consumer;
import java.util.Arrays;
import java.util.List;

public class ConsumerExample {
    public static void main(String[] args) {
        Consumer<String> printer = s -> System.out.println(s);
        List<String> names = Arrays.asList("Alice", "Bob", "Charlie");
        names.forEach(printer); // Prints each name
    }
}

2. Predicate<T>

A Predicate evaluates a condition on an input value and returns a boolean result.

• Abstract Method: boolean test(T t)
• Use Case: Perfect for filtering data, validation, and conditional checks. It’s heavily used in the Stream API’s filter() method.

Example:

import java.util.function.Predicate;
import java.util.stream.Stream;

public class PredicateExample {
    public static void main(String[] args) {
        Predicate<String> isLongerThan5 = s -> s.length() > 5;
        Stream.of("Java", "Python", "JavaScript")
              .filter(isLongerThan5)
              .forEach(System.out::println); // Prints "JavaScript"
    }
}

3. Function<T, R>

A Function takes an input of type T and produces a result of type R. It’s used for transformation and mapping.

• Abstract Method: R apply(T t)
• Use Case: Transforming one object into another, such as converting a String to its length or mapping a DTO to an entity.

Example:

import java.util.function.Function;
import java.util.stream.Stream;

public class FunctionExample {
    public static void main(String[] args) {
        Function<String, Integer> stringLength = s -> s.length();
        Stream.of("Apple", "Banana", "Cherry")
              .map(stringLength)
              .forEach(System.out::println); // Prints 5, 6, 6
    }
}

4. Supplier<T>

A Supplier “supplies” a value of type T without taking any input.

• Abstract Method: T get()
• Use Case: Useful for lazy generation of values, such as creating new objects, generating random numbers, or providing default values.

Example:

import java.util.function.Supplier;
import java.time.LocalDateTime;

public class SupplierExample {
    public static void main(String[] args) {
        Supplier<LocalDateTime> currentTimeSupplier = () -> LocalDateTime.now();
        System.out.println(currentTimeSupplier.get()); // Prints the current date and time
    }
}

By understanding and using these core functional interfaces, you can write more expressive, concise, and powerful Java code.

Core Concepts

A stream pipeline consists of three parts:

1. A source: Where the stream originates from (e.g., a List, Set, or array).
2. Zero or more intermediate operations: These transform the stream into another stream. Examples include filter, map, and sorted.
3. A terminal operation: This produces a result or a side-effect, and triggers the execution of the pipeline. Examples include forEach, collect, and reduce.

One of the key features of streams is laziness. Intermediate operations are not executed until a terminal operation is invoked. This allows the Stream API to optimize the execution of the pipeline.

Creating Streams

There are several ways to create a stream:

From a Collection

You can create a stream from any Collection (e.g., List, Set) using the stream() method.

List<String> names = Arrays.asList("Alice", "Bob", "Charlie");
Stream<String> nameStream = names.stream();

From an Array

You can create a stream from an array using the Arrays.stream() method or Stream.of().

String[] nameArray = {"Alice", "Bob", "Charlie"};
Stream<String> nameStreamFromArray = Arrays.stream(nameArray);

Stream<String> nameStreamFromOf = Stream.of("Alice", "Bob", "Charlie");

From a Range of Numbers

The IntStream, LongStream, and DoubleStream interfaces provide methods for creating streams of primitive numeric types.

IntStream intStream = IntStream.range(1, 5); // 1, 2, 3, 4
LongStream longStream = LongStream.rangeClosed(1, 5); // 1, 2, 3, 4, 5

Using Stream.iterate() and Stream.generate()

You can also create infinite streams using iterate() and generate().

Stream<Integer> evenNumbers = Stream.iterate(0, n -> n + 2);
Stream<Double> randomNumbers = Stream.generate(Math::random);

It’s important to use limit() with infinite streams to prevent an infinite loop.

Stream Operations

Stream operations are divided into two categories: intermediate and terminal.

Intermediate Operations

Intermediate operations return a new stream and are always lazy.

• filter(Predicate<T>): Returns a stream consisting of the elements of this stream that match the given predicate.

  List<String> names = Arrays.asList("Alice", "Bob", "Charlie", "Anna");
  names.stream()
       .filter(name -> name.startsWith("A"))
       .forEach(System.out::println); // Alice, Anna
  

• map(Function<T, R>): Returns a stream consisting of the results of applying the given function to the elements of this stream.

  List<String> names = Arrays.asList("Alice", "Bob", "Charlie");
  names.stream()
       .map(String::length)
       .forEach(System.out::println); // 5, 3, 7
  

• flatMap(Function<T, Stream<R>>): Transforms each element of the stream into a stream of other objects and then flattens all the generated streams into a single stream.

  List<List<Integer>> listOfLists = Arrays.asList(
      Arrays.asList(1, 2),
      Arrays.asList(3, 4),
      Arrays.asList(5, 6)
  );
  listOfLists.stream()
             .flatMap(List::stream)
             .forEach(System.out::print); // 123456
  

• distinct(): Returns a stream consisting of the distinct elements (according to Object.equals(Object)) of this stream.

• sorted(): Returns a stream consisting of the elements of this stream, sorted according to natural order.

• peek(Consumer<T>): Returns a stream consisting of the elements of this stream, additionally performing the provided action on each element as elements are consumed from the resulting stream. This is useful for debugging.

Terminal Operations

Terminal operations trigger the stream processing and produce a result.

• forEach(Consumer<T>): Performs an action for each element of this stream.

• collect(Collector<T, A, R>): Performs a mutable reduction operation on the elements of this stream using a Collector. This is one of the most powerful terminal operations.

  List<String> names = Arrays.asList("Alice", "Bob", "Charlie");
  List<String> upperCaseNames = names.stream()
                                     .map(String::toUpperCase)
                                     .collect(Collectors.toList());
  

• reduce(T identity, BinaryOperator<T> accumulator): Performs a reduction on the elements of this stream, using an initial value and an associative accumulation function.

  List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);
  int sum = numbers.stream().reduce(0, (a, b) -> a + b); // 15
  

• count(): Returns the count of elements in this stream.

• anyMatch(Predicate<T>), allMatch(Predicate<T>), noneMatch(Predicate<T>): These operations check if any, all, or no elements of this stream match the given predicate.

• findFirst(), findAny(): Return an Optional describing the first element of this stream, or an arbitrary element of the stream, respectively.

Collectors

The Collectors class provides a set of static factory methods for creating Collector instances.

• toList(), toSet(), toMap(): Collect elements into a List, Set, or Map.
• joining(CharSequence delimiter): Joins the elements into a String.
• groupingBy(Function<T, K>): Groups elements according to a classification function.
• partitioningBy(Predicate<T>): Partitions elements into a Map<Boolean, List<T>> based on a predicate.

Parallel Streams

You can easily create a parallel stream by calling the parallelStream() method on a collection or by calling the parallel() intermediate method on a stream. This can lead to significant performance improvements for large datasets, as the operations are performed concurrently.

List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
int sum = numbers.parallelStream()
                 .mapToInt(Integer::intValue)
                 .sum();

However, be mindful of the overhead of parallelism. For small datasets or simple operations, a sequential stream might be faster.

Conclusion

The Java Stream API is a fundamental part of modern Java development. It enables you to write more concise, readable, and potentially more performant code for data processing. By understanding the core concepts of stream creation, intermediate operations, and terminal operations, you can leverage the full power of functional-style programming in Java.

AtomicInteger is a class from the java.util.concurrent.atomic package that provides a thread-safe way to perform atomic operations on an integer value. Unlike traditional locking mechanisms (e.g., synchronized blocks), AtomicInteger uses low-level hardware instructions to achieve thread safety with higher performance.

The Problem: Race Conditions with Standard Integers

In a multithreaded environment, incrementing a simple int variable is not an atomic operation. The seemingly simple counter++ operation involves three distinct steps:

1. Read: Read the current value of the counter.
2. Modify: Increment the value.
3. Write: Write the updated value back to the counter.

If two threads execute this operation simultaneously, they might both read the same initial value, increment it, and write back the same result. This leads to “lost updates” and an incorrect final value.

Non-Atomic Example

The following code demonstrates this problem. We start ten threads, and each thread increments a shared counter 10,000 times. We expect the final value to be 100,000, but the actual result is often lower due to race conditions.

import java.util.concurrent.atomic.AtomicInteger;

public class CounterExample {

    private static int counter = 0;
    private static AtomicInteger atomicCounter = new AtomicInteger(0);

    public static void main(String[] args) throws InterruptedException {
        nonAtomicExample();
        atomicExample();
    }

    public static void nonAtomicExample() throws InterruptedException {
        counter = 0;
        Runnable task = () -> {
            for (int i = 0; i < 10_000; i++) {
                counter++;
            }
        };

        Thread[] threads = new Thread[10];
        for (int i = 0; i < 10; i++) {
            threads[i] = new Thread(task);
            threads[i].start();
        }

        for (Thread thread : threads) {
            thread.join();
        }

        System.out.println("Non-Atomic Final Counter: " + counter);
    }

    public static void atomicExample() throws InterruptedException {
        atomicCounter.set(0);
        Runnable task = () -> {
            for (int i = 0; i < 10_000; i++) {
                atomicCounter.incrementAndGet(); // Atomic operation
            }
        };

        Thread[] threads = new Thread[10];
        for (int i = 0; i < 10; i++) {
            threads[i] = new Thread(task);
            threads[i].start();
        }

        for (Thread thread : threads) {
            thread.join();
        }

        System.out.println("Atomic Final Counter: " + atomicCounter.get());
    }
}

The Solution: AtomicInteger

AtomicInteger solves this problem by providing atomic methods for updating the integer value. These methods use a hardware-level mechanism called Compare-and-Swap (CAS).

How Compare-and-Swap (CAS) Works

CAS is an atomic instruction that compares the contents of a memory location with a given value and, only if they are the same, modifies the contents of that memory location to a new given value. This is done as a single atomic operation.

The incrementAndGet() method, for example, uses CAS to ensure that the read-modify-write operation is atomic. It repeatedly tries to update the value until it succeeds, preventing race conditions.

Common AtomicInteger Methods

Here are some of the most commonly used methods in AtomicInteger:

• get(): Returns the current value.
• set(int newValue): Sets the value to newValue.
• incrementAndGet(): Atomically increments the current value by one and returns the new value.
• getAndIncrement(): Atomically increments the current value by one and returns the old value.
• decrementAndGet(): Atomically decrements the current value by one and returns the new value.
• getAndDecrement(): Atomically decrements the current value by one and returns the old value.
• addAndGet(int delta): Atomically adds the given value to the current value and returns the new value.
• getAndSet(int newValue): Atomically sets to the given value and returns the old value.
• compareAndSet(int expect, int update): Atomically sets the value to update if the current value is equal to expect, and returns true if successful.

By using AtomicInteger, you can ensure the correctness of your multithreaded code without the performance overhead of traditional synchronization.

Why Do We Need BlockingQueue?

In multi-threaded applications, it’s common to have a scenario where one or more threads (Producers) are generating data, and one or more other threads (Consumers) are processing that data. This is known as the producer-consumer problem.

A BlockingQueue elegantly solves this by providing a shared, thread-safe channel for communication. Instead of manually implementing complex synchronization logic with wait() and notify(), you can rely on the queue to handle it for you:

• Blocks Producers: If the queue is full, any producer thread trying to add an element will be blocked until there is space available.
• Blocks Consumers: If the queue is empty, any consumer thread trying to retrieve an element will be blocked until an item is available.

This built-in mechanism simplifies code, reduces the risk of concurrency bugs like race conditions, and improves overall application stability.

The Producer-Consumer Pattern with BlockingQueue

The producer-consumer pattern is a classic concurrency design pattern. BlockingQueue makes implementing it straightforward.

Here’s a simple example using LinkedBlockingQueue:

import java.util.concurrent.BlockingQueue;
import java.util.concurrent.LinkedBlockingQueue;

public class BlockingQueueExample {

    public static void main(String[] args) {
        // A queue with a fixed capacity of 5
        BlockingQueue<String> queue = new LinkedBlockingQueue<>(5);

        // Producer thread
        Thread producer = new Thread(() -> {
            try {
                for (int i = 1; i <= 10; i++) {
                    String item = "Item " + i;
                    System.out.println("Producing: " + item);
                    // put() blocks if the queue is full
                    queue.put(item);
                    Thread.sleep(500); // Simulate time taken to produce an item
                }
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });

        // Consumer thread
        Thread consumer = new Thread(() -> {
            try {
                for (int i = 1; i <= 10; i++) {
                    // take() blocks if the queue is empty
                    String item = queue.take();
                    System.out.println("Consuming: " + item);
                    Thread.sleep(1000); // Simulate time taken to consume an item
                }
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });

        producer.start();
        consumer.start();
    }
}

In this example:

• The producer adds items to the queue. If the queue reaches its capacity of 5, the put() call will block until the consumer takes an item.
• The consumer removes items. If the queue is empty, the take() call will block until the producer adds an item.

Common BlockingQueue Implementations

Java provides several implementations of the BlockingQueue interface, each suited for different use cases:

• ArrayBlockingQueue: A bounded queue backed by an array. It’s efficient but has a fixed capacity.
• LinkedBlockingQueue: An optionally bounded queue backed by linked nodes. It offers higher throughput than ArrayBlockingQueue but can consume more memory.
• PriorityBlockingQueue: An unbounded queue where elements are ordered based on their natural ordering or a custom Comparator.
• DelayQueue: An unbounded queue where elements can only be taken when their specified delay has expired.
• SynchronousQueue: A queue with no internal capacity. Each put() operation must wait for a corresponding take() operation, making it ideal for handoff scenarios.

By choosing the right implementation, you can tailor the behavior of your concurrent application to your specific needs.

Why CompletableFuture?

Before CompletableFuture, Java’s Future was limited. You could start an asynchronous task, but you had to block your main thread using get() to retrieve the result. This defeated the purpose of non-blocking code.

CompletableFuture solves this by providing a non-blocking, callback-based approach. It allows you to chain tasks together, so that a subsequent task automatically executes when the previous one completes, without ever blocking your main thread.

Core Features of CompletableFuture

• Asynchronous Execution: Run tasks in the background without blocking the caller thread, typically using a ForkJoinPool or a custom Executor.
• Composability and Chaining: Chain multiple asynchronous operations together using methods like thenApply(), thenAccept(), and thenCompose().
• Powerful Combination: Combine the results of multiple CompletableFutures using thenCombine(), allOf(), or anyOf().
• Robust Exception Handling: Handle exceptions gracefully within the asynchronous pipeline using methods like exceptionally() and handle().
• Explicit Completion: Programmatically complete a future with a result or an exception, giving you more control over its lifecycle.

Key Methods of CompletableFuture

Here’s a look at some of the most commonly used methods:

How Does CompletableFuture Work?

1. Asynchronous Task Execution: When you call supplyAsync() or runAsync(), the task is submitted to a thread pool (by default, the ForkJoinPool.commonPool()). Your main thread is free to continue its work.
2. Callback Chaining: You can attach callbacks using methods like thenApply() or thenAccept(). These callbacks are registered and will be executed only when the preceding task finishes.
3. Result and Exception Handling: The CompletableFuture object holds the state of the computation (e.g., pending, completed with a result, or completed with an exception). When a task finishes, it triggers the execution of any dependent callbacks.
4. Combining Futures: Methods like allOf() and anyOf() allow you to coordinate multiple asynchronous tasks, enabling you to proceed when all or any of them have completed.

Practical Example

Let’s see CompletableFuture in action with a simple example:

import java.util.concurrent.CompletableFuture;
import java.util.concurrent.TimeUnit;

public class CompletableFutureExample {

    public static void main(String[] args) {
        CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> {
            // Simulate a long-running task
            try {
                TimeUnit.SECONDS.sleep(1);
            } catch (InterruptedException e) {
                throw new IllegalStateException(e);
            }
            return "Hello";
        }).thenApply(result -> result + " World!");

        // Attach a callback to consume the final result
        future.thenAccept(result -> {
            System.out.println("Result: " + result);
            System.out.println("This is executed in thread: " + Thread.currentThread().getName());
        });

        System.out.println("This is printed immediately from the main thread.");

        // Wait for the future to complete to see the output
        future.join();
    }
}

In this example:

1. supplyAsync() starts a background task.
2. thenApply() chains another task to transform the result.
3. thenAccept() registers a final callback to print the result.
4. The main thread prints its message immediately and then calls join() to wait for the asynchronous pipeline to finish before exiting.

By leveraging CompletableFuture, you can build sophisticated, non-blocking, and highly efficient applications in Java.

The hashCode() and equals() Contract

The most important concept to understand is the contract between hashCode() and equals():

1. If two objects are equal according to the equals(Object) method, then calling the hashCode() method on each of the two objects must produce the same integer result.
2. It is not required that if two objects are unequal according to the equals(Object) method, then calling the hashCode() method on each of the two objects must produce distinct integer results. However, producing distinct hash codes for unequal objects may improve the performance of hash tables.

In simple terms: equal objects must have equal hash codes.

If you override the equals() method, you must also override the hashCode() method to maintain this contract.

Why is This Contract So Important?

Hash-based collections use an object’s hash code to quickly locate it. Here’s a simplified view of how HashMap.put(key, value) works:

1. It calculates the key’s hash code.
2. It uses this hash code to find a bucket (an index in an internal array).
3. If the bucket is empty, it stores the key-value pair there.
4. If the bucket is not empty (a hash collision), it iterates through the existing entries in that bucket and uses the equals() method to check if the key already exists.

If you break the contract, these collections will behave incorrectly.

Example: Breaking the Contract

Let’s see what happens when we override equals() but not hashCode().

import java.util.HashMap;
import java.util.Map;
import java.util.Objects;

class Product {
    private String id;

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

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Product product = (Product) o;
        return Objects.equals(id, product.id);
    }

    // hashCode() is NOT overridden
}

public class BrokenContractExample {
    public static void main(String[] args) {
        Map<Product, String> map = new HashMap<>();
        map.put(new Product("a"), "Apple");
        map.put(new Product("a"), "Avocado"); // Should replace "Apple"

        // The map size will be 2, which is incorrect!
        System.out.println("Map size: " + map.size());
        System.out.println(map);
    }
}

What went wrong?

• We defined equals() to consider two Product objects with the same id as equal.
• However, since we didn’t override hashCode(), each new Product("a") gets a different hash code from the default Object.hashCode() implementation (which is based on memory address).
• The HashMap calculates two different hash codes, places the objects in two different buckets, and never even calls the equals() method. The result is a map with duplicate logical keys.

How to Correctly Implement hashCode()

To fix this, we must implement hashCode() based on the same fields used in the equals() method. The easiest way is to use the Objects.hash() utility method.

import java.util.HashMap;
import java.util.Map;
import java.util.Objects;

class CorrectProduct {
    private String id;

    public CorrectProduct(String id) {
        this.id = id;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        CorrectProduct that = (CorrectProduct) o;
        return Objects.equals(id, that.id);
    }

    @Override
    public int hashCode() {
        // Use the same field(s) as in equals()
        return Objects.hash(id);
    }
}

public class CorrectContractExample {
    public static void main(String[] args) {
        Map<CorrectProduct, String> map = new HashMap<>();
        map.put(new CorrectProduct("a"), "Apple");
        map.put(new CorrectProduct("a"), "Avocado"); // Correctly replaces "Apple"

        // The map size will be 1, which is correct.
        System.out.println("Map size: " + map.size());
        System.out.println(map);
    }
}

By correctly implementing both equals() and hashCode(), we ensure that hash-based collections work as expected, providing both correctness and performance.

Fail-Fast Iterators

Fail-fast iterators immediately throw a ConcurrentModificationException if the collection is structurally modified (i.e., elements are added or removed) at any time after the iterator is created, except through the iterator’s own remove() method.

How They Work

Fail-fast iterators operate directly on the collection itself. They keep track of the number of modifications made to the collection using an internal flag (like modCount). When you create an iterator, it saves the initial modCount. With each iteration (next() call), it checks if the current modCount has changed. If it has, the iterator knows that the collection has been modified concurrently and throws a ConcurrentModificationException.

This mechanism helps to prevent unexpected behavior and data corruption by alerting you to concurrent modification issues early on.

Common collections that use fail-fast iterators include ArrayList, HashMap, and HashSet.

Code Example

import java.util.ArrayList;
import java.util.Arrays;
import java.util.Iterator;
import java.util.List;
import java.util.ConcurrentModificationException;

public class FailFastExample {
    public static void main(String[] args) {
        List<String> list = new ArrayList<>(Arrays.asList("A", "B", "C"));
        Iterator<String> iterator = list.iterator();

        while (iterator.hasNext()) {
            String element = iterator.next();
            System.out.println("Processing: " + element);
            try {
                // This will throw ConcurrentModificationException
                list.add("D"); 
            } catch (ConcurrentModificationException e) {
                System.err.println("Caught a ConcurrentModificationException!");
                e.printStackTrace();
                break; 
            }
        }
    }
}

In this example, list.add("D") modifies the list while the iterator is active, causing a ConcurrentModificationException to be thrown.

Fail-Safe Iterators

In contrast, fail-safe iterators (also known as non-fast-fail iterators) do not throw a ConcurrentModificationException if the collection is modified while being iterated.

How They Work

Fail-safe iterators work on a clone or a snapshot of the underlying collection. This means that any modifications made to the original collection do not affect the iterator. The iterator continues to traverse the snapshot, which remains unchanged. This approach ensures that the iteration can complete without errors, but it also means that the iterator might not reflect the most up-to-date state of the collection.

Collections that use fail-safe iterators are typically found in the java.util.concurrent package, such as CopyOnWriteArrayList and ConcurrentHashMap.

Code Example

import java.util.Iterator;
import java.util.concurrent.CopyOnWriteArrayList;

public class FailSafeExample {
    public static void main(String[] args) {
        CopyOnWriteArrayList<String> list = new CopyOnWriteArrayList<>(new String[]{"A", "B", "C"});
        Iterator<String> iterator = list.iterator();

        while (iterator.hasNext()) {
            String element = iterator.next();
            System.out.println("Processing: " + element);
            
            // This modification will not be reflected in the iterator
            if (element.equals("B")) {
                list.add("D");
            }
        }
        
        System.out.println("Final list: " + list);
    }
}

In this case, even though we add “D” to the list, the iterator doesn’t throw an exception. The output will show that the iterator processed the original elements (“A”, “B”, “C”), and the final list contains “D”.

Key Differences: Fail-Fast vs. Fail-Safe

Conclusion

Choosing between fail-fast and fail-safe iterators depends on your specific needs.

• Use fail-fast iterators when you need to be immediately aware of concurrent modifications, which is typical in single-threaded environments or when you can control modifications.
• Opt for fail-safe iterators in multi-threaded environments where you need to ensure that iterations can proceed without interruption, even if the collection is being modified by other threads.

By understanding these differences, you can write more reliable and predictable Java applications.