DEV Community: Prabhat Kumar

🔴 Your architecture rules are dying in Confluence. Here's how to make them bite back.

Prabhat Kumar — Tue, 03 Mar 2026 05:36:02 +0000

Every team has that architecture doc. You know the one — 47 pages, last updated 8 months ago, ignored by everyone shipping features.

The problem isn't discipline. It's that rules written in prose don't fail builds.

Here's a workflow I've been using to convert architecture documentation into executable, failing JUnit tests — in under 10 minutes.

The 3-Step Process

Step 1 — Copy your arch rules from Confluence/Wiki

Just grab the raw text. Doesn't need to be formatted perfectly.
Example rules I copied:

Classes extending a parent must use the parent name as suffix
e.g., CacheDataProvider extends DataProvider ✅
No string literals inside methods — use static final class members
e.g., static final String DATE_FORMAT = "yyyy-MM-dd HH:mm:ss" ✅
Controllers must live under .controller. package only
Domain objects must NOT be instantiated with "new" inside methods
e.g., new CacheHelper() inside a method ❌

Step 2 — Feed them to Claude Code with this prompt

Open Claude Code and paste this:

You are an expert Java architect specializing in ArchUnit — a Java library for checking architecture rules as unit tests.

You will receive architecture rules in plain english format and must convert it into a complete, compilable ArchUnit JUnit5 test class.

Rules:
<architecture_rules>
  A. Class must have parent class name as suffix while extending. 
    Ex: class CacheDataProvider when extends DataProvider
  B. No string literals inside a method, always have static final class member. 
    Ex: String DATE_FORMAT = "yyyy-MM-dd HH:mm:ss";
  C. Package Naming Conventions like edu.pk.demo.archunit.controller.* 
  D. Method should not create domain object locally using "new" keyword. 
    Ex: final CacheHelper cacheHelper = new CacheHelper();
</architecture_rules>

Requirements:
- Use @AnalyzeClasses(packages = "edu.pk.demo.archunit")              # Use your project package name
- One @ArchTest per rule, named descriptively
- Use ArchUnit's fluent API (classes(), noClasses(), methods())
- Add a brief comment above each test explaining the rule intent
- Base package: edu.pk.demo.archunit  

ArchUnit API Reference
  - Class-level setup:
  @AnalyzeClasses(packages = "com.example", importOptions = ImportOption.DoNotIncludeTests.class)
  public class MyArchTest { ... }

  - Rule declaration (always static final):
  @ArchTest
  static final ArchRule ruleName = ...;

  - Fluent API for common patterns:
  # CONTAINMENT (CONTAINED WITHIN / CONTAINS):
  classes()
    .that().resideInAPackage("com.example..")
    .should().resideInAnyPackage("com.example.domain..", "com.example.service..")
    .as("...").because("...");

  # NO DEPENDENCY ON:
  noClasses()
    .that().resideInAPackage("com.example.web..")
    .should().dependOnClassesThat().resideInAPackage("com.example.db..")
    .as("...").because("...");

  # CYCLE FREE:
  slices()
    .matching("com.example.(*)..")
    .should().beFreeOfCycles();

  # MUST USE LIBRARY (CONTAINS library):
  classes()
    .that().resideInAPackage("com.example.api..")
    .should().dependOnClassesThat().resideInAPackage("com.security..")
    .as("...").because("...");

Output Rules:
- Output ONLY valid Java source code
- No markdown code fences
- No explanation text before or after the class
- Full import statements required
- Class must be immediately runnable with ArchUnit + JUnit5 on the classpath

Step 3 — Drop the generated tests into your project and run

Claude generates something like this:

@AnalyzeClasses(packages = "edu.pk.demo.archunit")
public class ArchitectureRulesTest {

// Rule: Subclass name must end with the parent class simple name
@ArchTest
static final ArchRule subclassesShouldUseSuperclassNameAsSuffix =
      classes()
          .that().areAssignableTo(DataProvider.class)
          .should().haveSimpleNameEndingWith("DataProvider")
          .because("Subclasses must use the parent class name as suffix for discoverability");
...
}

