Articles, tutorials, and insights about functional programming in Java
A method signature is a contract. Most Java APIs break that contract silently — returning null, throwing undeclared exceptions, or hiding multiple outcomes behind a boolean. Functional types turn vague promises into honest, self-documenting interfaces.
Adding a functional library to a Java codebase rarely solves the underlying problem on its own. Sometimes the library is the right answer. Sometimes the problem is discipline, naming, and design — and a library just gives bad habits a fancier vocabulary.
Legacy systems do not need a rewrite to benefit from functional programming. The right approach is incremental: find the seams, wrap the dangerous parts, and grow functional islands outward. A practical guide for Java teams working with existing production code.
Sealed types make your domain states explicit and exhaustive. Pattern matching forces every caller to handle them all. Together they turn a class of runtime surprises into compile-time errors — and make the business model readable in the type signatures.
Lazy evaluation defers a computation until its result is actually needed. That single idea eliminates wasted work, enables safe default values, and defers heavy initialization — but it also introduces traps around side effects, debugging, and error timing that you need to know before reaching for it.
Higher-order functions are not just map and filter. They are the mechanism behind every composable pattern in functional programming — Strategy, Decorator, Policy, pipeline — explained through real backend Java code.
Predictable code is code you can understand without reading everything around it. Functional programming gives you three concrete tools to get there: pure functions, honest signatures, and immutable values.
0.1.0 is the first stable, production-ready release of dmx-fun: a battle-tested ecosystem of functional programming modules for Java backends, with first-class Spring Boot and Quarkus support.
Functional idioms improve code when applied to the problems they solve. Applied to problems they do not solve, they add ceremony, obscure intent, and hurt performance. This post catalogs the specific cases where the functional version is the worse version — and why.
The case against mutable state is not philosophical. It is a list of bugs that mutable state causes reliably, in every codebase, on every team. This post names them, shows what they look like in Java backend code, and demonstrates the concrete improvement that comes from eliminating each one.
