97 Things Every Java Programmer Should Know

Chapter 70. Rediscover the JVM Through Clojure

James Elliott

Sometime around 2007, my office book club read Java Concurrency in Practice by Brian Goetz (Addison-Wesley). We weren’t far past the preface of this important book when we panicked about how wrong our naive understanding of Java’s memory model had been, and how easily bugs are introduced into multithreaded code. There were audible gasps, and at least one reported nightmare.

In developing a highly concurrent cloud offering, we needed a language that wouldn’t litter our codebase with landmines of shared, mutable state. We chose Clojure: it has solid concurrency answers and favors functional, efficient transformation of immutable data. It runs on the familiar JVM, interoperating smoothly with the huge ecosystem of Java libraries. Though some were hesitant about the unfamiliar Lisp syntax and about relearning how to program without mutating variables, it was a great decision.

We discovered the benefits of a REPL-centric (read–eval–print loop) workflow:

• No rebuilding or relaunching to test changes

• Exploring the running system and trying variations instantly

• Building and refining ideas incrementally

We appreciated Clojure’s bias toward working with data using standard structures and its rich, opinionated core library. You don’t have to create lots of classes—each with its own mutually incompatible API—to model anything. ...