Tomasz Nurkiewicz around Java and concurrency

Do you know the feeling when you discover a bug in a functionality that was working couple of weeks (or versions) ago? Too bad we didn’t have any automated tests and what used to be fine, now is broken. Let’s take this simple repository as an example:

Write test first We noticed that some particular functionality was OK in version 1.0 but is broken in 1.1. What is the first thing we do? Of course write a test case to make sure this bug, once fixed, never comes back! Writing (failing) test for every bug you find has many advantages:

It documents bugs and proves they were fixedNon-obvious workarounds and solutions will not be removed ("why was he checking for null here?! It’s impossible, let's simplify it") by accidentYou gradually improve overall code coverage, even in legacy codebase. So you have a failing test case. But even with isolated test you can't reliably figure out what is wrong. If only we could find a commit that broke that test - assuming commits are small…

Considering legacy Java code, no matter where you look, Java 8 with lambda expressions can definitely improve quality and readability. Today let us look at ReadWriteLock and how we can make using it simpler. Suppose we have a class called Buffer that remembers last couple of messages in a queue, counting and discarding old ones. The implementation is quite straightforward:

public class Buffer { private final int capacity; private final Deque<String> recent; private int discarded; public Buffer(int capacity) { this.capacity = capacity; this.recent = new ArrayDeque<>(capacity); } public void putItem(String item) { while (recent.size() >= capacity) { recent.removeFirst(); ++discarded; } recent.addLast(item); } public List<String> getRecent() { final ArrayList<String> result = new ArrayList<>(); result.addAll(recent); return result; …