@ankurm

Ankur in Java

Mastering Java Comparator: A Practical Guide to Custom Sorting

As a Java developer, you constantly work with collections of objects. While sorting a list of strings or numbers is trivial, what happens when you need to sort a list of your own custom objects, like Employee or Product? How do you tell Java how to order them? By salary? By name? By age? This is precisely the problem the Comparator interface was designed to solve. In this guide, we’ll take a deep dive into the java.util.Comparator. We’ll explore everything from the classic implementation methods to the elegant and powerful approaches introduced in Java 8. By the end, you’ll be able to handle any custom sorting challenge with confidence. What Exactly is a Java Comparator? At its core, a Comparator is an object that encapsulates a specific sorting logic. It’s a functional interface whose main purpose is to define a custom order for a set of objects that might not have a natural ordering or when you need an ordering different from the natural one.

Ankur in Java

Taming Object Chaos: The Mediator Design Pattern Explained

Imagine you’re building a complex user interface. You have a dozen different components: buttons, text fields, checkboxes, and dropdowns. A change in one component needs to affect several others. For example, selecting an option in a dropdown might enable a specific button, disable a checkbox, and populate a text field. If you make these components talk directly to each other, you’ll quickly end up with a tangled mess. Each component will need a direct reference to every other component it interacts with. This is what we call “spaghetti code”—a nightmare to debug, maintain, and extend. Every time you add a new component, you have to go back and wire it up to all the existing ones. So, how do we clean up this mess? Enter the Mediator Pattern. The Mediator Pattern is a behavioral design pattern that provides a centralized communication hub for a group of objects. Instead of talking to each other directly, these objects (called Colleagues) only talk to the central hub (the Mediator). The Mediator then relays messages and coordinates actions between the Colleagues.

Ankur in Java

Solving the Producer-Consumer Problem in Java with BlockingQueue

The Producer-Consumer problem is a classic concurrency puzzle that every Java developer encounters. It provides a fantastic model for understanding how to coordinate tasks between different threads. Imagine a restaurant kitchen: chefs (producers) cook dishes and place them on a pass, and waiters (consumers) pick them up to serve. The pass is a shared space with a limited capacity. This is the Producer-Consumer problem in a nutshell. In this tutorial, we’ll explore the modern and elegant solution to this problem in Java using the BlockingQueue interface from the java.util.concurrent package. What is the Producer-Consumer Problem? The problem involves two types of processes, or threads, that share a common, fixed-size buffer or queue: The Producer: Its job is to generate data (or “products”) and put it into the shared buffer. The Consumer: Its job is to take data from the buffer and process it. The core challenges we need to solve are: The producer must not try to add data to the buffer if it’s full. It should wait until there is space. The consumer must not try to take data from the buffer if it’s empty. It should wait until there is data available. The shared buffer must be accessed in a thread-safe manner to prevent race conditions and data corruption.

Ankur in Java

Boosting RESTeasy Performance: Enable GZIP Compression for Faster APIs

In the world of high-performance APIs, speed is paramount. Delivering data quickly and efficiently significantly improves user experience and reduces server load. One of the most effective strategies for achieving this is GZIP compression. This post will guide you through enabling GZIP compression (Content Encoding) in your JAX-RS (RESTeasy) applications, ensuring your APIs are leaner and meaner. GZIP works by compressing the data transferred between your server and the client. When a client requests data, the server can compress the response using GZIP before sending it. The client then decompresses the data, resulting in less data transmission over the network. This is particularly beneficial for large payloads like JSON or XML. Most modern browsers and HTTP clients automatically support GZIP decompression. How to Enable GZIP Compression in RESTeasy Enabling GZIP compression in RESTeasy is straightforward and primarily involves configuring your JAX-RS application. There are two main approaches: 1. Using the resteasy.providers Context Parameter (Recommended for Servlet Containers) This is the most common and recommended way for applications deployed in traditional servlet containers like Tomcat, JBoss/WildFly, or Jetty. You’ll add a context parameter to your web.xml file.

Ankur in Tomcat

Effortless Deployment: Your Guide to the Tomcat Maven Plugin

As a developer, I’m always looking for ways to streamline my workflow, especially when it comes to deploying applications. If you’re working with Maven and Tomcat, the Tomcat Maven Plugin is an absolute game-changer. It allows you to deploy, start, stop, and even redeploy your web applications directly from your Maven build, eliminating the need for manual server interactions. In this post, we’ll dive deep into using this powerful plugin, complete with practical examples to get you up and running quickly. Let’s get started! What is the Tomcat Maven Plugin? The Tomcat Maven Plugin is a Maven plugin that provides goals for running and deploying web applications to an embedded or standalone Tomcat server. It simplifies the development and testing cycle by allowing you to manage your application’s lifecycle within your Maven project.

Ankur in Python

How to Count Occurrences of a Substring in a Python String

