Posts

Different States of Java Threads

Image
Introduction In Java, threads can have States. The Thread.State enum defines the different states that a Java thread can have. This enum defines the following values -
NEWRUNNABLEBLOCKEDWAITINGTIMED_WAITINGTERMINATED In the subsequent sections, I provide a brief overview of these states along with possible transitions between them.

States of a Java Thread NEW This is the default state a thread gets when it is first created.
RUNNABLE As soon as a thread starts executing, it moves to the RUNNABLE state. Note that a thread that is waiting to acquire a CPU for execution is still in this state.
BLOCKED A thread moves to the BLOCKED state as soon as it gets blocked waiting for a monitor lock. This can happen in one of the following two ways - It's waiting to acquire a lock to enter a synchronised block/method.It's waiting to reacquire the monitor lock of an object on which it invoked the Object.wait method.
WAITING A thread moves to this state as a result of invoking one of the follo…

A brief overview of the Fork/Join Framework in Java

Introduction The Fork/Join framework is a framework to solve a problem using a concurrent divide-and-conquer approach. They were introduced to complement the existing concurrency API. Before their introduction, the existing ExecutorService implementations were the popular choice to run asynchronous tasks, but they work best when the tasks are homogenous and independent. Running dependent tasks and combining their results using those implementations were not easy. With the introduction of the Fork/Join framework, an attempt was made to address this shortcoming. In this post, we will take a brief look at the API and solve a couple of simple problems to understand how they work.
Solving a non-blocking task Let's jump directly into code. Let's create a task which would return the sum of all elements of a List. The following steps represent our algorithm in pseudo-code:
01. Find the middle index of the list 02. Divide the list in the middle 03. Recursively create a new task which will …

Java Tips: Creating a Monitoring-friendly ExecutorService

In this article we will be extending an ExecutorService implementation with monitoring capabilities. This monitoring capability will help us to measure a number of pool parameters i.e., active threads, work queue size etc. in a live production environment. It will also enable us to measure task execution time, successful tasks count, and failed tasks count.

Monitoring Library As for the monitoring library we will be using Metrics. For the sake of simplicity we will be using a ConsoleReporter which will report our metrics to the console. For production-grade applications, we should use an advanced reporter (i.e., Graphite reporter). If you are unfamiliar with Metrics, then I recommend you to go through the getting started guide.

Let's get started.

Extending the ThreadPoolExecutor We will be using ThreadPoolExecutor as the base class for our new type. Let's call it MonitoredThreadPoolExecutor. This class will accept a MetricRegistry as one of its constructor parameters -

public …

JPA Tips: Avoiding the N + 1 select problem

Introduction ORM frameworks like JPA simplifies our development process by helping us to avoid lots of boilerplate code during the object <-> relational data mapping. However, they also bring some additional problems to the table, and N + 1 is one of them. In this article we will take a short look at the problem along with some ways to avoid them.

The Problem As an example I will use a simplified version of an online book ordering application. In such application I might create an entity like below to represent a Purchase Order -
@Entity public class PurchaseOrder { @Id private String id; private String customerId; @OneToMany(cascade = ALL, fetch = EAGER) @JoinColumn(name = "purchase_order_id") private List<PurchaseOrderItem> purchaseOrderItems = new ArrayList<>(); }
A purchase order consists of an order id, a customer id, and one or more items that are being bought. The PurchaseOrderItem entity might have the following structure…

Replacing exceptions with error notifications during input validation in Java

In my previous article I wrote about an input validation design which replaces hard-to-maintain-and-test if-else blocks. However, as some readers pointed out, it has a drawback - if the input data has more than one validation errors, then the user will have to submit the request multiple times to find all of them. From a usability perspective this is not a good design.

An alternative to throwing exceptions when we find a validation error is to return a Notification object containing the error(s). This will enable us to run all the validation rules on the user input, and catch all violations at the same time. Martin Fowler wrote an article detailing the approach. I highly recommend you to go ahead and give it a read, if you haven't done so already.

In this article I will refactor my previous implementation to use Error Notification object to validate user inputs.

As a first step, I will create an ErrorNotification object which encapsulates my application errors -
public class Error…

Clean Code from the trenches - Validation

Let's directly start with an example. Consider a simple web service which allows clients to place order to a shop. A very simplified version of the order controller could look something like below -

@RestController @RequestMapping(value = "/", consumes = MediaType.APPLICATION_JSON_VALUE, produces = MediaType.APPLICATION_JSON_VALUE) public class OrderController { private final OrderService orderService; public OrderController(OrderService orderService) { this.orderService = orderService; } @PostMapping public void doSomething(@Valid @RequestBody OrderDTO order) { orderService.createOrder(order); } }
And the corresponding DTO class -

@Getter @Setter @ToString public class OrderDTO { @NotNull private String customerId; @NotNull @Size(min = 1) private List<OrderItem> orderItems; @Getter @Setter @ToString public static class OrderItem { private String menuId; private String description; private String pric…

Dealing with Java's LocalDateTime in JPA

A few days ago I ran into a problem while dealing with a LocalDateTime attribute in JPA. In this blog post I will try to create a sample problem to explain the issue, along with the solution that I used.
Consider the following entity, which models an Employee of a certain company -
@Entity @Getter @Setter public class Employee { @Id @GeneratedValue private Long id; private String name; private String department; private LocalDateTime joiningDate; }
I was using Spring Data JPA, so created the following repository -
@Repository public interface EmployeeRepository extends JpaRepository<Employee, Long> { }
I wanted to find all employees who have joined the company at a particular date. To do that I extended my repository from JpaSpecificationExecutor - @Repository public interface EmployeeRepository extends JpaRepository<Employee, Long>, JpaSpecificationExecutor<Employee> { }
and wrote a query like below -
@SpringBootTest @RunWith(SpringRunne…