Stop using 50MB frameworks to manage one single instance of a Logger.
Most developers think they know how to write a Singleton. They read a blog post a decade ago and haven't checked if that information is still valid for the modern JVM. The result? Production code filled with thread-safety issues, memory leaks, and "Senior" implementations that are actually maintenance liabilities.
We’ve moved from "Singletons everywhere" to "DI frameworks for everything," but we’ve forgotten how to actually use the JVM.
In my latest post, I break down:
- The Reality of Failure: Why "Double-Checked Locking" is often just a sophisticated way to introduce bugs.
- The "Resume-Driven Development" Trap: Why we over-engineer simple patterns just to look smart.
- The 2026 Standard: Why the Enum Singleton remains the only truly bulletproof implementation.
- Testing Myths: Why "Singletons are hard to test" is usually a symptom of poor interface design, not the pattern itself.
Complexity is debt. Every line of extra code is something that can break at 3 AM. If you’re still writing ten lines of synchronized boilerplate for a task that requires one, you're building a liability, not a feature.
1 comment
[ 3.8 ms ] story [ 10.2 ms ] threadMost developers think they know how to write a Singleton. They read a blog post a decade ago and haven't checked if that information is still valid for the modern JVM. The result? Production code filled with thread-safety issues, memory leaks, and "Senior" implementations that are actually maintenance liabilities.
We’ve moved from "Singletons everywhere" to "DI frameworks for everything," but we’ve forgotten how to actually use the JVM.
In my latest post, I break down: - The Reality of Failure: Why "Double-Checked Locking" is often just a sophisticated way to introduce bugs. - The "Resume-Driven Development" Trap: Why we over-engineer simple patterns just to look smart. - The 2026 Standard: Why the Enum Singleton remains the only truly bulletproof implementation. - Testing Myths: Why "Singletons are hard to test" is usually a symptom of poor interface design, not the pattern itself.
Complexity is debt. Every line of extra code is something that can break at 3 AM. If you’re still writing ten lines of synchronized boilerplate for a task that requires one, you're building a liability, not a feature.