Java Data Storage and Type Casting Explained

Just wrapped up learning different ways to create a deep copy in Java, and honestly, it’s one of those topics that looks simple… until it isn’t Here are the approaches I explored: Copy Constructor – Clean and explicit, gives full control over how objects are copied. Clone Method – Classic approach using Cloneable, but comes with its own quirks and pitfalls. Apache Commons Lang – Using serialization utilities for quick deep copies. Gson – Convert object → JSON → object again (simple but not always efficient). Jackson – Similar to Gson, but more powerful and widely used in production systems. Key takeaway: There’s no “one-size-fits-all” solution. The right choice depends on: Performance requirements Object complexity Maintainability and readability For example, while serialization-based approaches (Gson/Jackson) are convenient, they may not be ideal for performance-critical systems. On the other hand, copy constructors provide clarity but require more manual effort. Understanding these trade-offs is what really makes the difference. Always remember: Shallow copy can silently introduce bugs Deep copy ensures data safety but must be used wisely Excited to keep diving deeper into Java internals and writing more robust code #Java #DeepCopy #Programming #SoftwareDevelopment #BackendDevelopment #JavaDeveloper #CleanCode #CodingJourney #LearningInPublic #TechSkills #Developers #ObjectOrientedProgramming #Engineering

𝘂𝘀𝗲𝗱 𝘁𝗼 𝘁𝗵𝗶𝗻𝗸 “𝗳𝗶𝗻𝗮𝗹 𝗶𝗻 𝗹𝗮𝗺𝗯𝗱𝗮” 𝗶𝘀 𝗷𝘂𝘀𝘁 𝗮𝗻𝗼𝘁𝗵𝗲𝗿 𝗝𝗮𝘃𝗮 𝗿𝘂𝗹𝗲… Until it actually hit me in a real scenario. I was writing a simple async flow using lambda… And suddenly compiler said: 👉 “variable must be final or effectively final” My first reaction: “Why Java is so strict here?” 😅 Then I tried to think deeper… int x = 10; Runnable r = () -> System.out.println(x); x = 20; r.run(); Now honestly… 👉 What should this print? 10? 20? That’s when it clicked 💡 Java doesn’t want you to even enter this confusion zone Lambdas in Java don’t behave like typical closures. They don’t track changing variables… They capture a fixed value snapshot So once captured → it must not change. Then I looked from concurrency angle 🧵 We use lambdas everywhere: ✔ Threads ✔ Async calls ✔ Streams If local variables were mutable: → Race conditions → Visibility issues → Nightmares in debugging That small “final” rule is actually doing a BIG job silently. It’s forcing: ✔ Predictable behavior ✔ Safer multi-threading ✔ Cleaner thinking And the best part? Java even relaxed it with effectively final So you don’t write extra code… But still get safety. Now whenever I see this rule… I don’t see restriction anymore. I see design maturity. 𝗥𝗲𝗮𝗹 𝘁𝗮𝗸𝗲𝗮𝘄𝗮𝘆 🚀 “Good languages don’t just give power… They protect you from misusing it.” Funny how a small compile-time error… Can teach such a deep concept. If you’ve faced this before, you know the pain 😄 If not, you will… and you’ll remember this.

🚀 #Headline: Day 10 — How Arrays Work in Java (Deep Dive into Memory) After learning array syntax in Part 1, today's lecture went beneath the surface. This wasn't about writing more code – it was about understanding what actually happens inside the JVM when you write new int[5]. This is the kind of knowledge that separates surface-level coders from developers who truly understand their tools. Covered in this lecture: ✔️ Why arrays are stored in contiguous memory ✔️ How arrays are allocated in Heap memory (not Stack!) ✔️ Stack vs Heap – what goes where ✔️ What happens inside the JVM during array creation ✔️ How memory indexing actually works (base address + offset) ✔️ Why array access is O(1) – constant time random access ✔️ Performance implications of contiguous storage ✔️ Special case of boolean arrays ✔️ How 2D arrays are stored in memory ✔️ Array of Strings – reference behavior The "aha" moment came when the instructor explained the math behind indexing: address = base + (index × size). This is why arrays are so fast – no traversal needed, just a direct calculation. Understanding that array references live on the Stack while the actual data lives on the Heap clarifies so many concepts about memory management. This lecture truly delivered on its promise: "This is not just coding. This is internal understanding." Learning from: 👨🏫 Aditya Tandon (Instructor) 🚀 Rohit Negi (CoderArmy) 📺 Source: https://lnkd.in/gpFpcpDs Let's connect 🤝 Pankaj Kumar #Java #100DaysOfCode #ProgrammingJourney #JavaBasics #BuildInPublic

