Java Spring Boot Roadmap — Zero to Job-Ready

Fixing Spring Boot OutOfMemoryError in Docker (Paketo Buildpacks Edition) While deploying a set of Spring Boot microservices, I ran into a surprising issue: Terminating due to java.lang.OutOfMemoryError: Java heap space At first glance, this didn’t make sense — each container had 700 MB memory allocated. That should be more than enough… right? Not quite. 🔍 Root Cause The application was built using Paketo Buildpacks, which automatically calculate JVM memory settings. Here’s what the JVM ended up with: Total Memory: 700M -Xmx3086K (≈ 3 MB heap!) MaxMetaspaceSize ≈ 200 MB ReservedCodeCacheSize = 240 MB Thread Count = 250 (~250 MB stack) 👉 Result: The heap (where application objects live) was reduced to ~3 MB, causing immediate crashes. ⚠️ Why This Happens Paketo distributes memory across: Heap (-Xmx) Metaspace Code cache Thread stacks With: High thread count (250 by default) Large code cache (240 MB) Significant metaspace (~200 MB) 👉 There’s almost nothing left for the heap. ✅ The Fix The solution is to override JVM memory allocation explicitly. 1. Control Heap Size JAVA_TOOL_OPTIONS="-Xms256m -Xmx512m -XX:MaxMetaspaceSize=128m -XX:+UseG1GC" 2. Reduce Thread Count BPL_JVM_THREAD_COUNT=50 This alone frees hundreds of MBs. 3. Apply in Docker Compose environment: - JAVA_TOOL_OPTIONS=-Xms256m -Xmx512m -XX:MaxMetaspaceSize=128m -XX:+UseG1GC - BPL_JVM_THREAD_COUNT=50 🧠 Smarter Resource Allocation Not all microservices need the same memory. Service | Memory Limit | Heap | --------------------------------------------------------- API Gateway | 512 MB | 256 MB | --------------------------------------------------------- Auth Service | 700 MB | 512 MB | --------------------------------------------------------- Payment Service | 700 MB | 512 MB | --------------------------------------------------------- Catalog Service | 512 MB | 256 MB | --------------------------------------------------------- ⚡ Optional Optimization Enable lazy initialization to reduce startup memory pressure: SPRING_MAIN_LAZY_INITIALIZATION=true ✅ Expected Result After applying the fix, JVM logs should show: -Xmx256M or higher NOT: -Xmx3M 💡 Key Takeaway When running Spring Boot in containers: Memory limits ≠ usable heap If you don’t explicitly configure JVM memory, tools like Paketo may allocate it in unexpected ways — leading to crashes even when plenty of memory is available. 🚀 Final Thought In microservices architectures, each service runs its own JVM. Without proper tuning, memory usage scales quickly and unpredictably. 👉 JVM tuning is not optional — it’s part of production readiness. #SpringBoot #Docker #Microservices #Java #DevOps #Kubernetes #BackendEngineering

As a Java/Kotlin developer, I've always wondered why Golang became one of the most widely used languages in backend solutions. After doing some hands-on work, here are my impressions: Simplicity: few keywords, no traditional exception handling, built-in tooling and standard library. Predictable performance: low-latency GC, no JVM, no separate runtime — cold start is virtually instant with low overhead. Native concurrency (Goroutines): much like Kotlin's Coroutines, Goroutines are extremely lightweight (just a few KB of initial stack). I ran the same algorithm in Java 21, Go, and C++17 on an AWS Lambda (1769 MB, us-east-1). The results surprised me. 📊 Benchmark: SHA-256 chain (500K), allocation (1M objects), matrix multiply 300×300 (8 threads), and JSON serde (10K records). Results: 🐹 Go (go1.26) → Cold start: 59ms → Total time: 281ms → Memory: 28 MB → Billed: 343ms ☕ Java 21 (Corretto) → Cold start: 757ms → Total time: 986ms → Memory: 143 MB → Billed: 1766ms ⚡ C++17 (custom runtime) → Cold start: 27ms → Total time: 464ms → Memory: 50 MB → Billed: 494ms Key takeaways: 1. Go won overall. 3.5x faster than Java, 1.7x faster than C++. Go's runtime has an Assembly-optimized SHA-256 implementation (SIMD) — it outperformed C++'s OpenSSL. 2. Allocation: Go handled 1M objects in 0.35ms. Java took 26.9ms. C++ came in at ~0ms (the compiler optimized the entire loop away). 3. JSON is Java's Achilles' heel. 306ms for 10K records with Jackson — 31% of total execution time. Go with native encoding/json: 52ms. 4. Cold start remains the biggest differentiator. Java 757ms vs Go 59ms vs C++ 27ms. SnapStart helps, but it doesn't close the gap entirely. Would I migrate a system with complex domain logic from Java to Golang? NO. Go is built for high-concurrency microservices, CLIs, proxies/API gateways, infrastructure tooling, and even image processing pipelines. Go's pointers also make the transition easier for those coming from C++. All the code and benchmark setup are in my repository (link in the comments). #aws #lambda #golang #java #cpp #serverless #benchmark #cloudnative #backend

