Java Archives - Page 21 of 29

Ankur in Java

Deep Dive into Java’s PriorityBlockingQueue

Let's explore a powerful and often-underutilized concurrent collection in Java: the PriorityBlockingQueue. If you’re building multi-threaded applications where task prioritization and producer-consumer patterns are crucial, understanding this class is a game-changer. The PriorityBlockingQueue is part of Java’s java.util.concurrent package. As its name suggests, it combines the features of a PriorityQueue and a BlockingQueue. Let’s break down what that means. What is PriorityBlockingQueue? At its core, PriorityBlockingQueue is an unbounded blocking queue (meaning it doesn’t have a fixed capacity, though memory limits apply) that orders its elements according to their natural ordering, or by a Comparator provided at queue construction time. Elements with higher priority (as defined by their comparison) are retrieved first.

Ankur in Java

Integrating Gson with JAX-RS (Jersey) for Seamless JSON Handling

JSON has become the de-facto standard for data exchange in web services, and for Java developers, Gson is a highly popular library for converting Java objects to JSON and vice-versa. When building RESTful APIs with JAX-RS (specifically Jersey), integrating Gson can significantly streamline your development process. This post will guide you through setting up a Jersey project to leverage Gson for automatic JSON serialization and deserialization. Why Gson with JAX-RS? While JAX-RS implementations like Jersey often come with their own default JSON providers (like Jackson), Gson offers a lightweight and often more intuitive API for many developers. Its simple approach to serialization and deserialization, along with features like custom type adapters and versioning, makes it a compelling choice for many projects.

Ankur in Java

HashMap vs. Hashtable in Java: A Practical Comparison

When you’re working with key-value pairs in Java, the Collections Framework offers several Map implementations. Two of the most frequently discussed are HashMap and Hashtable. While they seem to serve a similar purpose, they have crucial differences that every Java developer must understand. This is a classic Java interview question, but more importantly, choosing the right one has real-world implications for your application’s performance and stability. Let’s cut to the chase: For almost all new development, you should use HashMap or ConcurrentHashMap. Hashtable is a legacy class that you should generally avoid. This guide will break down why. Key Differences: HashMap vs. Hashtable Here are the fundamental distinctions between HashMap and Hashtable, starting with the most important one. 1. Synchronization and Thread-Safety This is the single most critical difference between the two. Hashtable is synchronized. This means all of its public methods, like put() and get(), are marked with the synchronized keyword. Only one thread can access the Hashtable instance at a time. While this makes it thread-safe, it comes at a significant performance cost due to contention, as threads have to wait for the lock to be released. HashMap is non-synchronized. It makes no guarantees about thread safety. If multiple threads access a HashMap concurrently and at least one of them modifies the map structurally, it can lead to data inconsistency and unexpected behavior. External synchronization is required if you need to use it in a multi-threaded context.

Ankur in Java

CopyOnWriteArrayList in Java: When It Wins (JMH) and When It Hurts

CopyOnWriteArrayList trades an expensive, array-copying write for a lock-free read and an iterator that can never throw ConcurrentModificationException. This rewrite backs that trade-off with real JMH read/write throughput benchmarks, two deterministic concurrency demos built on CountDownLatch barriers instead of Thread.sleep guesses, a genuine concurrent-writer race condition caught and fixed mid-benchmark, and a javap-verified correction: the internal lock is a plain Object monitor, not a ReentrantLock.

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.

Ankur in Java

Configuring ResourceBundleViewResolver in Spring MVC

In a Spring MVC application, a ViewResolver is responsible for mapping logical view names that your controllers return to actual .jsp files (or Thymeleaf templates, etc.). When you need to support multiple locales and provide messages or titles that vary per language, a ResourceBundleViewResolver is a convenient choice. This post walks through a minimal, but complete, configuration that you can drop into any Spring MVC project. Problem Statement Suppose you want a home.jsp that displays a greeting, a welcome message, and a page title, all of which should change depending on the user’s locale. You also want to keep the JSPs simple, so you delegate the translation of these messages to a standard Java ResourceBundle (properties file). Solution Overview Define the view resolver so it first looks for a messages_*.properties file. Configure the ViewResolver hierarchy to fall back to the default view resolver if a match isn’t found. Create a simple controller that forwards to a logical view name. Write the JSP that pulls values from the resource bundle.

Ankur in Java

Troubleshoot: java.lang.ClassNotFoundException: com.sun.jersey.spi.container.servlet.ServletContainer

Encountering a ClassNotFoundException is a common rite of passage for any Java developer. Specifically, the error java.lang.ClassNotFoundException: com.sun.jersey.spi.container.servlet.ServletContainer can be a head-scratcher when you’re working with web services, particularly when migrating or setting up a new project. This exception typically indicates that your application server (like Tomcat, JBoss, or Jetty) can’t find the necessary Jersey Servlet container class. Let’s break down why this happens and how to fix it. Understanding the Problem The class com.sun.jersey.spi.container.servlet.ServletContainer is a core component of the older **Jersey 1.x** framework. It’s responsible for bootstrapping and handling requests for your RESTful services. If your application attempts to load this class and it’s not present in the classpath, you’ll get the ClassNotFoundException. The most common reasons for this are: Missing Dependency: The required Jersey servlet JAR file is not included in your project’s build path or deployed WAR file. Incorrect Version: You’re using a mix of Jersey 1.x and Jersey 2.x (or later) dependencies, or your configuration points to a Jersey 1.x class while you’re using Jersey 2.x. Build Tool Misconfiguration: Your build tool (Maven, Gradle) isn’t correctly packaging the dependency. Deployment Issue: The JAR file isn’t correctly placed in the application server’s classpath (e.g., in WEB-INF/lib for web applications).

Ankur in Java

Exploring Java’s LinkedHashSet: Order-Preserving Uniqueness

In the vast and varied world of Java Collections, understanding the nuances of each data structure is crucial for writing efficient and robust code. Today, we're diving into a fascinating member of the Set family: the LinkedHashSet. While the standard HashSet offers blazing-fast O(1) average time complexity for most operations, it doesn't guarantee any order. Enter LinkedHashSet, which beautifully combines the best of both worlds: the uniqueness of a Set with the predictable, insertion-order iteration of a List. Think of it this way: a regular HashSet is like throwing items into a bag – you know they're all there, but when you pull them out, there's no telling which one will come first. A LinkedHashSet, on the other hand, is like placing items onto a conveyor belt – they maintain their original order as they were added, even though duplicates are still strictly rejected. What is LinkedHashSet? The LinkedHashSet class is a member of the Java Collections Framework, specifically implementing the Set interface and extending the HashSet class. It stores unique elements, just like a regular HashSet, but it also maintains a doubly-linked list running through its elements. This linked list defines the iteration order, which is the order in which elements were inserted into the set (insertion-order). Here are its key characteristics: Uniqueness: It does not allow duplicate elements. If you try to add an element that already exists, the operation will effectively do nothing, and the existing element's position will remain unchanged. Insertion Order: It maintains the order in which elements were inserted into the set. When you iterate over a LinkedHashSet, elements will be returned in the same sequence they were added. Null Elements: It can store one null element. Non-Synchronized: Like HashSet, LinkedHashSet is not synchronized. If multiple threads access a LinkedHashSet concurrently and at least one of the threads modifies the set, it must be synchronized externally. This is typically done by wrapping it with Collections.synchronizedSet(). Performance: It provides O(1) average-time performance for basic operations like add(), contains(), and remove(), assuming a good hash function. Due to the overhead of maintaining the linked list, it's generally slightly slower than HashSet but faster than TreeSet.