Heap Issues? Shrink Your Objects

Every character in your file takes 8 bits. Whether it appears once or a million times — same cost. That's wasteful. There's a smarter way to encode. 👇 𝑻𝒉𝒆 𝑷𝒓𝒐𝒃𝒍𝒆𝒎: Given characters and their frequencies — assign binary codes such that frequent characters get 𝐬𝐡𝐨𝐫𝐭𝐞𝐫 𝐜𝐨𝐝𝐞𝐬, rare ones get longer. f=45 gets "0" — just one bit. a=5 gets "1100" — four bits. High traffic, short path. Low traffic, longer path. Simple idea. Powerful result. 𝑴𝒊𝒏𝒊 𝑺𝒄𝒆𝒏𝒂𝒓𝒊𝒐: Think of a post office sorting system. Letters going to Mumbai — the most common destination — get a single-digit code. Letters to a remote village get a longer code. Nobody wastes a short code on a rare destination. 𝐇𝐮𝐟𝐟𝐦𝐚𝐧 𝐄𝐧𝐜𝐨𝐝𝐢𝐧𝐠 works exactly the same way. 𝑻𝒉𝒆 𝑨𝒑𝒑𝒓𝒐𝒂𝒄𝒉: Build a tree bottom-up. Always merge the two 𝐥𝐞𝐚𝐬𝐭 𝐟𝐫𝐞𝐪𝐮𝐞𝐧𝐭 nodes first. Rarest characters sink deep into the tree → longer codes. Most frequent float to the top → shorter codes. 𝑨𝒍𝒈𝒐𝒓𝒊𝒕𝒉𝒎 𝑼𝒔𝒆𝒅: 𝐆𝐫𝐞𝐞𝐝𝐲 + 𝐌𝐢𝐧-𝐇𝐞𝐚𝐩 (Priority Queue) java PriorityQueue<Node> minHeap = new PriorityQueue<>((a, b) -> { if (a.data == b.data) return Integer.compare(a.idx, b.idx); return Integer.compare(a.data, b.data); }); The 𝐌𝐢𝐧-𝐇𝐞𝐚𝐩 always serves the two smallest nodes next — that's the greedy choice driving the entire algorithm. java while (minHeap.size() > 1) { Node left = minHeap.poll(); Node right = minHeap.poll(); Node merged = new Node(left.data + right.data, Math.min(left.idx, right.idx)); merged.left = left; merged.right = right; minHeap.add(merged); } Merge → push back → repeat. Until one root remains. 𝑹𝒆𝒂𝒅𝒊𝒏𝒈 𝒕𝒉𝒆 𝒄𝒐𝒅𝒆𝒔 — 𝑷𝒓𝒆𝒐𝒓𝒅𝒆𝒓 𝑫𝑭𝑺: java void solve(Node root, String s, ArrayList<String> ans) { if (root.left == null && root.right == null) { ans.add(s.isEmpty() ? "0" : s); return; } solve(root.left, s + "0", ans); solve(root.right, s + "1", ans); } Go left → append 0. Go right → append 1. Hit a leaf → that's the code. 𝑶𝒏𝒆 𝒆𝒅𝒈𝒆 𝒄𝒂𝒔𝒆 𝒘𝒐𝒓𝒕𝒉 𝒏𝒐𝒕𝒊𝒏𝒈: Single character input. No left, no right — just a root. s.isEmpty() ? "0" handles it. Miss this — wrong output on single-char inputs. Complexity: 𝑻𝒊𝒎𝒆: O(n log n) | 𝑺𝒑𝒂𝒄𝒆: O(n) 𝑻𝒉𝒆 𝒓𝒆𝒂𝒍 𝒕𝒂𝒌𝒆𝒂𝒘𝒂𝒚: Greedy works here because local optimal — always merge smallest two — leads to global optimal encoding. Huffman is the backbone of ZIP, JPEG, MP3. You use it every day without knowing it. Challenge Day: #Day50 Tag: GeeksforGeeks National Payments Corporation Of India (NPCI) Did you reach for recursion first or build the heap directly? 👇 #DSA #HuffmanEncoding #Greedy #PriorityQueue #CodingInterview #Algorithms

