<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/stop-using-50mb-frameworks-to-manage-one-single-instance-of-a-logger-most-developers-think-they-k-kkpcugz5i" -->

---
title: Stop using 50MB frameworks to manage one single instance...
description: The Singleton pattern is often implemented incorrectly with thread-safety issues or unnecessary complexity. Common anti-patterns include broken lazy...
canonical: https://daily.dev/posts/stop-using-50mb-frameworks-to-manage-one-single-instance-of-a-logger-most-developers-think-they-k-kkpcugz5i
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: 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&#x27;t checked if that information is still valid for the modern JVM. The result? Production code filled with thread-safety issues, memory leaks, and &quot;Senior&quot; implementations that are actually maintenance liabilities.


We’ve moved from &quot;Singletons everywhere&quot; to &quot;DI frameworks for everything,&quot; but we’ve forgotten how to actually use the JVM.


In my latest post, I break down:

- The Reality of Failure: Why &quot;Double-Checked Locking&quot; is often just a sophisticated way to introduce bugs.

- The &quot;Resume-Driven Development&quot; 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 &quot;Singletons are hard to test&quot; 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&#x27;re building a liability, not a feature. | daily.dev
og:description: The Singleton pattern is often implemented incorrectly with thread-safety issues or unnecessary complexity. Common anti-patterns include broken lazy...
og:url: https://daily.dev/posts/stop-using-50mb-frameworks-to-manage-one-single-instance-of-a-logger-most-developers-think-they-k-kkpcugz5i
og:image: https://api.daily.dev/og/posts/KKPCuGZ5i.png
og:image:alt: 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&#x27;t checked if that information is still valid for the modern JVM. The result? Production code filled with thread-safety issues, memory leaks, and &quot;Senior&quot; implementations that are actually maintenance liabilities.


We’ve moved from &quot;Singletons everywhere&quot; to &quot;DI frameworks for everything,&quot; but we’ve forgotten how to actually use the JVM.


In my latest post, I break down:

- The Reality of Failure: Why &quot;Double-Checked Locking&quot; is often just a sophisticated way to introduce bugs.

- The &quot;Resume-Driven Development&quot; 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 &quot;Singletons are hard to test&quot; 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&#x27;re building a liability, not a feature.
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.