Ever found yourself needing to know how many times a specific character or word appears in a piece of text? Whether you’re analyzing user input, parsing log files, or just working with text data, counting occurrences is a fundamental task. Python, with its “batteries-included” philosophy, provides a simple and efficient built-in method for this: string.count(). In this tutorial, we’ll walk you through everything you need to know about using the count() method, from basic usage to more advanced examples. Understanding the count() Method Syntax The syntax for the count() method is straightforward and flexible. It’s called on a string object and looks like this: string.count(substring, start, end) Let’s break down the parameters: substring: (Required) This is the character or sequence of characters you want to count within the main string. start: (Optional) An integer specifying the index from where the search should begin. If omitted, it defaults to 0 (the beginning of the string). end: (Optional) An integer specifying the index where the search should end. If omitted, it defaults to the end of the string. The method returns an integer representing the total number of non-overlapping occurrences of the substring.

Ankur in Java

How to Configure Multiple Log Appenders in Log4j2 (Console and File)

In modern application development, logging isn’t a one-size-fits-all task. During development, you want to see logs immediately on your console. In production, you need those same logs persisted to a file for auditing, debugging, and historical analysis. What if you want both at the same time? This is where Log4j2’s powerful feature of multiple appenders comes in. An Appender in Log4j2 is simply a destination for your log messages. By configuring multiple appenders, you can direct your application’s logs to various destinations simultaneously—like the console, a rolling file, a database, or even a messaging queue. In this tutorial, we’ll walk through the most common use case: configuring Log4j2 to write logs to both the console and a rolling file. The Core Concept: Define and Attach Configuring multiple appenders in Log4j2 is a straightforward two-step process: Define Appenders: In the <Appenders> section of your configuration file, you define each output destination you want to use. Each appender is given a unique name (e.g., “Console”, “File”). Attach Appenders to Loggers: In the <Loggers> section, you tell a logger (like the root logger) which of the defined appenders it should use. You do this by referencing the appenders by their names. Let’s see this in action.

Ankur in Java

A Practical Guide to the Chain of Responsibility Pattern in Java

As developers, we often face scenarios where a request needs to go through a series of processing steps, validations, or transformations. A naive approach might involve a massive if-else if-else block or a complex switch statement. This code quickly becomes rigid, hard to maintain, and a nightmare to extend. What if you could create a flexible pipeline where each step can decide whether to handle the request or simply pass it along? This is precisely the problem the Chain of Responsibility pattern solves. It’s a behavioral design pattern that lets you build a chain of processing objects. A request enters the chain and is passed from one object to the next until one of them handles it. The core idea is to decouple the sender of a request from its receivers, giving multiple objects a chance to handle the request. Think of an ATM dispensing cash. When you request an amount, the machine doesn’t just grab a random mix of bills. It has a logic: first, try to dispense the largest denominations (like $50 bills), then pass the remaining amount to the next dispenser (e.g., $20 bills), and so on, until the full amount is dispensed. Each dispenser in this chain is a handler. What is the Chain of Responsibility Pattern? The pattern consists of a source that initiates a request and a series of “handler” objects. Each handler contains a reference to the next handler in the chain and implements a common interface for processing requests.

Ankur in Java

Java’s ExecutorService.invokeAny(): Winning the Race for the First Result

In the world of concurrent programming, we often face scenarios where we need to perform the same task in multiple ways, but we only care about the first successful result. Imagine querying three different microservices for the same piece of data. You don’t care which service responds, as long as you get the data as quickly as possible. Once you have it, the other requests become redundant. How do you efficiently manage this “race”? You could manually spin up threads, use a CountDownLatch or a Phaser, and manage a shared result variable with locks. But that’s complicated and error-prone. Fortunately, Java’s ExecutorService provides a clean, powerful, and built-in solution: the invokeAny() method. Let’s dive into how invokeAny() works and how you can use it to write cleaner, more efficient concurrent code. What is ExecutorService.invokeAny()? The invokeAny() method is a blocking operation that submits a collection of Callable tasks to an ExecutorService. It doesn’t wait for all of them to finish. Instead, it waits for the first task to complete successfully (i.e., without throwing an exception) and returns its result. As soon as one task finishes, invokeAny() returns its result and immediately attempts to cancel all other running or pending tasks. This “fire-and-forget-the-rest” behavior makes it the perfect tool for tasks involving redundancy and speed.

Ankur in Java

Don’t Specify Version Numbers in Spring XML Schema References

If you’ve been working with Spring Framework for a while, especially with its XML-based configuration, you’ve likely encountered a pattern in the <beans> element where schema locations are defined. It often looks something like this: <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd">  </beans> Notice the -3.0.xsd at the end of the schema locations? This explicitly ties your configuration to a specific version of the Spring schema. While this might seem harmless or even like a good idea for precision, it can actually lead to unnecessary headaches and maintenance overhead. Why You Shouldn’t Include Version Numbers The Spring Framework is designed with backward compatibility in mind. When a new version of Spring is released (e.g., Spring 3.0, 4.0, 5.0, etc.), the XML schemas are generally updated to include new features or deprecate old ones, but they usually remain compatible with configurations written for previous versions, especially if you’re not using any of the very latest, specific features.