Sorting by Bit Patterns: A Powerful Technique

Solved a classic DSA problem today – Valid Anagram Given two strings, the challenge is to check whether they are anagrams of each other. Day - 1 Input: s = "listen", t = "silent" Output: true Input: s = "hello", t = "world" Output: false 🔹 Approach 1 (Best - O(n) Time, O(1) Space) 👉 Character frequency count use karo (array of size 26) Code (Java) Java public class ValidAnagram { public static boolean isAnagram(String s, String t) { if (s.length() != t.length()) return false; int[] count = new int[26]; for (int i = 0; i < s.length(); i++) { count[s.charAt(i) - 'a']++; count[t.charAt(i) - 'a']--; } for (int c : count) { if (c != 0) return false; } return true; } public static void main(String[] args) { System.out.println(isAnagram("listen", "silent")); // true System.out.println(isAnagram("hello", "world")); // false } } ✅ Time Complexity: O(n) ✅ Space Complexity: O(1) (fixed 26 size array) 🔹 Approach 2 (Normal - Sorting Method) 👉 Dono strings ko sort karo, fir compare karo Code Java import java.util.Arrays; public class ValidAnagramSort { public static boolean isAnagram(String s, String t) { if (s.length() != t.length()) return false; char[] a = s.toCharArray(); char[] b = t.toCharArray(); Arrays.sort(a); Arrays.sort(b); return Arrays.equals(a, b); } } ⏱ Time Complexity: O(n log n) 💾 Space Complexity: O(n) #Raghavgarg #day1 #streak #raghav #DSASTREAKWITHPWSKILLS #RAGHAV #dsa #pw #pwskills #pw #pwskills #raghavgarg Raghav Garg

🚀 Java Deep dive : Why does Java have both "int" and "Integer"? At first glance, both store numbers. But in reality — they solve completely different problems. ------ ⚡ "int" → Speed - Primitive type - Stores raw value - Fast & memory efficient - ❌ No null - ❌ No methods 👉 Best for: loops, calculations, performance-critical code --- 🧠 "Integer" → Flexibility - Wrapper class (object) - Can store "null" - Supports utility methods - Works with Collections 👉 Best for: APIs, DB, frameworks, real-world applications --- 🔥 Why Java needed "Integer" Because primitives alone weren’t enough: ✔ Collections require objects ✔ Null handling is essential (DB/API cases) ✔ Utility methods simplify operations ✔ Autoboxing bridges "int" ↔ "Integer" seamlessly --- ⚠️ Interview Trap (Must Know) "Integer" comparison using "==" can break your logic: - Works for -128 to 127 (cached) - Fails outside that range 👉 Always use ".equals()" for comparison --- 🧠 When to use what? ✔ Use "int" → when performance matters ✔ Use "Integer" → when flexibility is needed --- 💬 Comment “JAVA” if you want more such interview-ready concepts 🔗 Open to connect with Backend / Java / Data folks Follow Surya Mahesh Kolisetty for more such backend deep dives. #Java #SystemDesign #InterviewPrep #BackendDeepDive #Cfbr #Connections #SpringBoot #Backend #InterviewPrep #Programming

I always thought JVM just "runs Java code." Today I went deeper. And what I found was actually fascinating. 🧵 Here's what actually happens inside the JVM when you hit Run: ───────────────────── Step 1 — Your code becomes Bytecode ───────────────────── When you write Java and compile it: .java file → javac compiler → .class file That .class file isn't machine code. It's Bytecode — a middle language that NO operating system understands directly. Only one thing understands it. The JVM. ───────────────────── Step 2 — Class Loader picks it up ───────────────────── The JVM doesn't just blindly execute your bytecode. First, the Class Loader loads it into memory. It does 3 things: → Loading — finds and imports your .class file → Linking — verifies the bytecode is valid and safe → Initialization — sets up static variables and runs static blocks This is Java's first security checkpoint. Malformed or malicious bytecode gets caught RIGHT here. ───────────────────── Step 3 — Memory Areas kick in ───────────────────── Once loaded, JVM allocates memory across different areas: → Heap — where all your objects live (this is where garbage collection happens) → Stack — where method calls and local variables are stored → Method Area — stores class-level data, static variables → PC Register — tracks which instruction is currently executing → Native Method Stack — for native (non-Java) code execution The Heap is where most Java interview questions come from. Garbage Collection, memory leaks, OutOfMemoryError — all Heap problems. ───────────────────── Step 4 — Execution Engine runs it ───────────────────── Now the actual execution happens via: → Interpreter — reads and executes bytecode line by line (slow) → JIT Compiler (Just-In-Time) — detects frequently run code and compiles it directly to native machine code (fast) → Garbage Collector — automatically cleans up objects no longer in use This is why Java is fast despite being interpreted. JIT makes it competitive with C++ in many real-world scenarios. ───────────────────── Step 5 — Native Libraries ───────────────────── Some operations Java can't do alone. File I/O, network calls, OS-level interactions. For these, JVM uses Native Method Interface (JNI) to talk to native libraries written in C/C++. This is how Java stays platform-independent while still accessing platform-specific features. ───────────────────── 🧠 The Full Flow in one line: ───────────────────── .java → javac → .class (Bytecode) → Class Loader → Memory Allocation → Execution Engine (Interpreter + JIT) → Native Libraries → Output Most people say "JVM runs Java." But now you know exactly HOW. Day 4 of learning Java in public. ✅ One deep concept every single day. What part of JVM do YOU find most interesting? 👇 #Java #JVM #LearnInPublic #SoftwareEngineering #Day4 #100DaysOfCode #JavaDeveloper #FullStackDeveloper #ByteCode #JIT

Here are some tricky Java fundamental questions 🔹 Primitive Data Types & Variables Why is Java called a statically typed language? How is it different from a strongly typed language? Why can variable names start only with $, _, or letters? Why not digits or symbols like @? 🔹 Type Promotion & Casting What is type promotion in Java? Why does this fail? byte a = 10; byte b = 20; byte c = a + b; 👉 Why is byte + byte automatically converted to int? Why does this work? int x = 10; long y = x; But this doesn’t: long x = 10; int y = x; What are the limitations of downcasting? When does data loss happen? 🔹 Static Concepts When are static variables initialized in Java? When does a static block execute? Can it run multiple times? 🔹 Floating Point (Most misunderstood topic) How are float and double stored in memory? Why don’t we use float much in real-world applications? Why does this happen? float a = 0.1f; float b = 0.2f; System.out.println(a + b); Why does 0.7f print as 0.699999... internally? What does System.out.printf("%.2f", 0.7f); actually do? Does double completely fix floating-point precision issues? 🔹 BigDecimal & Precision How does BigDecimal handle precision differently from float/double? Why is this bad? new BigDecimal(0.1) and why is this correct? new BigDecimal("0.1") If BigDecimal is perfect, why don’t we use it everywhere? 🔹 BigInteger & Overflow When do we use BigInteger instead of long? What happens when a number exceeds long range? 🔹 Bonus Core Concepts What happens when primitives overflow? Where are primitives stored: stack or heap? What is the default value of primitive variables vs local variables? Is Java truly pass-by-value even for primitives? 🔥 Critical Understanding Question 👉 Why does Java convert byte + byte into int automatically? Because in Java, any arithmetic on byte/short/char is internally promoted to int for performance and safety, so operations are done at a CPU-efficient level and then must be explicitly narrowed back if needed. #Java #JavaBasics #Programming #CodingInterview #SoftwareEngineering #Developers #ComputerScience #FloatingPoint #BigDecimal #CoreJava

🔥 𝐒𝐭𝐫𝐢𝐧𝐠 𝐯𝐬 𝐒𝐭𝐫𝐢𝐧𝐠𝐁𝐮𝐢𝐥𝐝𝐞𝐫 𝐯𝐬 𝐒𝐭𝐫𝐢𝐧𝐠𝐁𝐮𝐟𝐟𝐞𝐫 𝐢𝐧 𝐉𝐚𝐯𝐚 — 𝐒𝐭𝐨𝐩 𝐂𝐨𝐧𝐟𝐮𝐬𝐢𝐧𝐠 𝐓𝐡𝐞𝐦! This is one of the most asked Java interview questions — yet most developers can't explain the difference clearly. Let me fix that 👇 🔵 𝐒𝐭𝐫𝐢𝐧𝐠 — 𝐈𝐦𝐦𝐮𝐭𝐚𝐛𝐥𝐞 & 𝐓𝐡𝐫𝐞𝐚𝐝-𝐒𝐚𝐟𝐞 𝐒𝐭𝐫𝐢𝐧𝐠 𝐬𝟏 = "𝐇𝐞𝐥𝐥𝐨"; 𝐒𝐭𝐫𝐢𝐧𝐠 𝐬𝟐 = 𝐬𝟏 + " 𝐖𝐨𝐫𝐥𝐝"; // creates a NEW object every time! 𝐒𝐭𝐫𝐢𝐧𝐠 𝐬𝟑 = "𝐇𝐞𝐥𝐥𝐨"; // s1 == s3 → true (same String pool reference) // s1 == s2 → false (s2 is a brand new object) ✅ Stored in String Pool — memory efficient for reuse ✅ Thread-safe by design (immutable) ❌ Every + or concat() creates a new object — bad in loops! 🩷 𝐒𝐭𝐫𝐢𝐧𝐠𝐁𝐮𝐢𝐥𝐝𝐞𝐫 — 𝐌𝐮𝐭𝐚𝐛𝐥𝐞 & 𝐅𝐚𝐬𝐭 𝐒𝐭𝐫𝐢𝐧𝐠𝐁𝐮𝐢𝐥𝐝𝐞𝐫 𝐬𝐛 = 𝐧𝐞𝐰 𝐒𝐭𝐫𝐢𝐧𝐠𝐁𝐮𝐢𝐥𝐝𝐞𝐫(); 𝐬𝐛.𝐚𝐩𝐩𝐞𝐧𝐝("𝐇𝐞𝐥𝐥𝐨").𝐚𝐩𝐩𝐞𝐧𝐝(" 𝐖𝐨𝐫𝐥𝐝"); // same object 𝐬𝐛.𝐢𝐧𝐬𝐞𝐫𝐭(𝟎, "𝐒𝐚𝐲: "); 𝐬𝐛.𝐫𝐞𝐯𝐞𝐫𝐬𝐞(); 𝐒𝐭𝐫𝐢𝐧𝐠 𝐫𝐞𝐬𝐮𝐥𝐭 = 𝐬𝐛.𝐭𝐨𝐒𝐭𝐫𝐢𝐧𝐠(); ✅ Modifies the same object — no new allocations ✅ Fastest option for string manipulation ❌ NOT thread-safe — don't share between threads 🟣 𝐒𝐭𝐫𝐢𝐧𝐠𝐁𝐮𝐟𝐟𝐞𝐫 — 𝐓𝐡𝐫𝐞𝐚𝐝-𝐒𝐚𝐟𝐞 𝐛𝐮𝐭 𝐒𝐥𝐨𝐰𝐞𝐫 𝐒𝐭𝐫𝐢𝐧𝐠𝐁𝐮𝐟𝐟𝐞𝐫 𝐬𝐛 = 𝐧𝐞𝐰 𝐒𝐭𝐫𝐢𝐧𝐠𝐁𝐮𝐟𝐟𝐞𝐫(); 𝐬𝐛.𝐚𝐩𝐩𝐞𝐧𝐝("𝐇𝐞𝐥𝐥𝐨"); // synchronized  𝐬𝐛.𝐚𝐩𝐩𝐞𝐧𝐝(" 𝐖𝐨𝐫𝐥𝐝"); // Same API as StringBuilder, but all methods are synchronized ✅ Thread-safe — safe for multi-threaded access ❌ Synchronization adds overhead — slower than StringBuilder 📊 𝐐𝐮𝐢𝐜𝐤 𝐂𝐨𝐦𝐩𝐚𝐫𝐢𝐬𝐨𝐧 𝐅𝐞𝐚𝐭𝐮𝐫𝐞 𝐒𝐭𝐫𝐢𝐧𝐠 𝐒𝐭𝐫𝐢𝐧𝐠𝐁𝐮𝐢𝐥𝐝𝐞𝐫 𝐒𝐭𝐫𝐢𝐧𝐠𝐁𝐮𝐟𝐟𝐞𝐫 Mutable? ❌ No ✅ Yes ✅ Yes Thread-safe? ✅ Yes ❌ No ✅ Yes Speed Slowest* Fastest Moderate Use case Constants Loops Multi-thread *+ in a loop is slow. Compiler may optimize single-line concatenation. 💡 Golden Rule: Use 𝐒𝐭𝐫𝐢𝐧𝐠 for fixed values. Use 𝐒𝐭𝐫𝐢𝐧𝐠𝐁𝐮𝐢𝐥𝐝𝐞𝐫 for manipulation in single-threaded code. Use 𝐒𝐭𝐫𝐢𝐧𝐠𝐁𝐮𝐟𝐟𝐞𝐫 only when multiple threads share the same buffer. Drop a 🔥 if this cleared your confusion! Tag a Java dev who still uses + inside loops 😄 👇 Which one do you use most in your projects? #Java #String #StringBuilder #StringBuffer #CoreJava #Backend #SpringBoot #JavaDeveloper #100DaysOfCode #InterviewPrep #Programming

❔ Problem Statement: LLMs are stateless and lack access to application-specific data and services, making them insufficient for real-world backend interactions. The challenge is to enable them to understand intent, invoke appropriate tools, and generate context-aware responses through structured orchestration. Python LangChain is the innovation layer for LLM orchestration, while LangChain4j and Spring AI bring similar capabilities into Java for enterprise systems. Spring AI focuses more on integration and MCP support, whereas LangChain4j is closer to raw LangChain concepts, and MCP itself is just a protocol that standardizes tool communication rather than replacing these frameworks. Bringing them into Java Applications: **LangChain4j (Java equivalent of LangChain): LangChain4j is Java library that brings LLM orchestration capabilities similar to Python’s LangChain. It acts as an alternative to Spring AI, but: LangChain4j =>more LLM-first abstraction Spring AI =>more Spring ecosystem integrated approach What it does: ->LLM integrations (OpenAI, Ollama, Anthropic Claude, etc.). ->Memory (chat history). ->RAG (retrieval-augmented generation) ->Tool calling / function calling. ->Prompt templates. **LangGraph4j (Stateful orchestration layer): LangGraph4j is the Java adaptation of LangGraph It can be used with langchain/spring ai together, deals on state management, nodes, edges and traversing through relationship. Core Concepts State: shared data across steps Nodes: actions (LLM/tool/function) Edges: transitions Graph traversal: execution flow Stateful in nature unlike langchain which is stateless[unless memory added]. Designed for: ->Multi-agent orchestration systems ->Retry/ loops ->Conditional flows ->Long-running workflows. Where and when to use [strategy approach]: In Python LangChain LLM + tools LangGraph ->workflow + state Java Applications (Approach1) LangChain4j -> LLM + tools LangGraph4j -> workflow + state Java Applications (Approach 2) Spring AI -> LLM + tools + integration MCP ->tool communication layer LangGraph4j (optional) ->workflow + state In real systems, LangChain4j is used for executing LLM and tool interactions, while LangGraph4j manages the overall workflow and state, allowing both to be combined to build fully functional AI systems. #LLM #LangChain #LangGraph #SpringAI  #Java #SystemDesign

🚀 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

𝗝𝗗𝗞 𝘃𝘀 𝗝𝗥𝗘 𝘃𝘀 𝗝𝗩𝗠 Here's what actually happens when you run a Java program — and the parts most engineers never learn: JDK → JRE → JVM → JIT 𝗝𝗗𝗞 (Java Development Kit) Your complete toolbox. Compiler (javac), debugger, profiler, keytool, jshell — and a bundled JRE. Without it, you can't write or compile Java. Just run it. 𝗝𝗥𝗘 (Java Runtime Environment) JVM + standard class libraries. Ships to end users. No compiler. No dev tools. Just enough to run a .jar. 𝗝𝗩𝗠 (Java Virtual Machine) This is where it gets interesting. 𝗧𝗵𝗿𝗲𝗲 𝗹𝗮𝘆𝗲𝗿𝘀 𝗶𝗻𝘀𝗶𝗱𝗲: • Class Loader — loads, links, and initializes .class files at runtime (not all at startup) • Runtime Data Areas — Heap, Stack, Method Area, PC Register, Native Method Stack • Execution Engine — interprets + compiles bytecode 𝗝𝗜𝗧 (Just-In-Time Compiler) Watches your code at runtime. Identifies "hot" methods — those called frequently. Compiles them natively. Skips the interpreter next time. That's how Java catches up to C++ performance on long-running workloads. 𝗪𝗵𝗮𝘁 𝗺𝗼𝘀𝘁 𝗱𝗲𝘃𝘀 𝗺𝗶𝘀𝘀 • 𝗖𝗹𝗮𝘀𝘀 𝗟𝗼𝗮𝗱𝗶𝗻𝗴 𝗶𝘀 𝗹𝗮𝘇𝘆 The JVM doesn't load all classes upfront. It loads them on first use — which is why cold start time differs from steady-state throughput. • 𝗝𝗜𝗧 𝗵𝗮𝘀 𝘁𝗶𝗲𝗿𝘀 HotSpot JVM uses tiered compilation: C1 (fast, light optimization) kicks in first, then C2 (aggressive optimization) takes over for truly hot code. GraalVM replaces C2 entirely with a more powerful compiler. • 𝗧𝗵𝗲 𝗛𝗲𝗮𝗽 𝗶𝘀 𝗻𝗼𝘁 𝗼𝗻𝗲 𝘁𝗵𝗶𝗻𝗴 It's split: Eden → Survivor Spaces → Old Gen → Metaspace (post Java 8). Understanding this is prerequisite to tuning GC and fixing OOM errors. • 𝗦𝘁𝗮𝗰𝗸 𝘃𝘀 𝗛𝗲𝗮𝗽 — 𝗿𝘂𝗻𝘁𝗶𝗺𝗲 𝗯𝗲𝗵𝗮𝘃𝗶𝗼𝗿 Every thread gets its own stack. Local primitives live there. Objects always go to the heap. References live on the stack. This is why stack overflows (deep recursion) and heap OOMs are completely different problems. • 𝗝𝗩𝗠 𝗶𝘀 𝗻𝗼𝘁 𝗮𝗹𝘄𝗮𝘆𝘀 𝗶𝗻𝘁𝗲𝗿𝗽𝗿𝗲𝘁𝗲𝗱 When GraalVM's native-image compiles your app ahead-of-time (AOT), there's no JVM at runtime at all. Instant startup. Fixed memory footprint. Different trade-offs. • 𝗕𝘆𝘁𝗲𝗰𝗼𝗱𝗲 𝗶𝘀 𝗻𝗼𝘁 𝗯𝗶𝗻𝗮𝗿𝘆 It's an intermediate representation — platform-agnostic instructions the JVM can run on any OS. This is Java's "write once, run anywhere" in practice, not just in theory. 𝗧𝗵𝗲 𝗺𝗲𝗻𝘁𝗮𝗹 𝗺𝗼𝗱𝗲𝗹 𝘁𝗵𝗮𝘁 𝗰𝗹𝗶𝗰𝗸𝘀: • JDK = write + compile + run • JRE = run only • JVM = execution environment • JIT = runtime optimizer What's the JVM internals detail that surprised you most when you first learned it? A special thanks to my faculty Syed Zabi Ulla sir at PW Institute of Innovation for their clear explanations and continuous guidance throughout this topic. #Java #JVM #SoftwareEngineering #BackendDevelopment #ProgrammingFundamentals

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