Tomasz Nurkiewicz around Java and concurrency

My colleagues are developing a trading system that processes quite heavy stream of incoming transactions. Each transaction covers one Instrument (think bond or stock) and has some (now) unimportant properties. They are stuck with Java (< 8), so let's stick to it:

class Instrument implements Serializable, Comparable<Instrument> { private final String name; public Instrument(String name) { this.name = name; } //...Java boilerplate } public class Transaction { private final Instrument instrument; public Transaction(Instrument instrument) { this.instrument = instrument; } //...Java boilerplate } Instrument will later be used as a key in HashMap, so for the future we pro-actively implement Comparable<Instrument>. This is our domain, now the requirements:

Transactions come into the system and need to be processed (whatever that means), as soon as possibleWe are free to process them in any order...however transactions f…

If InterruptedException wasn't checked exception, probably no one would even notice it - which would actually prevent couple of bugs throughout these years. But since it has to be handled, many handle it incorrectly or thoughtlessly. Let's take a simple example of a thread that periodically does some clean up, but in between sleeps most of the time.

class Cleaner implements Runnable { Cleaner() { final Thread cleanerThread = new Thread(this, "Cleaner"); cleanerThread.start(); } @Override public void run() { while(true) { cleanUp(); try { TimeUnit.SECONDS.sleep(1); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } } private void cleanUp() { //... } } This code is wrong on so many layers!

Starting Thread in a constructor might not be a good idea in some environments, e.g. some frameworks like Spring will create dynamic subclass to support m…