Why this matters

Architecture drift happens because rules live in documents, not in pipelines.

When you encode rules as tests:
✅ Every PR is verified automatically
✅ New developers can't accidentally break conventions
✅ Architecture decisions are self-documenting in code
✅ No more "we agreed not to do this" code review comments

The best part? Claude Code handles the ArchUnit API fluency. You just describe what you want to enforce — it figures out how to write it.

Your architecture doc shouldn't be a suggestion. Make it a compiler error.

Have you automated architecture enforcement in your team? What rules do you wish you'd enforced from day one? Drop them below 👇.

Wiring Claude Into Real Systems With Tool Use

Prabhat Kumar — Fri, 27 Feb 2026 05:46:09 +0000

Claude isn't just a chat interface. With Tool Use (function calling), you can wire it up to real systems — databases, APIs, queues — and build agents that actually do things autonomously. This article walks you through the mental model and real production-grade examples using Python.

Who This Is For

You're a backend engineer. You know REST APIs, you've seen microservices, you understand distributed systems at some level. You've probably played with ChatGPT or the Anthropic API and thought "okay, it answers questions — but how do I actually build something useful with this?"

This article is exactly for that moment.

No PhD in ML required. Just solid engineering instinct.

The Problem With Chatbots

Most engineers first encounter with LLM APIs that looks like below:

import anthropic

client = anthropic.Anthropic(api_key="your-key")

response = client.messages.create(
    model="claude-opus-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "What is the refund status of order #12345?"}]
)

print(response.content[0].text)
# → "I don't have access to your order system, so I can't check that."

And that's the wall. Claude is smart, but it's stateless and isolated. It knows nothing about your business, your database, your users.

The typical workaround? Stuff everything into the prompt:

# ❌ Bad pattern — brittle, expensive, leaks data
prompt = f"""
Here is the full customer database export:
{entire_database_dump}

Now answer: What is the refund status of order #12345?
"""

This doesn't scale. It's expensive, slow, and a security nightmare.

Tool Use is the real answer.

What Is Tool Use, Really?

Think of it like this: you're the orchestrator. Claude is your smart analyst. Instead of dumping all data at Claude upfront, you give Claude a menu of tools it can call — and Claude decides which tools to invoke, in what order, to answer the question.

The flow looks like this:

User Request
     │
     ▼
┌─────────────┐     "I need order info"    ┌──────────────────┐
│   Claude    │ ─────────────────────────► │  get_order_info  │
│   (Brain)   │ ◄───────────────────────── │  (Your API/DB)   │
└─────────────┘     returns order data     └──────────────────┘
     │
     │ "I need refund status too"
     ▼
┌─────────────┐                            ┌──────────────────┐
│   Claude    │ ─────────────────────────► │ get_refund_status│
│   (Brain)   │ ◄───────────────────────── │  (Your API/DB)   │
└─────────────┘     returns refund data    └──────────────────┘
     │
     ▼
  Final Response to User

Claude doesn't call your functions directly. It tells you which function to call and with what args. You execute it. You hand the result back. This is intentional — you stay in control.

Real Use Case #1: Customer Support Agent

Let's build a support agent for an e-commerce platform. It should handle questions about orders, refunds, and shipping — without any human in the loop.

Step 1 — Define Your Tools