☕ How Java Actually Works — from source code to running application. Most developers use Java daily without knowing this. After 10+ years of building enterprise Java systems, understanding what happens under the hood has made me a dramatically better engineer. Let me walk through every stage 👇 📝 Stage 1 — Source You write Java code in your editor — IntelliJ, VS Code, Eclipse. That code is saved as a .java source file. Human-readable. Platform-specific to nothing yet. This is where it all begins. ⚙️ Stage 2 — Compile The Java Compiler (javac) transforms your .java source file into Bytecode — a .class file. This is the magic of Java's "Write Once Run Anywhere" promise. The bytecode is not native machine code — it's an intermediate language that any JVM on any platform can understand. Windows, Linux, Mac — same bytecode runs everywhere. 📦 Stage 3 — Artifacts The compiled .class files are packaged into artifacts — JAR files, modules, or classpath entries. In enterprise projects I've shipped across Bank of America and United Health, Maven and Gradle manage this — producing versioned artifacts deployed to Nexus or AWS CodeArtifact repositories. 📂 Stage 4 — Load The Class Loader loads .class files, JARs, and modules into the Java Runtime Environment at runtime. Three built-in class loaders handle this — Bootstrap, Extension, and Application. Understanding class loading has helped me debug NoClassDefFoundError and ClassNotFoundException in production more times than I can count. 🔍 JVM — Verify Before executing a single instruction, the JVM Verifier checks the bytecode for correctness and security violations. No invalid memory access. No type violations. No corrupted bytecode. This is one reason Java is inherently safer than languages with direct memory management. ▶️ Stage 5 — Execute — Interpreter + JIT Compiler This is where performance gets interesting. The JVM first Interprets bytecode line by line — fast startup, moderate throughput. Simultaneously it monitors execution and identifies hot paths — code that runs frequently. Those hot paths are handed to the JIT (Just-In-Time) Compiler which compiles them to native machine code stored in the Code Cache. 🏃 Stage 6 — Run The JVM runs a mix of interpreted bytecode and JIT-compiled native code — balancing startup speed with peak performance. Standard Libraries (java.* / jdk.*) provide everything from collections to networking to I/O throughout execution. #Java #c2c #opentowork #c2h #JVM #CoreJava #JavaDeveloper #SpringBoot #JVMPerformance #FullStackDeveloper #OpenToWork #BackendDeveloper #Java17 #HiringNow #EnterpriseJava #SoftwareEngineer #JITCompiler #JavaInterview #CloudNative #Microservices #TechEducation #Programming

For years, we’ve accepted that running Java applications meant running on the JVM. But what if that assumption no longer holds? I just published a new article exploring how Spring Boot applications can be compiled into native executables using GraalVM Native Image—dramatically reducing startup time and memory usage, which is especially relevant in cloud and serverless environments. Native images are built ahead-of-time into standalone binaries, eliminating the need for a JVM at runtime and enabling faster startup and lower resource consumption. This is not just about performance—it’s about rethinking how we build and run Java in a world where every millisecond and megabyte has a cost. In the article, I walk through: - The real problem behind Java resource consumption in the cloud - The trade-offs between JVM (JIT) and AOT compilation - How Spring Boot AOT makes native compilation viable - A minimal working example using Gradle and modern Java If you’re building microservices, running in containers, or exploring serverless with Java, this might change how you think about your architecture. 👉 Read the full article: https://lnkd.in/dcAvBVTz Curious to hear your thoughts—are native images something you’re already using or still evaluating?

This is good news, but at the same time gives me the feeling that Spring Boot is playing catch up with Quarkus. Developers are the winners in all this, because they get to finally enjoy native images in their Spring Boot projects.