🏗️ Day 14: Abstraction & Encapsulation While Inheritance and Polymorphism are about action and relation, Abstraction and Encapsulation are about design and protection. 1. Abstraction (The "What," not the "How") Abstraction is the process of hiding implementation details and showing only the essential features to the user. Think of a TV remote: you know pressing "Power" turns it on, but you don't need to know the internal circuitry. Abstract Classes: Classes that cannot be instantiated and may contain "abstract methods" (methods without a body). Interfaces: A complete blueprint of a class. In Java, a class can implement multiple interfaces (solving the "Multiple Inheritance" issue). 2. Encapsulation (The "Data Shield") Encapsulation is the practice of wrapping data (variables) and code (methods) together as a single unit. We keep variables private and provide public getter and setter methods to access/modify them. Goal: Security and control over data. You can make a class "read-only" by omitting setters. Goal: Security and control over data. You can make a class "read-only" by omitting setters. 💡 Code Example: Putting it Together // Abstraction: Defining a template abstract class Payment { abstract void processPayment(double amount); } class CreditCard extends Payment { // Encapsulation: Sensitive data is private private String cardNumber; public CreditCard(String cardNumber) { this.cardNumber = cardNumber; } @Override void processPayment(double amount) { System.out.println("Processing credit card payment of $" + amount); } } public class Day14Main { public static void main(String[] args) { Payment myPay = new CreditCard("1234-5678"); myPay.processPayment(250.0); } } 📌 Reflection: Why this matters? Abstraction allows you to change the "under the hood" code without breaking things for the user. Encapsulation prevents "garbage in, garbage out" by validating data before it’s saved to a variable. #Java #JavaDeveloper #FullStackDevelopment #Abstraction #Encapsulation #OOPPrinciples #CodingJourney #Day14