tools = [
    {
        "name": "get_order_details",
        "description": "Fetches order details including items, total, and current status for a given order ID.",
        "input_schema": {
            "type": "object",
            "properties": {
                "order_id": {
                    "type": "string",
                    "description": "The order ID, e.g. ORD-98765"
                }
            },
            "required": ["order_id"]
        }
    },
    {
        "name": "get_refund_status",
        "description": "Returns the refund status and expected timeline for a given order.",
        "input_schema": {
            "type": "object",
            "properties": {
                "order_id": {
                    "type": "string",
                    "description": "The order ID to check refund status for"
                }
            },
            "required": ["order_id"]
        }
    },
    {
        "name": "initiate_refund",
        "description": "Initiates a refund for an order if it is eligible. Only call this if the customer explicitly requests a refund.",
        "input_schema": {
            "type": "object",
            "properties": {
                "order_id": {
                    "type": "string",
                    "description": "The order ID to refund"
                },
                "reason": {
                    "type": "string",
                    "description": "Reason for the refund"
                }
            },
            "required": ["order_id", "reason"]
        }
    }
]

Notice the descriptions are crisp and behavioral — they tell Claude when to use the tool, not just what it does. This is critical. Claude uses these descriptions to make decisions.

Step 2 — Wire Up Your Actual Implementations

import anthropic
import json
from typing import Any

client = anthropic.Anthropic(api_key="your-key")

# --- Tool implementations — thin wrappers that delegate to service clients ---

def get_order_details(order_id: str) -> dict:
    return OrderClient.get_order_by_id(order_id)


def get_refund_status(order_id: str) -> dict:
    return RefundClient.get_refund_by_order_id(order_id)


def initiate_refund(order_id: str, reason: str) -> dict:
    return RefundClient.create_refund(order_id, reason)


# --- Tool Executor (dispatcher) ---

def execute_tool(tool_name: str, tool_input: dict) -> Any:
    """Central dispatcher. Claude tells us what to call — we call it."""
    if tool_name == "get_order_details":
        return get_order_details(tool_input["order_id"])
    elif tool_name == "get_refund_status":
        return get_refund_status(tool_input["order_id"])
    elif tool_name == "initiate_refund":
        return initiate_refund(tool_input["order_id"], tool_input["reason"])
    else:
        return {"error": f"Unknown tool: {tool_name}"}

Step 3 — The Agentic Loop

This is the core pattern. It's just a loop — keep calling Claude until it stops asking for tools:

def run_support_agent(user_message: str) -> str:
    """
    The agentic loop:
    1. Send message to Claude with available tools
    2. If Claude wants to call a tool → execute it → send result back
    3. Repeat until stop_reason is anything other than "tool_use"
       (end_turn = final answer, max_tokens = truncation, etc.)
    """
    messages = [{"role": "user", "content": user_message}]

    system_prompt = """You are a helpful customer support agent for an e-commerce platform.
    Use the available tools to fetch real data before answering.
    Be concise, empathetic, and always confirm before initiating any refund.
    Never make up order details — always use tools to fetch accurate information."""

    print(f"\n🧑 User: {user_message}")
    print("-" * 60)

    while True:
        response = client.messages.create(
            model="claude-opus-4-6",
            max_tokens=1024,
            system=system_prompt,
            tools=tools,
            messages=messages
        )

        # Any stop reason other than "tool_use" means Claude is done reasoning.
        # This cleanly handles end_turn, max_tokens, stop_sequence, etc.
        if response.stop_reason != "tool_use":
            final_text = next(
                block.text for block in response.content if hasattr(block, "text")
            )
            print(f"\n🤖 Agent: {final_text}")
            return final_text

        # Claude wants to call tools — execute them and feed results back
        messages.append({"role": "assistant", "content": response.content})

        tool_results = []
        for block in response.content:
            if block.type == "tool_use":
                print(f"🔧 Calling tool: {block.name}({block.input})")
                result = execute_tool(block.name, block.input)
                print(f"   ↳ Result: {result}")

                tool_results.append({
                    "type": "tool_result",
                    "tool_use_id": block.id,
                    "content": json.dumps(result)
                })

        messages.append({"role": "user", "content": tool_results})

Step 4 — Run It