Hi all, Recently attended a few Java Backend interviews and wanted to share some of the questions I encountered. Sharing this in case it helps someone preparing 👇 🔹 Microservices & System Design 1.What is cascading in microservices? 2.How do you handle cascading failures in distributed systems? 3.Service A sends a request → Service B processes payment using Apache Kafka     👉 What happens if Service B is down for 30 minutes?     👉 How does Kafka ensure reliability in this scenario? 4.How can Kafka be handled efficiently to avoid message loss or system issues? 🔹 Design Principles (SOLID) 5. Given the below scenario, which SOLID principle is violated? How would you fix it? interface Worker { void work(); void eat(); void sleep(); } class Human implements Worker { public void work() {} public void eat() {} public void sleep() {} } class Robot implements Worker { public void work() {} public void eat() {} // ❌ Not applicable public void sleep() {} // ❌ Not applicable } 👉 Which principle would you apply and how would you redesign this? 6. Explain the Open/Closed Principle with a real-world example 🔹 Backend & Tools 7. What are some real-world use cases of Docker in your daily work? 8. What is the default port number of Redis? 9. How do you handle and manage Redis in a real application? 🔹 Spring / Spring Boot 10. How do you read values from properties files in Spring Boot? 11. How do you implement custom exception handling (e.g., 401 / 403 errors)? 12. What is the difference between Spring and Spring Boot? What are the advantages of Spring Boot? 13. Explain Dependency Injection (DI) and Inversion of Control (IoC) 🔹 Java Core 14. Write a program to count repeated characters in a given string 15. Difference between Comparable and Comparator 🔹 Practical / Real-World 16. How do you integrate your application with GitHub or Bitbucket? 17. How do you test your application (unit, integration, etc.)? 18. Your code builds successfully in local and you push it to GitHub/Bitbucket—where do you verify if the build was successful? --- These questions covered both core concepts and real-world scenarios. --Open to new opportunities as a Java Backend Developer (Immediate Joiner). Would appreciate any referrals or leads. #Java #SpringBoot #Microservices #Kafka #Redis #Docker #BackendDevelopment #InterviewPreparation #SoftwareEngineering #DevOps #JavaDeveloper

**Level up your Java Spring Boot Skills: Essential Concepts for Production-Grade Systems 🚀** Moving beyond simple CRUD APIs is about understanding and implementing distributed system principles. 1. 🛡️ Fault Tolerance with Resilience4j: Implement patterns like circuit breaking, retries, and rate limiting to build resilient microservices that don't cascade when dependencies fail. 2. 🕵️♂️ Distributed Tracing using Spring Cloud Sleuth & Zipkin: Trace requests across multiple services to simplify debugging and pinpoint latency issues in a microservices environment. 3. 🏎️ Reactive Programming with Project Reactor: Embrace non-blocking, asynchronous processing for highly-scalable, responsive applications. 4. 📊 Metrics & Monitoring with Micrometer: Instrument your services to get real-time insights into health and performance for effective production management. Prometheus: Trigger alerts based on P95 metrics. 5. 📩 Event Streaming with Spring Kafka: Design durable, fault-tolerant, and dynamic event-driven architectures. Moving beyond basic producers/consumers to master consistency with The Transactional Outbox Pattern: Ensuring your database updates and message sends are atomic to avoid data drift. Idempotency: Designing your consumers to handle duplicate messages without side effects using unique request IDs or Bloom filters on keys and enforcing transactions (commit/rollback) 6. ⚙️ Configuration Management using Spring Cloud Config: Use centralized configuration management with version control and hot-refresh capabilities. 7. 🔭 Observability with OpenTelemetry: Leverage a unified approach to tracing and metrics to proactively detect and troubleshoot failures. 8. 💾 Caching & Locking with Redis & Spring Data Redis: Implement high-availability caching and manage concurrency with distributed locking for improved performance and data consistency. Write-Through vs. Write-Behind: Knowing when to prioritize immediate consistency over low latency. Distributed Locking: Using Redis to prevent "thundering herd" problems in high-traffic environments. 9. 🔒 Secrets Management using Vault by HashiCorp: Securely manage credentials, API keys, and other secrets for your distributed applications. 10. 📦 Containerization with Docker: Ensure easy deployment and scalability by containerizing your Spring Boot applications. Dockerhub register an image for Kubernetes Pod Auto scaling 11. Modern Concurrency Models 🧵 Virtual Threads: Moving away from heavy OS-thread-per-request models to lightweight concurrency along with asynchronous calls with completablefutures, semaphores, reentrant locks, countdown latch, thread pool, and how this impacts your blocking I/O operations is a game-changer for performance tuning. 12. The AI-Driven Backend 🤖 Support LLMs: Manage session state and Log context for AI agents and integrating vector-based search or RAG architectures into your Spring services for seamless SDLC. #SpringBoot #Microservices #Kafka

🚀 Unlocking Docker BuildKit Features in Java: A Deep Dive into API Integration  ⚠️ The Challenge  When working with Docker builds in Java applications, a common issue arises: the popular 𝐝𝐨𝐜𝐤𝐞𝐫-𝐣𝐚𝐯𝐚 library doesn't support BuildKit's advanced features like cache mounts (--mount=type=cache). These features require the version=2 query parameter in Docker's API, but docker-java only uses API versions as path components.  🔍 The Investigation  𝐖𝐡𝐚𝐭 𝐖𝐚𝐬 𝐃𝐢𝐬𝐜𝐨𝐯𝐞𝐫𝐞𝐝:  - Docker API endpoint: /v1.47/build?version=2 enables BuildKit backend  - version=1 = Legacy builder (fails with BuildKit features)  - version=2 = BuildKit backend (supports advanced features)  - docker-java library missing this crucial parameter  💡 The Solution  𝐈𝐦𝐩𝐥𝐞𝐦𝐞𝐧𝐭𝐚𝐭𝐢𝐨𝐧 𝐀𝐩𝐩𝐫𝐨𝐚𝐜𝐡:  1. 𝐌𝐨𝐝𝐢𝐟𝐲 BuildImageCmd interface to add withBuildKitVersion() method  2. 𝐔𝐩𝐝𝐚𝐭𝐞 BuildImageCmdExec to include version query parameter  3. 𝐄𝐧𝐡𝐚𝐧𝐜𝐞 DefaultDockerClientConfig with BuildKit version support  4. 𝐁𝐮𝐢𝐥𝐝 𝐜𝐮𝐬𝐭𝐨𝐦 𝐉𝐀𝐑 and integrate with bmuschko Gradle plugin  🔬 Key Technical Insights  𝐁𝐮𝐢𝐥𝐝𝐊𝐢𝐭 𝐯𝐬 𝐋𝐞𝐠𝐚𝐜𝐲 𝐂𝐨𝐦𝐩𝐚𝐫𝐢𝐬𝐨𝐧:  # Legacy (version=1) - FAILS with cache mounts  curl "http://localhost/v1.47/build?version=1&..."  # Error: "the --mount option requires BuildKit"  # BuildKit (version=2) - SUCCESS    curl "http://localhost/v1.47/build?version=2&..."  # Rich BuildKit trace output, cache mounts work!  𝐆𝐫𝐚𝐝𝐥𝐞 𝐈𝐧𝐭𝐞𝐠𝐫𝐚𝐭𝐢𝐨𝐧:   buildscript {     repositories {       mavenLocal() // Custom docker-java version     }     dependencies {       classpath 'com.github.docker-java:docker-java-core:3.4.0-buildkit'     }   }   task buildWithBuildKit(type: DockerBuildImage) {     dockerCommand.withBuildKitVersion("2") // Enable BuildKit!   }  📈 The Impact  𝐑𝐞𝐬𝐮𝐥𝐭𝐬:  - ✅ 𝐁𝐚𝐜𝐤𝐰𝐚𝐫𝐝𝐬 𝐂𝐨𝐦𝐩𝐚𝐭𝐢𝐛𝐥𝐞: Existing builds continue working  - ⚡ 𝐎𝐩𝐭-𝐢𝐧 𝐁𝐮𝐢𝐥𝐝𝐊𝐢𝐭: Enable advanced features when needed  - 🏃♂️ 𝐏𝐞𝐫𝐟𝐨𝐫𝐦𝐚𝐧𝐜𝐞 𝐁𝐨𝐨𝐬𝐭: BuildKit's parallel processing & caching  - 🔮 𝐅𝐮𝐭𝐮𝐫𝐞-𝐑𝐞𝐚𝐝𝐲: Supports latest Docker build innovations  🎓 Lessons Learned  𝐊𝐞𝐲 𝐓𝐚𝐤𝐞𝐚𝐰𝐚𝐲𝐬:  - 📚 Always check API documentation for missing query parameters  - 🍎 GNU tar vs BSD tar matters for Docker builds on macOS (xattr issues!)  - 🕵️ Direct API exploration reveals gaps in wrapper libraries  - 🔧 Local modifications can bridge functionality gaps in open source libraries  Have you encountered similar gaps between wrapper libraries and underlying APIs? What approaches worked best for your use case? 💭 #Docker #ContainerDevelopment #BuildKit

Every Java developer has confidently used these three terms. JVM. JDK. JRE. Most of them have no idea what the difference actually is. (Don't worry. Neither did I when I started.) Let's go back to the promise Java made in 1995 -> "Write Once, Run Anywhere." Sounds magical. But HOW? How does the same code run on Windows, Mac, and Linux without changing a single line? The answer is the JVM -> Java Virtual Machine. When you write Java code, it doesn't become machine code directly. It first becomes something called Bytecode. Bytecode is like a middle language not human readable, not machine readable either. It's in between. Now here's the trick. Every operating system has its own JVM installed. And the JVM's only job is to take that Bytecode and translate it into instructions YOUR machine understands. Windows JVM speaks Windows. Mac JVM speaks Mac. Linux JVM speaks Linux. But your code? Your code never changes. That's the magic. That's "Write Once, Run Anywhere." Okay. So where do JDK and JRE fit in? Think of it like a kitchen. JVM -> the stove. It runs and executes things. JRE (Java Runtime Environment) -> the full kitchen. The stove + everything needed to actually cook. Libraries, tools, the works. If you just want to RUN a Java program, JRE is enough. JDK (Java Development Kit) -> the kitchen PLUS a recipe book, knife set, and a chef's manual. Everything in JRE plus the tools to actually WRITE and BUILD Java programs. Compilers. Debuggers. The full package. So -> -> User who just runs your app? They need JRE. -> You, the developer building it? You need JDK. -> Under all of it, quietly doing the real work? JVM. Here's why this matters more than you think. Ever seen this error? "Java is not recognised as an internal or external command" That's your machine saying I have no idea what Java is. You never gave me a JRE or JDK. Understanding JVM, JDK, and JRE isn't just theory. It saves you hours of debugging confusion. If you read this far... This is Post #2 of my Java series -> the story behind the code. Next up: How Java actually compiles and runs your code step by step, from the line you write to the output on your screen. Follow SHABANA FATHIMA so you don't miss it. JVM, JDK, JRE did this finally click for you, or were you already a pro? 👇 #Java #JavaSeries #JVM #JDK #JRE #SoftwareEngineering #Programming #LearnToCode #BackendDevelopment #TechHistory

Day 9 — #100DaysOfCode  today felt different. This was not just learning Java syntax. This was real world stuff. ☕ I set up Maven on my local machine and on an AWS cloud instance. And honestly, the moment my code ran on a cloud server — it felt like a big step forward. Maven Archetype Generate Command The command in the image is used to generate a new Maven project using the maven-archetype-quickstart template. Here is the exact command: 1 .Install Maven on AWS sudo yum update -y sudo yum install maven -y  mvn --version 2. create maven project mvn archetype:generate -DgroupId=com.edu -DartifactId=edu-app -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4 -DinteractiveMode=false Explanation of parameters: -DgroupId=com.edu→ The group ID for your project (usually your domain in reverse). -DartifactId=edu-app → The name of your project. -DarchetypeArtifactId=maven-archetype-quickstart → The archetype template to use. -DarchetypeVersion=1.0 → The version of the archetype. -DinteractiveMode=false → Runs the command without prompting for input. 3.Change folder -cd edu-app 4. run project -mvn compile -mvn exec:java -Dexec.mainClass="com.edu.App" Here is what I did today: Maven — I finally understand why every Java project uses it. Before Maven, you had to manually download every library your project needed. Maven does that for you automatically. You just write what you need in one file (pom.xml) and Maven handles the rest. It also compiles your code, runs tests, and packages everything into a JAR file — all with simple commands. AWS — I created an account, launched an EC2 instance (basically a computer in the cloud), connected to it from my terminal, and installed Maven on it. The idea that my code can run on a server somewhere in the world — not just on my laptop — is a completely different feeling. Some commands I used today: mvn --version — check if Maven is installed mvn compile — compile the project mvn package — build a JAR file mvn clean — delete old build files mvn test — run all tests 9 days in. Every day the topics get more real and more exciting. Day 1 ✅ Day 2 ✅ Day 3 ✅ Day 4 ✅ Day 5 ✅ Day 6 ✅ Day 7 ✅ Day 8 ✅ Day 9 ✅ If you work with Maven or AWS and have tips for a beginner — please share! Would love to connect. 🙏 #Java #Maven #AWS #EC2 #CloudComputing #100DaysOfCode #JavaDeveloper #LearningInPublic #BackendDevelopment #DevOps