🚫 Java is NOT a pure object-oriented language… and that’s exactly why it wins. When I first started exploring Java in depth, I believed everything was truly object-oriented—it felt like every piece of code revolved around classes. But the deeper I went, the more I realized the reality is far more nuanced… and way more interesting. Here’s the truth 👇 👉 A pure object-oriented language means everything is an object. No exceptions. Languages like Smalltalk follow this strictly. 👉 But Java? It bends the rules. ⚡ Primitive data types exist int, char, boolean, double — these are NOT objects. They don’t belong to any class and don’t inherit from anything. ⚡ Static methods & variables break OOP principles They belong to the class, not objects—so they bypass core concepts like polymorphism. ⚡ Wrapper classes exist… but as a workaround Yes, Integer, Double, etc. exist—but the fact we need them proves primitives aren't objects. So why does Java do this? Because Java chose performance + practicality over purity. Primitive types: ✔ Faster ✔ Memory efficient ✔ Less overhead than objects If Java forced everything to be an object, it would sacrifice speed—especially in large-scale systems. 💡 The takeaway: Java is an object-oriented language, but not purely object-oriented. And that’s not a flaw—it’s a design decision. 👉 In real-world engineering, balance beats ideology. — 💬 What’s your take—does this change how you look at Java? #Java #Programming #OOP #SoftwareEngineering #Coding

🚀 DAY 76/150 — CHECKING SUBTREES WITH RECURSION! 🌳 Day 76 of my 150 Days DSA Challenge in Java and today I solved a problem that strengthens my understanding of tree comparison and recursion 💻🧠 📌 Problem Solved: Subtree of Another Tree 📌 LeetCode: #572 📌 Difficulty: Easy–Medium The task is to determine whether one binary tree is a subtree of another binary tree. A subtree must match both structure and node values exactly. 🔹 Approach Used I used a recursive DFS approach: • Traverse each node of the main tree • For every node: Check if the subtree starting at that node is identical to the given tree • Use a helper function to compare two trees: If both nodes are null → true If values differ → false Recursively compare left and right subtrees ⏱ Complexity Time Complexity: O(n × m) (n = nodes in main tree, m = nodes in subtree) Space Complexity: O(h) (recursion stack) 🧠 What I Learned • Tree problems often require combining traversal + comparison • Recursion is powerful for handling hierarchical structures like trees • Breaking the problem into smaller checks simplifies the solution 💡 Key Takeaway This problem taught me how to: Compare two trees efficiently Apply recursion for structural matching Think in terms of subproblems within trees 🌱 Learning Insight As I continue my Binary Tree journey, I’m understanding that: Most tree problems are based on DFS, BFS, or recursion patterns Mastering these basics makes complex tree problems easier ✅ Day 76 completed 🚀 74 days to go 🔗 Java Solution on GitHub: 👉 https://lnkd.in/gZNXaW-C 💡 In trees, solving smaller parts correctly leads to the full solution. #DSAChallenge #Java #LeetCode #BinaryTree #Recursion #DFS #150DaysOfCode #ProblemSolving #CodingJourney #InterviewPrep #LearningInPublic

I recently revisited Chapter 3: "Methods Common to All Objects" in Effective Java by Joshua Bloch. This chapter focuses on the core methods defined in Object that every Java class inherits, and how to override them correctly. Here are the key takeaways I found most valuable: 1. equals() • Override equals() when a class has a notion of logical equality, not just object identity. • Follow the contract: reflexive, symmetric, transitive, consistent, and x.equals(null) must return false. • Compare only significant fields and ensure type compatibility. 2. hashCode() • Always override hashCode() when overriding equals(). • Equal objects must have the same hash code. • A good hash function combines the hash codes of significant fields. This is critical when using hash-based collections like HashMap or HashSet. 3. toString() • Provide a meaningful toString() implementation. • Include useful information about the object's state. • A well-designed toString() greatly simplifies debugging and logging. 4. clone() and Comparable • clone() is tricky and often better avoided in favor of copy constructors or factory methods. • Implement Comparable when a class has a natural ordering, and ensure consistency with equals(). 💡 My takeaway: Correctly implementing equals(), hashCode(), and toString() is fundamental for writing reliable Java classes. These methods influence how objects behave in collections, comparisons, debugging, and logging. Getting them right improves correctness and maintainability across the entire codebase. #Java #EffectiveJava #JoshuaBloch #CleanCode #SoftwareEngineering #JavaTips #Coding #JavaDevelopment