if __name__ == "__main__":
    # Test 1: Order status query
    run_support_agent("Hi, what's the status of my order ORD-12345?")

    # Test 2: Refund request
    run_support_agent("I want a refund for order ORD-12345. The shoes don't fit.")

    # Test 3: Multi-tool chain — Claude calls two tools in one go
    run_support_agent("Can you check order ORD-12345 and also tell me if my refund is on the way?")

Sample Output: Test 3

🧑 User: Can you check order ORD-12345 and also tell me if my refund is on the way?
------------------------------------------------------------
🔧 Calling tool: get_order_details({'order_id': 'ORD-12345'})
   ↳ Result: {'order_id': 'ORD-12345', 'status': 'DELIVERED', ...}
🔧 Calling tool: get_refund_status({'order_id': 'ORD-12345'})
   ↳ Result: {'refund_status': 'PENDING', 'amount': 142.99, ...}

🤖 Agent: Your order ORD-12345 for Nike Air Max and Running Socks was delivered on January 10th.
Regarding your refund — it's currently pending for $142.99, initiated on January 12th,
and you can expect it by January 17th. Let me know if you need anything else!

Claude autonomously decided to call two tools in the same turn because the question warranted it. You wrote zero routing logic for that.

Key Design Principles

Before you go build everything as an agent, here's what to internalize:

1. Tool Descriptions Are Your Decision Logic

The description field is not documentation — it's behavioral guidance. Claude reads it to decide when to invoke the tool. Be precise.

# ❌ Vague — Claude doesn't know when to use this
"description": "Gets order info"

# ✅ Behavioral and specific — tells Claude WHEN to use it
"description": "Fetches live order details including status, items, and delivery date.
                Use this whenever the user asks about a specific order or its current state.
                Requires a valid order ID."

2. You Own the Execution Boundary

Claude never calls your functions directly. It emits a structured tool_use block with the function name and typed arguments. You execute it. This is the trust boundary.

3. The Loop Termination Contract

Your while loop must handle these stop_reason values:

`stop_reason`	Meaning	Your Action
`end_turn`	Claude has a final answer	Extract text, return to user
`tool_use`	Claude wants to call tool(s)	Execute tools, append results
`max_tokens`	Response was cut off	Handle gracefully, retry or fail

4. Message History Is Your Agent's Working Memory

Every tool call and result gets appended to the messages list. Claude uses this full conversation context to reason across multiple steps.

5. Parallel vs Sequential Tool Calls

Claude can call multiple tools in a single turn when they're independent (like fetching order details and refund status simultaneously). This reduces round trips significantly. Design your tools to be stateless and parallelizable where possible — it makes the agent faster.

When NOT to Use Agents

Agents aren't always the answer. Know when to reach for them:

Scenario	Use Agent?	Why
Single lookup + format response	❌ No	Overkill — simple prompt + one tool call is enough
Dynamic multi-step investigation	✅ Yes	Core strength
Sub-100ms latency requirement	❌ No	Agents add multiple LLM round trips
Fully deterministic workflow	❌ No	Use a state machine — don't introduce LLM variance
Complex reasoning with unknown steps	✅ Yes	Agents shine here

The Mental Model, Summarized

Traditional App:  User → Hardcoded Logic → DB → Response
                  (every decision path handwritten by you)

Agentic App:      User → Claude (reasons about what to do)
                              ↕  tools
                         Your Systems (DB, APIs, queues)
                              ↕  results
                         Claude (synthesizes final answer)
                              ↓
                         Response

The shift is: you define capabilities (tools), Claude defines the execution path.

This is powerful because you don't need to anticipate every question or decision tree in advance. Claude reasons through it dynamically — and as you add more tools, the agent naturally becomes more capable without a single line of routing logic change.

Key Takeaways

Tool Use turns Claude from a stateless chat box into an autonomous worker connected to your real systems
The agentic loop is simple: send → get tool request → execute → send result → repeat
You control execution — Claude plans, never acts directly. Use this boundary for security and observability
Tool descriptions are decision logic, not documentation — write them with behavioral precision
Design tools to be stateless and parallelizable — Claude will exploit parallelism automatically