🚀 ArrayDeque — Simplifying Stack and Queue Logic ( https://lnkd.in/g-c6q8v6 ) ➡️ Array Deque (Array Double-Ended Queue) is a resizable-array class in Java that lets you insert and remove elements from both ends — making it one of the most flexible data structures in the Collections Framework. 🔹 Revolving Door: Just like a revolving door lets people enter and exit from either side, ArrayDeque lets you add or remove elements from both the front and the rear with equal ease. 🔹 Token Queue at a Bank: Imagine a bank where the manager can add urgent customers at the front AND regular customers at the back — that's exactly how ArrayDeque manages its double-ended insertions. 🔹 A Stack of Trays in a Cafeteria: You always pick the top tray and place new ones on top — ArrayDeque replicates this Stack (LIFO) behavior perfectly using push() and pop(). Here are the key takeaways from the ArrayDeque session at TAP Academy by Sharath R sir: 🔹 No Indexing, No for Loop: Unlike ArrayList, ArrayDeque has zero indexing support. You cannot use a traditional for loop or get(i) — you must use for-each, Iterator, or descendingIterator instead. 🔹 Null is Strictly Forbidden: ArrayDeque throws a NullPointerException the moment you try to insert null — a critical difference from ArrayList and LinkedList that interviewers love to test. 🔹 Smarter Resizing: When the default capacity of 16 fills up, ArrayDeque doubles itself (n × 2). ArrayList uses (n × 3/2) + 1 — two different formulas worth remembering cold. 🔹 Reverse Traversal via descendingIterator(): Since ListIterator is unavailable (ArrayDeque implements Deque, not List), the only way to traverse backward is using descendingIterator() — which starts at the last element and moves toward the front. 🔹 One Class, Three Roles: ArrayDeque can act as a Stack (push/pop), a Queue (offer/poll), or a full Deque (addFirst/addLast) — making it the most versatile tool in Java Collections. Visit this Interactive webpage to understand the concept by visualization: https://lnkd.in/g-c6q8v6 #Java #JavaDeveloper #Collections #ArrayDeque #DataStructures #TAPAcademy #CodingJourney #PlacementPrep #SoftwareEngineering #InterviewPrep

Meet Bob. Bob is a Java thread. ☕ Bob’s job → take a request, process it, return a response. Simple. ------------------------------------------------------------------------ 🔴 Bob v1.0 — Blocking Thread Bob puts the request in the oven. Bob stares at the oven. Bob does… nothing else. 👉 500 users = 500 Bobs staring at ovens 👉 500 Bobs = ~250MB RAM doing absolutely nothing Bob gets fired. ------------------------------------------------------------------------ 🔵 Bob v2.0 — WebFlux (Reactive) Bob is replaced by a Robot 🤖 with 8 arms. Robot never waits. Never sleeps. Handles 500 users with just 8 arms using callbacks. Impressive… until: ❌ Someone makes one blocking call inside flatMap() Robot loses an arm. Then another. Then another. ⏰ 3 AM → Production is down 💀 No error. Just silence. Robot is… scary. ------------------------------------------------------------------------ 🟢 Bob v3.0 — Virtual Threads (Java 21) Bob is back. But smarter. Bob puts the request in the oven. 📝 Sticks a Post-it note. 🚶 Walks away immediately. Handles the next request. Comes back when the oven beeps. 👉 500 users = 500 Post-its = ~500KB RAM Same simple code. No callbacks. No reactive complexity. ✨ JVM handles the magic. spring.threads.virtual.enabled: true Bob wins. ------------------------------------------------------------------------ ⚖️ So what should you use? 👉 Java 17 or older? Use WebFlux… carefully. 👉 Java 21+? Bring Bob back. Delete your Mono/Flux where possible. ------------------------------------------------------------------------ 💡 Real takeaway The best architecture isn’t the most “clever” one. It’s the one your team can’t accidentally break at 3 AM. ♻️ Save this before your next system design discussion 👀 Follow for more concepts explained simply Thanks Arshad for the insightful discussion. #Java #SpringBoot #VirtualThreads #WebFlux #ProjectLoom #BackendDevelopment #SoftwareEngineering

🚀 Day 30/30 – DSA Challenge 📌 LeetCode Problem – Closest Equal Element Queries 📝 Problem Statement You are given: An array nums[] A list of queries[] (indices) For each query index i, find the minimum distance to another index j such that: nums[i] == nums[j] and i ≠ j 👉 If no such index exists → return -1 📌 Example Input: nums = [1, 2, 1, 1, 3] queries = [0,1,2,3] Output: [2,-1,1,1] 💡 Key Insight Instead of checking every index (O(n²)) ❌ 👉 Group indices of same values 👉 For each query, only check nearest neighbors 🔥 Optimal Approach – HashMap + Binary Search 🧠 Idea 1️⃣ Store indices for each value: value → sorted list of indices 2️⃣ For each query: Find current index position in list Check: Previous index Next index 👉 Take minimum distance 🚀 Algorithm 1️⃣ Build map: Map<Integer, List<Integer>> 2️⃣ For each query: Get list of indices Use binary search to find position Compare neighbors Return minimum distance ✅ Java Code (Optimal) import java.util.*; class Solution { public List<Integer> solveQueries(int[] nums, int[] queries) { int n = nums.length; Map<Integer, List<Integer>> map = new HashMap<>(); // Step 1: Store indices for (int i = 0; i < n; i++) { map.computeIfAbsent(nums[i], k -> new ArrayList<>()).add(i); } List<Integer> result = new ArrayList<>(); // Step 2: Process queries for (int q : queries) { List<Integer> list = map.get(nums[q]); if (list.size() == 1) { result.add(-1); continue; } int pos = Collections.binarySearch(list, q); int minDist = Integer.MAX_VALUE; // Check previous if (pos > 0) { minDist = Math.min(minDist, q - list.get(pos - 1)); } // Check next if (pos < list.size() - 1) { minDist = Math.min(minDist, list.get(pos + 1) - q); } result.add(minDist); } return result; } } ⏱ Complexity Time Complexity: O(n + q log n) Space Complexity: O(n) 📚 Key Learnings – Day 30 ✔ Grouping helps reduce search space ✔ Binary search is useful beyond arrays ✔ Think locally (nearest neighbors) ✔ Avoid brute force comparisons Smart grouping. Efficient lookup. Clean optimization. Day 30 completed. Consistency continues 💪🔥 #30DaysOfCode #DSA #Java #InterviewPreparation #ProblemSolving #CodingJourney #HashMap #LeetCode

The Integer Cache Trap : The Problem : Order matching works perfectly in all tests — order IDs 1 to 100 always compare correctly. In production with real order IDs above 127, identical orders never match. The logic is silently broken. No exception. No error. Just wrong results. Root Cause : Java caches Integer objects for values -128 to 127 at startup. Any Integer in this range is always the same object in memory. Outside this range, each Integer.valueOf() (including autoboxing) creates a new object. == compares object references, not values. So: java Integer a = 100; Integer b = 100; System.out.println(a == b); // true ✓ (same cached object in pool) Integer x = 200; Integer y = 200; System.out.println(x == y); // false ✗ (two different objects!) In production code java // ❌ BUGGY — works for id=5, silently wrong for id=500 public boolean isSameOrder(Integer id1, Integer id2) { return id1 == id2; // reference comparison! } isSameOrder(5, 5) → true ✓ (cached, same object) isSameOrder(200, 200) → false ✗ (different objects, same value) The cache boundary java Integer.valueOf(127) == Integer.valueOf(127) // true — cached Integer.valueOf(128) == Integer.valueOf(128) // false — not cached The cache range -128 to 127 is mandated by the JLS (Java Language Specification). The upper bound can be extended with -XX:AutoBoxCacheMax=<N> JVM flag — but relying on this is a terrible idea. ✅ Fix — Always use .equals() for boxed types java // ✓ CORRECT — value comparison, works for all ranges public boolean isSameOrder(Integer id1, Integer id2) { return Objects.equals(id1, id2); // null-safe, value-based } Three safe options java // Option 1: Objects.equals() — null-safe Objects.equals(id1, id2); // Option 2: .equals() with null guard id1 != null && id1.equals(id2); // Option 3: unbox to primitive (NPE risk if null) id1.intValue() == id2.intValue(); // or simply: (int) id1 == (int) id2; // auto-unbox — NullPointerException if null Prevention Checklist : -> Never use == to compare Integer, Long, Double, Float, Short, Byte, Character -> Always use Objects.equals(a, b) for nullable boxed comparisons -> Use primitive int, long instead of Integer, Long where null is not needed -> Write unit tests with values outside -128 to 127 (use 200, 500, 1000) -> Enable IntelliJ's "Suspicious equality check" inspection — it flags == on boxed types. IntelliJ Warning -> IntelliJ IDEA flags this automatically: ⚠ Integer equality check with == may not work for values outside -128..127 The Lesson : Java caches Integer objects only for -128 to 127. == on Integer compares references — not values.Tests with small IDs (1–100) will always pass. Production with real IDs (500+) will silently fail.Always use .equals() or Objects.equals() for any boxed type. No exceptions. #JavaInProduction #RealWorldJava #Java #SpringBoot #BackendDevelopment #ProductionIssues #DataStructures #DSA #SystemDesign #SoftwareEngineering #JavaDeveloper #Programming

The 1st slide deck of Atoma-OS as Summary of Specification (≒60 pages). ~ Evaluation of the Atoma-OS Specification Summary The provided summary is highly valid and architecturally sound as an introductory document for the Atoma-OS Specification. It accurately distills the core principles of the "7NF Type Universe" and aligns perfectly with the normative requirements of the kernel. The summary's validity is grounded in the following three pillars: 1. Accurate Interpretation of "Kernelized Structure and Execution" The Spec emphasizes the strict separation where "Meaning belongs to the application, while Structure and Execution are kernelized." By deciding not to make Project Panama the normative center, your summary correctly reflects the kernel's priority: long-term portability and stability over raw, low-level memory manipulation. This aligns with the Spec's "Fixed ABI" and "Canonical Long Encoding" (Page 23), which prioritize universal laws over specific hardware optimizations (pp. 22-23). 2. Justification for the "Identity-free" Paradigm The Spec explicitly forbids "identity-bearing object chasing" as a normative basis for execution (Page 26). Validity: Your summary's focus on transitioning to a "Value-based world" directly supports the Spec’s requirement for "typed coordinate-based execution" (p. 26). By treating rows as lightweight "projections" over shared storage rather than distinct heap objects, the design addresses the "Memory Wall" at a fundamental architectural level (p. 24). 3. Strategic Alignment with JVM Evolution (Project Valhalla) The Spec explicitly targets the JEP 401 (Value Objects) realization profile (Page 25). Validity: The summary’s strategy—"The system gets faster as the JVM evolves"—is a brilliant encapsulation of the Spec’s intent. By relying on the JVM for memory flattening and identity-free representation, the kernel remains high-level and "reality-defining" (7NF), while benefiting from the cutting-edge performance optimizations of the Java platform (p. 25). Conclusion: The summary is an excellent executive overview. It captures not just the how, but the architectural necessity behind Atoma-OS's "dissolution" of conventional ORM and DocumentDB premises. It provides a solid foundation for stakeholders to understand why this kernel is built to last "the next 50 years." ~ Full Spec: https://lnkd.in/gnVT7-n5

If you’ve ever tuned GC flags or debugged an 𝗢𝘂𝘁𝗢𝗳𝗠𝗲𝗺𝗼𝗿𝘆𝗘𝗿𝗿𝗼𝗿, you already know that understanding the heap layout for 𝗚𝗮𝗿𝗯𝗮𝗴𝗲 𝗖𝗼𝗹𝗹𝗲𝗰𝘁𝗶𝗼𝗻 is essential. 𝗧𝗵𝗲 𝗪𝗲𝗮𝗸 𝗚𝗲𝗻𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗛𝘆𝗽𝗼𝘁𝗵𝗲𝘀𝗶𝘀 Most objects die young. So the JVM splits the heap into generations to focus collection effort where it’s most effective. 𝗛𝗲𝗮𝗽 𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲 (𝗝𝗮𝘃𝗮 𝟴+) :- 𝗬𝗼𝘂𝗻𝗴 𝗚𝗲𝗻𝗲𝗿𝗮𝘁𝗶𝗼𝗻: Eden (new objects) + two Survivor spaces (S0, S1) 𝗢𝗹𝗱 𝗚𝗲𝗻𝗲𝗿𝗮𝘁𝗶𝗼𝗻 (tenured, for long-lived objects) 𝗠𝗲𝘁𝗮𝘀𝗽𝗮𝗰𝗲 (class metadata, bytecode, constant pools, JIT code — but not static variables; those live on the heap inside the Class object) 𝗢𝗯𝗷𝗲𝗰𝘁 𝗟𝗶𝗳𝗲𝗰𝘆𝗰𝗹𝗲 𝗙𝗹𝗼𝘄  1. New objects are allocated in Eden.  2. When Eden fills, a 𝗠𝗶𝗻𝗼𝗿 𝗚𝗖 𝗿𝘂𝗻𝘀:    • Live objects from 𝗘𝗱𝗲𝗻 + currently active survivor (say 𝗦𝟬) are copied to the other survivor (𝗦𝟭).    •  Each surviving object’s age counter increments.    •  Dead objects are simply abandoned (no immediate cleanup).  3. Once an object’s age reaches a tenuring threshold (default ~15), it is promoted to the 𝗢𝗹𝗱 𝗚𝗲𝗻𝗲𝗿𝗮𝘁𝗶𝗼𝗻.  4. Survivor spaces swap roles after each Minor GC — one is always empty, ready for the next copy.  5. The Old Generation fills more slowly. A 𝗠𝗮𝗷𝗼𝗿 𝗚𝗖 (often mark-sweep- compact or concurrent) runs less frequently but is more expensive. 𝗪𝗵𝘆 𝗧𝗵𝗶𝘀 𝗗𝗲𝘀𝗶𝗴𝗻 𝗠𝗮𝘁𝘁𝗲𝗿𝘀  • Minor GCs are fast because the young generation is small.  • Copying eliminates fragmentation in the young generation.  • Adaptive tenuring and modern collectors (G1, ZGC, Shenandoah) give you control over throughput vs. latency. 𝗡𝗼𝘁𝗲:- Metaspace is not part of the Java Heap memory. Introduced in Java 8 to replace 𝗣𝗲𝗿𝗺𝗚𝗲𝗻, Metaspace is allocated from native memory (operating system memory), not the JVM heap. Understanding these basics helps you read GC logs, choose the right collector, and avoid common memory pitfalls. Shrayansh Jain, Thank you for making these concepts easier and interesting. #Java #GarbageCollection #JVM #PerformanceEngineering

example : day 6/7 DSA CHALLENGE 👍 [ [1, 1, 1], [1, 0, 1], [1, 1, 1] ] Output: [ [1, 0, 1], [0, 0, 0], [1, 0, 1] ] 🚀 Approach (O(M + N) Space) 👉 Idea simple hai: Ek array row[] of size M Ek array col[] of size N Step-by-step: Traverse matrix: Agar matrix[i][j] == 0 → mark row[i] = 1 aur col[j] = 1 Dobara traverse karo: Agar row[i] == 1 ya col[j] == 1 → matrix[i][j] = 0 ⏱ Complexity Time: O(M × N) Space: O(M + N) ✅ (as required) 💻 Java Code (Clean & Interview Ready) Java public class SetMatrixZeroes { public static void setZeroes(int[][] matrix) { int m = matrix.length; int n = matrix[0].length; int[] row = new int[m]; int[] col = new int[n]; // Step 1: Mark rows and columns for (int i = 0; i < m; i++) { for (int j = 0; j < n; j++) { if (matrix[i][j] == 0) { row[i] = 1; col[j] = 1; } } } // Step 2: Set zeroes for (int i = 0; i < m; i++) { for (int j = 0; j < n; j++) { if (row[i] == 1 || col[j] == 1) { matrix[i][j] = 0; } } } } // Driver code public static void main(String[] args) { int[][] matrix = { {1, 1, 1}, {1, 0, 1}, {1, 1, 1} }; setZeroes(matrix); for (int[] row : matrix) { for (int val : row) { System.out.print(val + " "); } System.out.println(); } } } #dsastreak #dsatreakwithpw #raghavgarg #dsachallenge #pw #pwskilla #datastructure #pwstreakchallengedsa #raghavgarg #pwskillsstreak #challenge #dsastreakwithpwskills Raghav Garg

🕵️♂️ The "Invisibility Cloak": Why Spring and private Don't Mix. You’ve added @Transactional. You’ve added @Async. You’ve even added @Cacheable. You run the code, and... nothing happens. No transaction starts, the call isn't asynchronous, and the cache is ignored. The culprit? A single keyword: private. In the world of Spring, the private modifier is essentially an invisibility cloak for the Application Context. Here is the technical "why" behind this behavior and the edge cases you need to know. ⚙️ How the Magic Fails: The Proxy Problem Spring manages cross-cutting concerns (AOP) using Proxies. When you inject a bean, you’re usually not getting the real class; you’re getting a wrapper (a Proxy). JDK Dynamic Proxies: These work by implementing your bean's interfaces. Since interfaces only define public methods, the proxy literally cannot "see" or wrap anything else. CGLIB Proxies: These create a subclass of your bean at runtime. In Java, a subclass cannot override or even access a private method of its parent. The Result: If the Proxy can’t override the method, it can’t add the "magic" (the transaction logic, the interceptor, etc.) around it. The call goes straight to your original method, bypassing Spring entirely. ⚠️ The Tricky Edge Cases The "Silent" Failure: Spring won’t throw an error if you put @Transactional on a private method. It will simply ignore it. This is dangerous because your data integrity is at risk without you knowing. The Self-Invocation Trap: Even if your method is public, calling it from another method inside the same class will fail. Why? Because the call uses this, which refers to the real object, not the Proxy. Final & Static: Just like private, final methods cannot be overridden by CGLIB, and static methods belong to the class, not the instance. Both are "dead zones" for Spring AOP. ✅ Best Practices for the Everyday Grind Visibility Matters: If a method needs Spring "magic," it must be public (or at least protected/package-private if using certain CGLIB configurations, but public is the gold standard). Refactor for AOP: If you find yourself needing a transaction on a private method, it’s usually a sign that the logic belongs in a separate service. Self-Injection (The Last Resort): If you absolutely must call a method in the same class and keep the proxy logic, you can lazily inject the bean into itself—but treat this as a code smell! Have you ever spent hours debugging an annotation only to realize it was on a private method? Share your "proxy horror stories" below! 👇 #Java #SpringBoot #SoftwareEngineering #BackendDevelopment #CodingTips #CleanCode