Java Bean Bag

  ☕ Have you ever had a Java application just... vanish ? No stack trace. No clear error. Just a core dump or a mysterious hs_err_pid file left behind like a clue from a crime scene. Over the past few weeks, I’ve been wrestling with this. 🧠 I kept asking myself: What really causes a JVM crash ? Is it always the app’s fault? How can I truly diagnose and prevent it? And how do I make sense of that gigantic heap dump file? So I went deep into the internals. Here’s what I found 👇 🔍 Why JVM Crashes (Beyond Just “OOM”) Yes, we all know about OutOfMemoryErrors. But JVM crashes often involve subtle, deeper issues: 🧬 Native Code Issues – JNI calls from Java to C/C++ can corrupt memory if not handled properly 🕸️ Threading Chaos – Deadlocks, race conditions, or blocked critical threads can destabilize the runtime 🗂️ DirectByteBuffer Abuse – Memory allocated outside the heap can escape GC tracking 🧱 Corrupt JVM Installation – Misconfigured JDKs, mixed versions, or...

☕ A Walk Down Memory Lane: My First Bug Nightmare About 9 years ago, as a fresher, I worked on a billing system for a retail application. The system was accessed both from mobile and web UI , and the actual billing logic was written in stored procedures (SQL-based backend). Everything looked fine... until customers started reporting weird issues : 🐛 The Bug: Bills Were Swapping Items! 😱 🧾 Scenario: Two different users generated separate bills around the same time One from Mobile , the other from Web The output bills had mixed-up items — each invoice had products that belonged to the other one! 🧨 🔍 Initial Questions: "Is this a DB issue?" "Are stored procedures broken?" "Race condition in app layer?" Turns out... 🚫 The code calling stored procedures wasn’t thread-safe. There was no synchronized mechanism to ensure each bill transaction was isolated. 🧠 The Root Cause Analysis (RCA): We were calling a shared BillingService.calculat...

👋 Before diving deep into testing, I always assumed: "JUnit is just something you use with @Test… it just works!"   But once I actually started exploring test frameworks in real-world projects, I realized there's so much more behind the scenes. So here’s a blog to clarify the confusion , make it visually digestible , and hopefully save you some debugging hours . Let’s roll! 🧠✨ 🔍 Step 1: What dependencies should I include for JUnit? You may have seen these terms in your build.gradle : testImplementation 'org.junit.jupiter:junit-jupiter:5.10.0' implementation 'com.example:some-library:1.2.3' But wait... what’s the difference? 🤔 ✅ implementation This means: Include the library for both compile time AND runtime . It will be packaged inside the final JAR/WAR. Use it for things your production code needs. 🧪 testImplementation This means: Use it only during test execution . It will NOT be added to the production JAR/WAR. Perfect for JU...

  🧩 Introduction Setting up MongoDB with OIDC authentication in a production-grade Spring Boot app sounds simple — until reality strikes. 😅 This post covers two specific issues I faced when integrating MongoDB v8 with Spring Boot 3.3.6 , and deploying the app via Terraform to Cloud Run . If you’re planning the same, ame, save yourself some debugging time and read on. 👇 🐛 Issue #1: MongoDB Driver Compatibility – “Unsupported authMechanism: MONGODB-OIDC” 🔥 The Problem: After upgrading to MongoDB v8 , my app started throwing this error: Unsupported authMechanism: MONGODB-OIDC Turns out, the default MongoDB driver version (5.0.1) pulled in by Spring Boot 3.3.6 isn’t compatible with MongoDB v8, especially when using OIDC authentication . Turns out, the default MongoDB driver version (5.0.1) pulled in by Spring Boot 3.3.6 isn’t compatible with MongoDB v8, especially when using OIDC authentication . ✅ The Fix: Manually specify compatible driver versions ( 5.2.1 or abo...