Follow me for more practical engineering content.

Tags: #claude #anthropic #ai #backend #python #agentic #llm #softwaredevelopment #devto

Java equals() Best Practice: instanceof vs getClass()

Prabhat Kumar — Mon, 12 May 2025 13:30:39 +0000

This learning is something I personally encountered in a SonarQube rule violation fix PR raised by Steven. It led me to revisit how we have historically written (often IDE-generated) the equals() method in Java—and why things are shifting now.

🛠️ The Old Way: `instanceof`

For years, IntelliJ and other dev tools used the instanceof check inside equals():

if (!(obj instanceof MyClass)) {
    return false;
}

This seemed fine—but there’s a hidden trap. It allows equality between subclass and superclass, which can violate the symmetry contract of equals():

a.equals(b) should return the same result as b.equals(a).

However, subclasses may have additional fields that the superclass doesn't compare—leading to inconsistent or buggy behavior in collections like HashSet, HashMap, or even in sorting and caching.

🚀 The Modern Approach: getClass()

IntelliJ and SonarQube now recommend:

if (obj == null || getClass() != obj.getClass()) {
    return false;
}

This enforces strict class equality—avoiding the risk of broken symmetry and ensuring predictable behavior across use cases.

🧠 Why Does This Matter?

The equals() contract (reflexive, symmetric, transitive) has existed since Java 1.0.

But tools started enforcing this best practice in recent years due to:

Bugs discovered in real-world code.
New Java features like records and sealed classes.

✅ Key Takeaway

If your class is not designed for subclass comparison, prefer using getClass() in equals()—it’s safer and more predictable.

Unveiling the Inner Workings of Spring AOP

Prabhat Kumar — Fri, 06 Sep 2024 16:05:44 +0000

In this post, we will demystify the internal mechanics of Aspect-Oriented Programming (AOP) in Spring. The focus will be on understanding how AOP achieves functionality like logging, often considered a form of “magic.” By walking through a core Java implementation, we’ll see how it’s all about Java’s reflection, proxy patterns, and annotations rather than anything truly magical.

Prerequisites

Java Core Proxy API
Reflection API
Annotation API

These are all part of java.lang.reflect,java.lang.annotation, and javassist.util.proxy packages.

The Core Mechanism

At the heart of Spring AOP lies the concept of proxy objects, method interceptors, and reflection. The key player in this pattern is the MethodHandler (or invocation handler). This handler controls the proxy object’s behavior by intercepting method calls. When a method is invoked on the proxy, it gets passed through the handler, where annotations can be introspected via reflection. Based on the annotations applied, the necessary logic (e.g., logging) can be executed before, after, or on exception.

Breaking it Down

Proxy Objects: These are dynamically created objects that stand in for your actual business objects, routing method calls through the method handler.
Invocation Handlers: This is where the magic of interception happens. Using reflection, the handler can examine annotations present on the target method and alter the behavior accordingly.
Custom Annotations: You can define custom annotations, which serve as markers to trigger additional functionality like logging, security checks, or transaction management.

Example: Suppose we want to add logging before and after certain method executions. Instead of hard-coding logging everywhere, we can annotate methods with @BeforeMethod and @AfterMethod. Our handler inspects the method for this annotation and adds the appropriate logging logic dynamically.

Below are the classes how the Controller and Service look like for our example.

WorkerController.java

package edu.pk.poc.aop.controller;

import edu.pk.poc.aop.annotation.AfterMethod;
import edu.pk.poc.aop.annotation.All;
import edu.pk.poc.aop.annotation.BeforeMethod;
import edu.pk.poc.aop.helper.ProxyFactory;
import edu.pk.poc.aop.service.Worker;
import edu.pk.poc.aop.service.WorkerService;
import edu.pk.poc.aop.service.WorkerServiceImpl;