**[Just Java](https://daily.dev/sources/justjava)** · [@sergiolema](https://daily.dev/sergiolema) · 35 upvotes · 3 comments

## Summary

The Singleton pattern is often implemented incorrectly with thread-safety issues or unnecessary complexity. Common anti-patterns include broken lazy initialization (not thread-safe), eager initialization (slows startup), and over-engineered double-checked locking. The two professional approaches are the Bill Pugh Holder Idiom (lazy, thread-safe, simple) and Enum Singletons (bulletproof against reflection and serialization issues). True seniority means choosing the simplest solution that works, depending on interfaces rather than concrete implementations for testability, and avoiding over-engineering driven by ego.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://sergiolema.dev/2026/02/16/the-singleton-delusion-why-your-implementation-is-probably-broken/>

## Community discussion

Top comments from developers on daily.dev.

**@eugeneyaremenko** · 5 upvotes

> Just don't do statefull programming and you won't need them.

**@petermrozek** · 3 upvotes

> Nice, clean, simple and efficently uses the tools that the JVM gives you. 🙂
>
>
> What else could one want? That Iberian ham looks delicious (reminds me of our trip to Barcelona). Now I'm hungry. 😆

**@zia40** · 1 upvotes

> KISS --- Keep It Simple and Stupid!

## Similar posts on daily.dev

- [Don’t just attend KubeCon \+ CloudNativeCon, Merge Forward your experience\!](https://daily.dev/posts/don-t-just-attend-kubecon-cloudnativecon-merge-forward-your-experience--l0rpp73x8) · CNCF · 1 upvotes · 0 comments
- [Announcing H2 2026 KCDs](https://daily.dev/posts/announcing-h2-2026-kcds-m96goajm1) · CNCF · 1 upvotes · 0 comments
- [Two months of Open Community Groups](https://daily.dev/posts/two-months-of-open-community-groups-asf52zhbs) · CNCF · 0 upvotes · 0 comments
- [CNCF Unveils Schedule for KubeCon \+ CloudNativeCon Europe 2026](https://daily.dev/posts/cncf-unveils-schedule-for-kubecon-cloudnativecon-europe-2026-ikhcoa5cb) · CNCF · 2 upvotes · 0 comments
- [CNCF Debuts KubeCon \+ CloudNativeCon Japan 2026 Schedule](https://daily.dev/posts/cncf-debuts-kubecon-cloudnativecon-japan-2026-schedule-xp5pyudub) · CNCF · 1 upvotes · 0 comments

---

Tags: [#java](https://daily.dev/tags/java), [#architecture](https://daily.dev/tags/architecture), [#design-patterns](https://daily.dev/tags/design-patterns), [#jvm](https://daily.dev/tags/jvm)

[View this post on daily.dev](https://daily.dev/posts/stop-using-50mb-frameworks-to-manage-one-single-instance-of-a-logger-most-developers-think-they-k-kkpcugz5i)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"DiscussionForumPosting","mainEntityOfPage":"https://daily.dev/posts/stop-using-50mb-frameworks-to-manage-one-single-instance-of-a-logger-most-developers-think-they-k-kkpcugz5i","headline":"Stop using 50MB frameworks to manage one single instance of a Logger.\n\n\nMost 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.\n\n\nWe’ve moved from \"Singletons everywhere\" to \"DI frameworks for everything,\" but we’ve forgotten how to actually use the JVM.\n\n\nIn my latest post, I break down:\n\n- The Reality of Failure: Why \"Double-Checked Locking\" is often just a sophisticated way to introduce bugs.\n\n- The \"Resume-Driven Development\" Trap: Why we over-engineer simple patterns just to look smart.\n\n- The 2026 Standard: Why the Enum Singleton remains the only truly bulletproof implementation.\n\n- Testing Myths: Why \"Singletons are hard to test\" is usually a symptom of poor interface design, not the pattern itself.\n\n\nComplexity 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.","text":"Shared: The Singleton Delusion: Why Your Implementation is Probably Broken","url":"https://daily.dev/posts/stop-using-50mb-frameworks-to-manage-one-single-instance-of-a-logger-most-developers-think-they-k-kkpcugz5i","datePublished":"2026-02-16T08:23:46.565Z","dateModified":"2026-02-16T08:24:38.218Z","author":{"@type":"Person","name":"Sergio Lema","url":"https://daily.dev/sergiolema","image":"https://media.daily.dev/image/upload/s--nl9-vkt8--/f_auto/v1748851384/avatars/avatar_HLZdjQwXa17Moi8MkIaqn?_a=BAMClqUq0","description":"CTO | Web Development, AI Automation, DevOps & Cloud Expert","interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"EndorseAction"},"userInteractionCount":720}},"image":"https://media.daily.dev/image/upload/s--2-1xRawN--/f_auto/v1722860399/public/Placeholder%2011","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":35},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":3}],"sharedContent":{"@type":"WebPage","url":"https://api.daily.dev/r/k9rfFgWsG"},"comment":[{"@type":"Comment","text":"Just don’t do statefull programming and you won’t need them.","datePublished":"2026-02-25T13:23:37.352Z","url":"https://daily.dev/posts/KKPCuGZ5i#c-leCtNp4fr","author":{"@type":"Person","name":"Eugene Yaremenko","url":"https://daily.dev/eugeneyaremenko","image":"https://avatars.githubusercontent.com/u/1898905?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":5}},{"@type":"Comment","text":"Nice, clean, simple and efficently uses the tools that the JVM gives you. 🙂\nWhat else could one want? That Iberian ham looks delicious (reminds me of our trip to Barcelona). Now I’m hungry. 😆","datePublished":"2026-02-16T19:55:26.919Z","url":"https://daily.dev/posts/KKPCuGZ5i#c-YjgAOYWt0","author":{"@type":"Person","name":"Peter Mrożek","url":"https://daily.dev/petermrozek","image":"https://media.daily.dev/image/upload/s--pBfYX68K--/f_auto/v1769247960/avatars/avatar_Qz65P1nVw3Bu6C5YwaZgA?_a=BAMAMiiu0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3}},{"@type":"Comment","text":"KISS — Keep It Simple and Stupid!","datePublished":"2026-03-05T07:11:19.554Z","url":"https://daily.dev/posts/KKPCuGZ5i#c-HaM4pkLHq","author":{"@type":"Person","name":"Zia","url":"https://daily.dev/zia40","image":"https://media.daily.dev/image/upload/s--D_nKUJkh--/f_auto/v1755777478/avatars/avatar_t0DLA6arFIZDBLmJPQpZH?_a=BAMClqZW0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}}],"isPartOf":{"@type":"WebPage","url":"https://daily.dev/squads/justjava","name":"Just Java"}}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Just Java","item":"https://daily.dev/squads/justjava"},{"@type":"ListItem","position":3,"name":"Stop using 50MB frameworks to manage one single instance of a Logger.\n\n\nMost 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.\n\n\nWe’ve moved from \"Singletons everywhere\" to \"DI frameworks for everything,\" but we’ve forgotten how to actually use the JVM.\n\n\nIn my latest post, I break down:\n\n- The Reality of Failure: Why \"Double-Checked Locking\" is often just a sophisticated way to introduce bugs.\n\n- The \"Resume-Driven Development\" Trap: Why we over-engineer simple patterns just to look smart.\n\n- The 2026 Standard: Why the Enum Singleton remains the only truly bulletproof implementation.\n\n- Testing Myths: Why \"Singletons are hard to test\" is usually a symptom of poor interface design, not the pattern itself.\n\n\nComplexity 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."}]}
```