#GenAI #RagforJAVA Few months ago I tried to build a RAG system in Java. I found 47 Python tutorials and exactly zero complete Java examples. So I figured it out the hard way : and wrote down everything I learned. Here's what nobody tells you about RAG in Java: The concept is simple. Two pipelines: #Ingest your docs (chunk → embed → store) #Answer questions (embed query → retrieve → prompt → LLM) The implementation is where it gets interesting. 𝗖𝗵𝘂𝗻𝗸𝗶𝗻𝗴 matters more than the model. I've seen teams obsess over GPT-4 vs Claude while their chunks are 2000 tokens with no overlap. Fix chunking first. 𝗬𝗼𝘂 𝗱𝗼𝗻'𝘁 𝗻𝗲𝗲𝗱 𝗮 𝗳𝗮𝗻𝗰𝘆 𝘃𝗲𝗰𝘁𝗼𝗿 𝗗𝗕 𝘁𝗼 𝘀𝘁𝗮𝗿𝘁. If you already use PostgreSQL, install pgvector. One extension. You're done. 𝗦𝗽𝗿𝗶𝗻𝗴 𝗔𝗜 𝗵𝗮𝘀 𝗺𝗮𝘁𝘂𝗿𝗲𝗱 𝗮 𝗹𝗼𝘁. VectorStore, EmbeddingModel, ChatClient — it's actually pleasant to work with now. 𝗘𝗺𝗯𝗲𝗱𝗱𝗶𝗻𝗴𝘀 𝗮𝗿𝗲 𝗰𝗵𝗲𝗮𝗽. 𝗚𝗲𝗻𝗲𝗿𝗮𝘁𝗶𝗼𝗻 𝗶𝘀 𝗻𝗼𝘁. Stop worrying about embedding costs. Watch your LLM token usage instead. 𝗦𝗶𝗺𝗶𝗹𝗮𝗿𝗶𝘁𝘆 𝘁𝗵𝗿𝗲𝘀𝗵𝗼𝗹𝗱𝘀 𝗮𝗿𝗲 𝗺𝗮𝗻𝗱𝗮𝘁𝗼𝗿𝘆. Without one, your LLM gets handed irrelevant junk and hallucinates confidently. Always set withSimilarityThreshold(). I wrote a full guide: architecture diagrams, working Spring Boot code (IngestionService, RagService, REST controller), pgvector setup, chunking strategies, advanced patterns like HyDE and reranking, and a production checklist. All Java. No Python. #Java #SpringBoot #RAG #GenerativeAI #BackendEngineering #LLM

Peglib 0.2.0 + 0.2.1 -- Major code generation reliability release Peglib is a PEG parser library for Java, inspired by cpp-peglib. It lets you define parsers using PEG grammar syntax, with support for both runtime interpretation and standalone source code generation. These two releases focused on one goal: making the generated standalone parser produce identical results to the interpreted parser. Every time. What changed: -- Rewrote the CST/AST code generator from the ground up to structurally mirror the interpreter's control flow. Identified and fixed 7 behavioral divergences in whitespace handling, predicate evaluation, cut failure propagation, and token boundary tracking. -- Fixed generated parsers crashing with StackOverflowError when the whitespace directive references named rules like LineComment or BlockComment. Added a reentrant guard matching the interpreter's approach. -- Fixed generated Token nodes losing their rule names. Tokens from < > captures now carry the parent rule name (e.g., "SelectKW", "NumericType") instead of a generic "token". -- Fixed CST tree structure. Container expressions (ZeroOrMore, OneOrMore, Optional) now wrap their children in proper NonTerminal nodes instead of flattening them into the parent -- matching how the interpreter builds the tree. -- Added 40 conformance tests that run the same grammars and inputs through both the interpreted and generated parsers, asserting identical success/failure outcomes. These fixes were discovered while building a PostgreSQL SQL parser with peglib. The interpreted parser handled the full grammar correctly, but the generated standalone parser had subtle failures. Now both produce matching results on all 350 tests. Test count: 308 -> 350 pragmatica-lite dependency: 0.9.10 -> 0.24.0 Available on Maven Central:   <groupId>org.pragmatica-lite</groupId>   <artifactId>peglib</artifactId>   <version>0.2.1</version> GitHub: https://lnkd.in/dgdjZahV #java #parsing #peg #opensource #compilers