public class WorkerController {
    WorkerService workerService = ProxyFactory.createProxy(WorkerServiceImpl.class);
    /**
     * This Method 1s annotated with @BeforeMethod and @AfterMethod, So the log statements
     * will be generated before and after method call.
     */
    @BeforeMethod
    @AfterMethod
    public void engageFullTimeWorker() throws Exception {
        Worker fullTimeWorker = new Worker();
        fullTimeWorker.setName("FullTime-Worker");
        fullTimeWorker.setPartTime(false);
        fullTimeWorker.setDuration(9);
        workerService.doWork(fullTimeWorker);
    }
    /**
     * This Method is annotated with @All, So the log statements will be generated before and after method call
     * along with exception if raised.
     */
    @All
    public void engagePartTimeWorker() throws Exception {
        Worker partTimeWorker = new Worker();
        partTimeWorker.setName("PartTime-Worker");
        partTimeWorker.setPartTime(true);
        partTimeWorker.setDuration(4);
        workerService.doWork(partTimeWorker);
    }
}

WorkerServiceImpl.java

package edu.pk.poc.aop.service;

import edu.pk.poc.aop.annotation.AfterMethod;

public class WorkerServiceImpl implements WorkerService {
    /**
     * Here this method is annotated with only @AfterMethod, So only log statement
     * will be generated after method call
     */
    @AfterMethod
    @Override
    public void doWork(Worker worker) throws Exception {
        if (worker.isPartTime()) {
            throw new Exception("Part time workers are not permitted to work.");
        }
        System.out.print("A full time worker is working for " + worker.getDuration() + " hours :: ");
        for (int i = 1; i < worker.getDuration(); i++) {
            System.out.print("* ");
        }
        System.out.println();
    }
}

Main.java test class

package edu.pk.poc.aop.test;

import edu.pk.poc.aop.controller.WorkerController;
import edu.pk.poc.aop.helper.ProxyFactory;
import edu.pk.util.Logger;

public class Main {
    public static void main(String[] args) {
        WorkerController controller = ProxyFactory.createProxy(WorkerController.class);
        Logger logger = new Logger();
        try {
            System.out.println("Testing @BeforeMethod and @AfterMethod");
            System.out.println("-----------------------------------------");
            controller.engageFullTimeWorker();
            System.out.println("Testing @All");
            System.out.println("-----------------------------------------");
            controller.engagePartTimeWorker();
        } catch (Exception e) {
            logger.error("Exception caught in Main class");
        }
    }
}

Output

Testing @BeforeMethod and @AfterMethod
-----------------------------------------
>>> Entering into edu.pk.poc.aop.controller.WorkerController.engageFullTimeWorker()
A full time worker is working for 9 hours :: * * * * * * * * 
>>> Exiting from edu.pk.poc.aop.service.WorkerServiceImpl.doWork()
>>> Exiting from edu.pk.poc.aop.controller.WorkerController.engageFullTimeWorker()
Testing @All
-----------------------------------------
>>> Entering into edu.pk.poc.aop.controller.WorkerController.engagePartTimeWorker()
>>> Exception in edu.pk.poc.aop.controller.WorkerController.engagePartTimeWorker()
Exception caught in Main class

How It Works

When a method is invoked on a proxy object, the call is intercepted by the handler, which uses reflection to inspect all the annotations on the target method. Based on those annotations, the handler decides whether to log method entry/exit, log exceptions, or skip logging altogether.

Here’s how you can visualize it:

Before Execution: Log method entry.
After Execution: Log method exit or success.
All: Log method entry, method entry and on exception if raised. This dynamic behavior shows that Spring AOP leverages core Java APIs rather than employing some magical trick.

Define Annotations

package edu.pk.poc.aop.annotation;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface AfterMethod {

}

package edu.pk.poc.aop.annotation;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface BeforeMethod {

}

package edu.pk.poc.aop.annotation;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface All {

}

Define Proxy Factory

package edu.pk.poc.aop.helper;

/**
 * The {@code ProxyFactory} class is responsible for creating proxy objects using the Javassist library.
 * It allows for dynamic generation of proxies for classes or interfaces, with support for method interception.
 */
public class ProxyFactory {

    /**
     * A Javassist ProxyFactory instance used to generate proxy classes.
     */
    private static final javassist.util.proxy.ProxyFactory factory = new javassist.util.proxy.ProxyFactory();

    /**
     * Creates a proxy object for the given class or interface.
     * If the class is an interface, the proxy implements the interface.
     * If it's a concrete class, the proxy extends the class.
     *
     * @param <T>   the type of the class or interface for which the proxy is to be created
     * @param klass the {@code Class} object representing the class or interface to proxy
     * @return a proxy instance of the specified class or interface, or {@code null} if proxy creation fails
     */
    public static <T> T createProxy(Class<T> klass) {
        if (klass.isInterface())
            factory.setInterfaces(new Class[]{klass});
        else
            factory.setSuperclass(klass);
        try {
            return (T) factory.create(new Class<?>[0], new Object[0], new AOPLoggingMethodHandler());
        } catch (Exception e) {
            System.err.println(e.getMessage());
        }
        return null;
    }
}

Define MethodHandler

package edu.pk.poc.aop.helper;

import edu.pk.poc.aop.annotation.AfterMethod;
import edu.pk.poc.aop.annotation.All;
import edu.pk.poc.aop.annotation.BeforeMethod;

import java.lang.annotation.Annotation;
import java.lang.reflect.Method;

import edu.pk.util.Logger;
import javassist.util.proxy.MethodHandler;

/**
 * This class is a MethodHandler implementation for Javassist proxies.
 * It intercepts method calls and provides logging functionality based on custom annotations.
 */
public class AOPLoggingMethodHandler implements MethodHandler {

    private static final Logger logger = new Logger();

    /**
     * This method intercepts method calls on the proxied object.
     * It checks for the presence of custom annotations (@BeforeMethod, @AfterMethod, @All)
     * and logs messages accordingly.
     *
     * @param self       The proxy object.
     * @param thisMethod The method being invoked on the proxy object.
     * @param proceed    The original method being proxied.
     * @param args       The arguments passed to the method.
     * @return The result of the method invocation.
     * @throws Throwable If any exception occurs during method invocation.
     */
    public Object invoke(Object self, Method thisMethod, Method proceed, Object[] args) throws Throwable {
        if (proceed != null) { // Concrete Method
            Object result = null;
            String className = resolveClassName(self);
            try {
                if (isAnnotationPresent(thisMethod, BeforeMethod.class) || isAnnotationPresent(thisMethod, All.class)) {
                    logger.info(">>> Entering into " + className + "." + thisMethod.getName() + "()");
                }
                result = proceed.invoke(self, args);
                if (isAnnotationPresent(thisMethod, AfterMethod.class) || isAnnotationPresent(thisMethod, All.class)) {
                    logger.info(">>> Exiting from " + className + "." + thisMethod.getName() + "()");
                }
            } catch (Throwable t) {
                if (isAnnotationPresent(thisMethod, All.class)) {
                    logger.error(">>> Exception in " + className + "." + thisMethod.getName() + "()");
                }
                throw t;
            }
            return result;
        }
        throw new RuntimeException("Method is Abstract");
    }

    /**
     * Checks if the given method is annotated with the specified annotation class.
     *
     * @param method The method to check for annotation.
     * @param klass  The annotation class to check for.
     * @return True if the annotation is present, false otherwise.
     */
    private boolean isAnnotationPresent(Method method, Class klass) {
        Annotation[] declaredAnnotationsByType = method.getAnnotationsByType(klass);
        return declaredAnnotationsByType != null && declaredAnnotationsByType.length > 0;
    }