𝗙𝗿𝗼𝗺 𝟱𝟬 𝗟𝗶𝗻𝗲𝘀 𝘁𝗼 𝟭: 𝗠𝘆 𝗝𝗼𝘂𝗿𝗻𝗲𝘆 𝘄𝗶𝘁𝗵 𝗝𝗮𝘃𝗮 𝗜𝗺𝗺𝘂𝘁𝗮𝗯𝗶𝗹𝗶𝘁𝘆 🚀 I used to think creating a safe, immutable class in Java was a chore. It turns out, I was just doing it the "old" way. Here is how I moved from complex boilerplate to clean, modern Java: Phase 1: The Traditional Way (The 5 Steps) 📝 To make a standard class truly immutable, you need to follow these strict rules: final class: Stop anyone from extending and changing your logic. private final fields: Lock your variables so they can’t be reassigned. No Setters: If you don’t provide a setX() method, the data can’t change! Defensive Copying: If you have a List, copy it in the constructor so the caller can’t change it from the outside. Boilerplate: Manually write equals(), hashCode(), and toString(). (Total: ~50 lines of code for one simple object! 😫) Phase 2: The "Record" Revolution (The 1-Line Way) ⚡ Since Java 14, we can replace all that manual work with a Record. 𝐩𝐮𝐛𝐥𝐢𝐜 𝐫𝐞𝐜𝐨𝐫𝐝 𝐔𝐬𝐞𝐫(𝐒𝐭𝐫𝐢𝐧𝐠 𝐧𝐚𝐦𝐞, 𝐋𝐢𝐬𝐭<𝐒𝐭𝐫𝐢𝐧𝐠> 𝐠𝐫𝐚𝐝𝐞𝐬) {} Why this is a game-changer: It is final by default. Fields are private final by default. equals(), hashCode(), and toString() are generated for you. Phase 3: The Final Level (Deep Immutability) ❄️ Wait! Even in a Record, a List is still mutable. To make it 100% safe, use a Compact Constructor: 𝐩𝐮𝐛𝐥𝐢𝐜 𝐫𝐞𝐜𝐨𝐫𝐝 𝐔𝐬𝐞𝐫(𝐒𝐭𝐫𝐢𝐧𝐠 𝐧𝐚𝐦𝐞, 𝐋𝐢𝐬𝐭<𝐒𝐭𝐫𝐢𝐧𝐠> 𝐠𝐫𝐚𝐝𝐞𝐬) {   𝐩𝐮𝐛𝐥𝐢𝐜 𝐔𝐬𝐞𝐫 {     𝐠𝐫𝐚𝐝𝐞𝐬 = 𝐋𝐢𝐬𝐭.𝐜𝐨𝐩𝐲𝐎𝐟(𝐠𝐫𝐚𝐝𝐞𝐬); // 𝐍𝐨𝐰 𝐢𝐭'𝐬 𝐭𝐫𝐮𝐥𝐲 𝐟𝐫𝐨𝐳𝐞𝐧!   } } The Result? ✅ Thread Safety: No more race conditions. ✅ Clean Code: You focus on the data, not the "ceremony." ✅ Peace of Mind: Your objects won't change behind your back. #Java #SoftwareEngineering #CleanCode #JavaRecords #ProgrammingTips #LearningInPublic

🚀 Day 15/30 – Java DSA Challenge 🔎 Problem 67: 225. Implement Stack using Queues (LeetCode – Easy) Continuing Day 15 with another foundational data structure problem — implementing a Stack (LIFO) using only Queue (FIFO) operations. This problem strengthens core understanding of: ✅ Stack vs Queue behavior ✅ Data Structure simulation ✅ Queue rotation logic ✅ LIFO implementation under constraints 🧠 Problem Summary We must design a stack using only standard queue operations: push(x) pop() top() empty() ⚠ Constraint: Only queue operations like add (push to back), poll (remove from front), peek, size, and isEmpty are allowed. 💡 Key Insight Stack → Last In First Out (LIFO) Queue → First In First Out (FIFO) To simulate LIFO behavior using FIFO: 👉 After every push, rotate the queue so the newly added element moves to the front. That ensures: pop() removes the most recently added element top() always returns the latest element 🔄 Approach Used 1️⃣ Use a single queue 2️⃣ On push(x): Add element to queue Rotate all previous elements behind it 3️⃣ pop() → simply poll from queue 4️⃣ top() → peek front 5️⃣ empty() → check if queue is empty ⏱ Complexity Analysis Push: O(N) Pop: O(1) Top: O(1) Space Complexity: O(N) 📌 Concepts Strengthened ✔ Stack fundamentals ✔ Queue manipulation ✔ Data structure transformation ✔ Logical thinking under constraints 📈 Learning Reflection Even though the problem is labeled Easy, it tests conceptual clarity. When constraints change, true understanding of data structures helps you adapt — not just memorize implementations. ✅ Day 15 Progress Update 🔥 67 Problems Solved in 30 Days DSA Challenge Consistency + Concept Clarity = Long-Term Mastery 🚀 #Day15 #30DaysOfDSA #Java #LeetCode #Stack #Queue #DataStructures #ProblemSolving #InterviewPreparation #CodingJourney