    /**
     * Resolves the class name of the proxied object, removing any Javassist proxy suffixes.
     *
     * @param self The proxy object.
     * @return The resolved class name.
     */
    private String resolveClassName(Object self) {
        String className = self.getClass().getName();
        if (className.contains("_$$")) {
            className = className.substring(0, className.indexOf("_$$"));
        }
        return className;
    }
}

Conclusion

Spring AOP is a powerful tool for cross-cutting concerns, but it’s not doing anything revolutionary. It’s built on core Java concepts like reflection and proxies, which are available in the language itself. By understanding this, you can better appreciate how Spring simplifies these lower-level mechanics for developer convenience.

Keep "Vacuous truth" on top of mind while coding with java.util.stream API

Prabhat Kumar — Mon, 02 Sep 2024 14:40:15 +0000

Introduction
What is Vacuous Truth?
- Problem Statement
- Enter Vacuous Truth
  - Mathematical Definition of Vacuous Truth
- Why Does This Matter in Programming?
- References

Introduction

Have you ever encountered a scenario in programming where you need to check if all elements in a list or stream satisfy a certain condition? This is a common pattern in coding, but what happens when the list is empty? This is where the concept of vacuous truth comes into play.

What is Vacuous Truth?

Before we dive into the mathematical definition, let’s start with a practical example in code to understand what vacuous truth is.

Problem Statement

Imagine you are tasked with checking if all elements in a list satisfy a certain condition. If they do, you perform a specific action. For example, consider the following Java code snippet:

  public static void main(String[] args) {
    // Example - 1, expected to do something
    if (allNumbersAreOdd(Arrays.asList(1, 3, 5))) {
      System.out.println("do something 1");
    }
    // Example - 2, NOT expected to do anything because NOT all numbers are odd
    if (allNumbersAreOdd(Arrays.asList(1, 2, 3, 4, 5))) {
      System.out.println("do something 2");
    }
    // Example - 3, NOT expected to do anything because list is empty so there is no odd number.
    /* This is the surprising element which is known as "Vacuous truth" and it will print "do something".
     * It is applicable to both allMatch(Predicate<? super T> predicate) 
     * and noneMatch(Predicate<? super T> predicate) */
    if (allNumbersAreOdd(Collections.emptyList())) {
      System.out.println("do something 3");
    }
  }

  private static boolean allNumbersAreOdd(@Nonnull List<Integer> numbers) {
    return numbers.stream().allMatch(integer -> integer % 2 != 0);
  }

The third example is particularly interesting. Why does it return "All numbers are odd" when the list is empty?

Enter Vacuous Truth

This behavior is an example of vacuous truth. In mathematical logic, a statement that asserts something about all elements of an empty set is considered true. This is because there are no elements in the set to contradict the statement.

Mathematical Definition of Vacuous Truth

According to Wikipedia:

"A vacuous truth is a statement that asserts that all members of the empty set have a certain property. Such statements are considered true because there are no counterexamples in the empty set."

In other words, when we say, "All elements of set S have property P," and if S is empty, this statement is vacuously true because there isn’t a single element in S that could potentially violate property P

Why Does This Matter in Programming?

Understanding vacuous truth is important in programming because it can impact the logic and outcomes of your code, especially when dealing with collections, streams, or any scenario where your input could potentially be empty.

Conclusion
Next time you're writing a function that checks if all elements in a list or stream satisfy a condition, remember the concept of vacuous truth. It explains why your code might behave in an unexpected way when the input is empty. Being aware of this can help you write more robust and predictable programs.
If you have requirement of an empty list/stream must not be evaluated as true, then you have to consider additional check on list/stream.

  private static boolean allNumbersAreOdd(@Nonnull List<Integer> numbers) {
    return !numbers.isEmpty() && numbers.stream().allMatch(integer -> integer % 2 != 0);
  }

References

Wikipedia: Vacuous truth
API note in Java documentation:
- boolean allMatch(Predicate<? super T> predicate)
- boolean noneMatch(Predicate<? super T> predicate)