Java SE 6: Mustang Era Redefines Performance & Architecture

Want to Level Up Your Java Game? Let's Talk JVM! 🚀 Ever wondered what makes Java tick behind the scenes? 🧐 It’s not just a language; it's an entire ecosystem, and the heart of it all is the Java Virtual Machine (JVM). 💓 Understanding the JVM is like knowing how your car's engine works—it makes you a better driver, or in our case, a better developer! 👩💻👨💻 Think of the JVM as Java’s interpreter and bodyguard. It’s what gives Java its superpower: "Write Once, Run Anywhere." 🌍 Here's a quick, breakdown of how it pulls off the magic. ✨ Your Code's Epic Journey: 1️⃣ Class Loader Subsystem: This is the JVM's "receptionist." It reads your .class files (compiled Java bytecode) and loads them into memory. It also takes care of linking and initialising things so they're ready to go. 🧑✈️ 2️⃣ Runtime Data Areas (Memory): This is where all the action happens! 🏗️ It's divided into key zones: * Method Area: Stores class information and static variables. Think of it as the project blueprint repository. 📂 * Heap: The big arena where all your objects live. 🏟️ This is shared space, and it's where the Garbage Collector does its work. * JVM Stack: Per-thread, private storage for method calls and local variables. Think of it as a personal notebook for each process. 💪 * PC Register: Keeps track of exactly where each thread is in the execution process. The ultimate bookmark! 🔖 * Native Method Stack: Dedicated space for non-Java (native) code. 🌐 3️⃣ Execution Engine: The engine room! 🚂 It takes that bytecode and turns it into real, executable commands. This is where you find the performance boosters: * Interpreter: Executes bytecode line by line, fast for getting things started. ⚡️ * JIT (Just-In-Time) Compiler: The performance wizard. 🧙♂️ It finds the "hot spots" in your code and compiles them directly into native machine code for maximum speed. * Garbage Collector (GC): Your code's janitor. 🧹 It automatically finds and frees up memory occupied by objects you're no longer using, preventing memory leaks and keeping things running smoothly. So, next time you run a Java application, remember the incredibly sophisticated JVM working tirelessly to make it happen! ⚙️ What's your favourite part of JVM architecture? Let me know in the comments! 👇 #Java #JVM #SoftwareEngineering #TechInfluencer #CloudComputing #CodingLife #LearnToCode #JavaDeveloper #TechTutorials #ProgrammerInsights #JVMInternal #PerformanceOptimization

☕ COMPLETE JAVA ROADMAP (Beginner → Advanced) 🟢 LEVEL 1 — Absolute Beginner (Foundation Stage) 1️⃣ Setup Environment Install JDK (17 or 21 LTS) Understand JDK vs JRE vs JVM Install IntelliJ IDEA (Community) Run Hello World Understand how compilation works (javac → bytecode → JVM) 2️⃣ Core Syntax Variables Data Types (int, double, float, boolean, char, String) Operators (arithmetic, relational, logical) Type casting Input using Scanner Output using System.out.println() 3️⃣ Control Flow if / else switch for loop while loop do-while loop break & continue 4️⃣ Methods Creating methods Return types Parameters Method overloading Call by value concept 5️⃣ Arrays 1D arrays 2D arrays Looping through arrays Basic array problems 🟡 LEVEL 2 — OOP Mastery (VERY IMPORTANT) 6️⃣ Classes & Objects Creating classes Creating objects Fields & methods Access modifiers (public, private, protected) 7️⃣ Constructors Default constructor Parameterized constructor Constructor overloading 8️⃣ OOP Pillars Encapsulation Inheritance Polymorphism Abstraction 9️⃣ Advanced OOP Interfaces Abstract classes final keyword static keyword this & super 🔵 LEVEL 3 — Intermediate Java 🔟 Exception Handling try / catch finally throw / throws Custom exceptions 1️⃣1️⃣ Collections Framework ArrayList LinkedList HashSet HashMap Iterator Comparable & Comparator 1️⃣2️⃣ Strings Deep Dive String methods StringBuilder StringBuffer Immutability concept 1️⃣3️⃣ File Handling Reading files Writing files BufferedReader FileWriter Serialization 1️⃣4️⃣ Packages & Access Control Creating packages Importing packages Access rules 🟣 LEVEL 4 — Advanced Java Concepts 1️⃣5️⃣ Multithreading Thread class Runnable interface Synchronization Thread lifecycle Executor framework 1️⃣6️⃣ Generics Generic classes Generic methods Wildcards 1️⃣7️⃣ Java 8+ Features Lambda expressions Functional interfaces Streams API Optional class Method references 1️⃣8️⃣ Annotations Built-in annotations Custom annotations 1️⃣9️⃣ Reflection API Class object Getting methods dynamically 🔴 LEVEL 5 — Professional Developer Level 2️⃣0️⃣ Data Structures & Algorithms (VERY IMPORTANT) Arrays Strings Linked List Stack Queue Recursion Sorting Searching Time complexity (Big-O) 2️⃣1️⃣ JDBC Connecting to MySQL CRUD operations PreparedStatement 2️⃣2️⃣ Build Real Projects Student Management System Banking Application Inventory System Chat Application 🏆 LEVEL 6 — Choose Specialization Now you pick path: 📱 If Android Developer: Android Studio XML layouts Activities & Fragments Firebase REST APIs MVVM architecture 🌐 If Backend Developer: Spring Framework Spring Boot REST API Hibernate Microservices JWT Authentication Docker deployment 🎮 If Game Developer: LibGDX OpenGL basics Game physics Multiplayer basics 🧠 MASTER LEVEL Design Patterns (Singleton, Factory, Observer, MVC) Clean Code principles SOLID principles Git mastery Build portfolio Contribute to open source

Method Overloading: More Than Just Same Method Names Just wrapped up a deep‑dive quiz session on Method Overloading in Java - scored 16.5 out of 18 While the overall result is solid, the half‑point deductions were a humbling reminder that method overloading - often considered a straightforward concept - has subtle intricacies that can trip up even experienced developers. The quiz covered a wide range of scenarios, and I’m sharing my takeaways because these details matter in everyday coding and design. What I explored: ✅ Core Rules - Method overloading is about same method name, different parameter lists (number, type, or order).   ✅ Return Type - Alone, it’s "not" sufficient to overload a method. The compiler needs the parameter list to decide.   ✅ Invalid Overloading - Understanding what doesn’t work (e.g., only changing return type) prevents subtle bugs.   ✅ Differentiating Overloaded Methods - How Java resolves the correct method at compile time.   ✅ Overloading and Polymorphism - Overloading is compile‑time (static) polymorphism, not runtime.   ✅ Timing of Resolution - Confirmed: overloading is resolved at compile time based on reference type.   ✅ Access Modifiers - They don’t affect overloading; you can overload with different access levels.   ✅ Number of Parameters - A key dimension; varying the count is a primary way to overload.   ✅ Benefits - Code readability, flexibility, and supporting multiple use cases with one method name.   ✅ Constructor Overloading - Same rules apply; essential for providing multiple object initialization paths.   ✅ Parameter Order - Changing order of parameters (of different types) is a valid overloading technique. 📉 Where I lost points (and learned the most): - Method Overloading and Polymorphism (0.5/1) – A reminder that overloading isn’t runtime polymorphic; that’s overriding’s job.   - Method Overloading Timing (0.5/1) – Reinforced that binding happens at compile time.   - Number of Parameters in Overloaded Methods (0.5/1 after 2 attempts) - Probably a trick question about ambiguity.   - Constructor Overloading in Java (0.5/1 after 2 attempts) - Highlighted nuances like constructor chaining with "this()".   - Parameter Order (0.5/1 after 2 attempts) - A valid but often overlooked way to overload. 💡Why this matters: Method overloading improves API usability and readability, but misusing it can lead to confusing code or unexpected method calls. Knowing the rules thoroughly helps you design cleaner interfaces and avoid common pitfalls - especially when working on libraries or frameworks where method names are exposed to other developers. If you’re a Java developer, I’d love to hear: What’s the most surprising overloading behaviour you’ve encountered? Or a trick question that stumped you? Drop it in the comments! 👇 #Java #MethodOverloading #Polymorphism #CleanCode #OOP #SoftwareEngineering #LearningInPublic TAP Academy

Standard Signature of main() Method in Java In every programming language there must be an entry point of execution from where program execution begins. In C/C++, the entry point is the main() function, which is invoked by the Operating System. OS expects 0 as exit status indicating successful program execution so the return type of main is commonly int. In Java, the entry point is also the main() method, but it is invoked by the Java Virtual Machine (JVM) instead of the OS. Since the JVM handles execution internally, there is no need to return a status code, therefore the return type of the main method is always void. In Java, every method belongs to a class, so the main method must be defined inside a class. Example: class Main { void main() {      // code    } } However, this method cannot be executed by the JVM because it is not accessible outside the class. To allow the JVM to access it, the method must be declared public. class Main { public void main() {      // code    } } In Java, methods normally belong to objects and are invoked using an object reference. If the main method were not static, the JVM would have to create an object of the class before calling it. Since main is the entry point of every program, this would add unnecessary overhead. To allow the JVM to invoke the method without creating an object, the main method is declared static. class Main { public static void main() {      // code    } } But this method still cannot receive data from the command line arguments. To accept input from the command line during program execution, the main method takes a parameter which is an array of strings. Each element of this array represents one argument passed from the command line. Final standard signature of the main method: class Main {    public static void main(String[] args) {      // code    } } Here: public → allows the JVM to access the method static → allows the JVM to call the method without creating an object void → no return value required String[] args → receives command line arguments However, for a beginner writing "public static void main(String[] args)" is overwhelming. So Java developer decided to introduce simplified syntax for new comer to maintain language acceptance and popularity among all.  In newer Java versions, we can write a simpler program like: void main() {   System.out.println("Hello"); } Introduced in JDK 21 and finally accepted in JDK 25 (2025). The compiler automatically wraps this into a class behind the scenes. However, this feature is mainly designed for learning and small scripts, while the traditional main method remains the standard approach used in real applications. Grateful to my mentor Syed Zabi Ulla for explaining these concepts so clearly and helping me build a strong foundation in programming. #OOP #Java #Programming #ComputerScience #LearningJourney #SoftwareDevelopment

The "11th Rule" Trap: Why Java’s Map.of() Might Be Misleading You ❌ Have you ever written perfectly logical, declarative code, only to be hit by a strange Compilation Error? You look at your IDE, and it insists on an "Incompatible Types" issue, even though your classes match perfectly. I recently hit a classic, but treacherous problem, using the Map.of() method. 📋 Dispatch Map Pattern I was implementing a "Type-to-Strategy Map" to replace a messy chain of if-else and instanceof blocks. The idea is clean: a map where the key is the Rule class and the value is the mapping function. Ten rules worked flawlessly. But as soon as I added the eleventh, everything broke. 🤯 A Misleading Hint Instead of a clear "Too many arguments" message, the compiler threw a confusing: "Incompatible types: expected... " I spent 15 minutes re-verifying my code, thinking I had made a mistake in the type system. I was convinced the problem was the type of the new rule, while the actual problem was simply the quantity. The compiler's "confused" hint led me down a rabbit hole, when I should have just been counting my arguments. 💡 Why is there a limit of 10? Why can't Map.of() just use varargs like List.of() to accept any number of elements? Varargs can only handle a single type. Type Mixing: In a Map, we have Keys (K) and Values (V). Java's varargs doesn't have a syntax to say "take arguments where every first is K and every second is  V". Safety: Using Object... would lose type safety and risk an odd number of arguments, leading to runtime crashes. Performance: To keep Map.of() lightning-fast and "allocation-free" (avoiding temporary arrays), JDK developers manually overloaded it 11 times (from 0 to 10 pairs). Once you hit 11, you've run out of "pre-built" templates! ✅ The Fix: Map.ofEntries() To bypass the "one-type varargs" limit, Java uses Map.ofEntries(). It wraps each pair into a Map.Entry object. Since the type is now uniform (Entry), varargs works perfectly, allowing for any number of elements. 🛠 Lessons Learned: Source over Docs: When a standard method acts weird, Command(Ctrl for Windows) + Click into the JDK source. Don’t trust the error message 100%: The compiler often "guesses" the closest mismatch, leading you away from the actual fix. The Dispatch Map Pattern: Despite this hiccup, it’s a powerful way to keep your code Open/Closed compliant and maintainable. Have you ever been misled by a cryptic compiler error? Share your stories in the comments! 👇 #java #backend #programming #cleancode #softwaredevelopment #tips #generics #jvm

How Cursor Indexes a Codebase So Fast — Explained from Java prespective.... Cursor performs something very impressive: it can understand and index a large codebase extremely quickly. But how does it do that? In this article, we’ll break down Cursor’s indexing approach using concepts that Java developers are already familiar with—such as Git hashing, caching strategies, AST parsing, and search indexing. The Problem Cursor Solves Imagine opening a large Java project: * 10,000+ files * Multiple Spring Boot services * Controllers, Services, Repositories * Multi-module architecture If an AI tool wants to understand the project, it needs to: 1. Read all files 2. Understand the relationships between them 3. Quickly find relevant pieces of code If the system scanned the entire project every time something changed, it would be extremely slow and expensive. Cursor solves this by building a smart incremental indexing system. Step 1: File Hashing (Similar to Git) The first step is generating a * hash (fingerprint) for each file. Example: UserService.java → hash A23F9 OrderService.java → hash B77K2 ProductController.java → hash X91LM This idea is exactly how Git tracks file changes internally. If even a single line in a file changes, the file’s hash changes immediately. This makes it easy to detect which files were modified without scanning the entire project. Step 2: Building a Merkle Tree Instead of storing file hashes separately, Cursor organizes them into a Merkle Tree. A simplified structure looks like this: ``` ROOT HASH / \ HASH A HASH B / \ / \ file1 file2 file3 file4 ``` Each parent hash is calculated from its child hashes. If one file changes: * The file’s hash changes * Its parent hash changes * Eventually the root hash changes This allows Cursor to quickly detect where the change occurred in the codebase without reprocessing everything. Step 3: Smart Code Chunking Cursor does not treat code as plain text. Instead, it splits the code using AST (Abstract Syntax Tree) parsing. Step 4: Creating Embeddings Each code chunk is then converted into an embedding vector. An embedding is simply a numerical representation of the meaning of the code. Example (simplified): createOrder() → [0.23, 0.91, 0.11, ...] cancelOrder() → [0.77, 0.04, 0.55, ...] These vectors are stored inside a vector database(Cursor uses Turbopuffer). Step 5: Incremental Updates Why This Approach Is Fast * Merkle trees for fast change detection * AST-based code chunking for meaningful segmentation * Embeddings for semantic understanding * Vector databases for fast similarity search * Incremental indexing instead of full reprocessing Sometimes the real innovation is simply using the wheel in the right place,not reinventing the wheel.

𝗗𝗔𝗬 𝟯 – 𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲 𝗼𝗳 𝗮 𝗝𝗮𝘃𝗮 𝗣𝗿𝗼𝗴𝗿𝗮𝗺 + 𝗝𝗮𝘃𝗮 𝗧𝗼𝗸𝗲𝗻𝘀 𝗜𝗻 𝘁𝗵𝗲 𝗹𝗮𝘀𝘁 𝘁𝘄𝗼 𝗽𝗼𝘀𝘁𝘀 𝘄𝗲 𝘂𝗻𝗱𝗲𝗿𝘀𝘁𝗼𝗼𝗱: • Why Java is Platform Independent • How JDK, JRE, and JVM work together to run a Java program Now it's time to move from 𝘁𝗵𝗲𝗼𝗿𝘆 → 𝗮𝗰𝘁𝘂𝗮𝗹 𝗰𝗼𝗱𝗲. 𝗟𝗲𝘁’𝘀 𝘄𝗿𝗶𝘁𝗲 𝗮 𝘀𝗶𝗺𝗽𝗹𝗲 𝗝𝗮𝘃𝗮 𝗽𝗿𝗼𝗴𝗿𝗮𝗺. ``` 𝚙𝚞𝚋𝚕𝚒𝚌 𝚌𝚕𝚊𝚜𝚜 𝙷𝚎𝚕𝚕𝚘𝚆𝚘𝚛𝚕𝚍 { 𝚙𝚞𝚋𝚕𝚒𝚌 𝚜𝚝𝚊𝚝𝚒𝚌 𝚟𝚘𝚒𝚍 𝚖𝚊𝚒𝚗(𝚂𝚝𝚛𝚒𝚗𝚐[] 𝚊𝚛𝚐𝚜) { 𝚂𝚢𝚜𝚝𝚎𝚖.𝚘𝚞𝚝.𝚙𝚛𝚒𝚗𝚝𝚕𝚗("𝙷𝚎𝚕𝚕𝚘 𝚆𝚘𝚛𝚕𝚍"); } } ``` At first glance this may look confusing. But if we break it down, the structure becomes very simple. 𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲 𝗼𝗳 𝗮 𝗝𝗮𝘃𝗮 𝗣𝗿𝗼𝗴𝗿𝗮𝗺 Every Java program generally contains: 1️⃣ 𝗖𝗹𝗮𝘀𝘀 𝗗𝗲𝗰𝗹𝗮𝗿𝗮𝘁𝗶𝗼𝗻 𝚙𝚞𝚋𝚕𝚒𝚌 𝚌𝚕𝚊𝚜𝚜 𝙷𝚎𝚕𝚕𝚘𝚆𝚘𝚛𝚕𝚍 In Java, everything starts with a class. The filename must match the class name. Example: 𝙷𝚎𝚕𝚕𝚘𝚆𝚘𝚛𝚕𝚍.𝚓𝚊𝚟𝚊 2️⃣ 𝗠𝗮𝗶𝗻 𝗠𝗲𝘁𝗵𝗼𝗱 𝚙𝚞𝚋𝚕𝚒𝚌 𝚜𝚝𝚊𝚝𝚒𝚌 𝚟𝚘𝚒𝚍 𝚖𝚊𝚒𝚗(𝚂𝚝𝚛𝚒𝚗𝚐[] 𝚊𝚛𝚐𝚜) This is the entry point of every Java program. When we run a program, the JVM starts execution from the 𝗺𝗮𝗶𝗻() 𝗺𝗲𝘁𝗵𝗼𝗱. 3️⃣ 𝗦𝘁𝗮𝘁𝗲𝗺𝗲𝗻𝘁𝘀 𝚂𝚢𝚜𝚝𝚎𝚖.𝚘𝚞𝚝.𝚙𝚛𝚒𝚗𝚝𝚕𝚗("𝙷𝚎𝚕𝚕𝚘 𝚆𝚘𝚛𝚕𝚍"); This statement simply prints output on the console. 𝗡𝗼𝘄 𝗹𝗲𝘁’𝘀 𝘂𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱 𝘀𝗼𝗺𝗲𝘁𝗵𝗶𝗻𝗴 𝘃𝗲𝗿𝘆 𝗶𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁 𝗶𝗻 𝗝𝗮𝘃𝗮. 𝗝𝗮𝘃𝗮 𝗧𝗼𝗸𝗲𝗻𝘀 Tokens are the smallest building blocks of a Java program. Java programs are basically made up of tokens. 𝗧𝗵𝗲𝗿𝗲 𝗮𝗿𝗲 𝗺𝗮𝗶𝗻𝗹𝘆 𝟱 𝘁𝘆𝗽𝗲𝘀: • 𝗞𝗲𝘆𝘄𝗼𝗿𝗱𝘀 → public, class, static, void • 𝗜𝗱𝗲𝗻𝘁𝗶𝗳𝗶𝗲𝗿𝘀 → names of variables, classes, methods • 𝗟𝗶𝘁𝗲𝗿𝗮𝗹𝘀 → actual values (10, "Hello", true) • 𝗦𝗲𝗽𝗮𝗿𝗮𝘁𝗼𝗿𝘀 → { } ( ) [ ] ; , • 𝗢𝗽𝗲𝗿𝗮𝘁𝗼𝗿𝘀 → + - * / = == Example identifier rules: ✔ Cannot start with a number ✔ Cannot use Java keywords ✔ No spaces allowed ✔ Can use letters, numbers, _ and $ Once you understand structure + tokens, reading Java code becomes much easier. If you look at the Java program again, you’ll now notice: It is simply a combination of tokens working together. Once you understand tokens and structure, reading Java code becomes much easier. 𝗧𝗼𝗺𝗼𝗿𝗿𝗼𝘄 (𝗗𝗮𝘆 𝟰) 𝗪𝗲’𝗹𝗹 𝗴𝗼 𝗱𝗲𝗲𝗽𝗲𝗿 𝗶𝗻𝘁𝗼 𝗼𝗻𝗲 𝗼𝗳 𝘁𝗵𝗲 𝗺𝗼𝘀𝘁 𝗶𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁 𝘁𝗼𝗽𝗶𝗰𝘀 𝗶𝗻 𝗝𝗮𝘃𝗮: • Data Types • Variables • Primitive vs Non-Primitive types • Memory basics behind variables Because before writing real programs, understanding how Java stores data is critical. 𝗦𝗲𝗲 𝘆𝗼𝘂 𝗶𝗻 𝗗𝗮𝘆 𝟰. #Java #BackendDevelopment #Programming #LearnInPublic #Day3

💡 Sneaky Throws in Java — A Lesser-Known Exception Handling Trick Java’s exception system distinguishes between checked and unchecked exceptions. Normally, checked exceptions like IOException must be either caught or declared in the method signature using throws. But there is an interesting technique called Sneaky Throws that allows a method to throw a checked exception without declaring it. 🔎 How does it work? The trick relies on Java generics and type erasure. A generic method can be written like this: public static <E extends Throwable> void sneakyThrow(Throwable e) throws E { throw (E) e; } At compile time, the compiler infers E as an unchecked type (often RuntimeException). However, at runtime the JVM simply executes the throw instruction and throws the actual exception object. ⚙️ Why developers use it Sneaky throws is sometimes useful when dealing with: Lambda expressions Streams Functional interfaces that don’t allow checked exceptions Utility libraries that want to reduce boilerplate try-catch blocks Example use case: private static void throwSneakyIOException() { sneakyThrow(new IOException("Sneaky exception")); } The method does not declare throws IOException, yet it will still throw it at runtime. ⚠️ Why it’s controversial While powerful, it breaks the normal exception contract of Java: Method signatures no longer reveal possible checked exceptions Harder for callers to know what to handle Can reduce code clarity Because of this, many teams avoid it in public APIs. 📦 Libraries like Project Lombok even provide an annotation for it: @SneakyThrows ✅ Takeaway Sneaky throws demonstrates an interesting reality of Java: The compiler enforces checked exceptions, but the JVM does not distinguish them at runtime. It’s a clever trick that shows how generics, type inference, and the JVM execution model interact under the hood. #Java #ExceptionHandling #JavaInternals #BackendDevelopment #SoftwareEngineering

🚀 Day 35 – Core Java | Super Keyword, Method Types in Inheritance & Access Modifiers Today’s session connected multiple important concepts in Java Inheritance and clarified how classes interact with each other in real programs. 🔹 Super Keyword When both parent and child classes have the same variable or method, Java gives priority to the child class. To access the parent class version, Java provides the super keyword. Example: super.variableName super.methodName() ✔ Used to access parent variables ✔ Used to call parent methods Important difference: super() → used for constructor chaining super keyword → used to access parent properties and behaviors 🔹 Constructor Chaining Recap Constructor chaining can happen in two ways: 1️⃣ Within the same class this() 2️⃣ Between parent and child classes super() Important rule: Both this() and super() must be the first line of a constructor, so they cannot be used together in the same constructor. 🔹 Types of Methods in Inheritance In inheritance, methods fall into three categories: 1️⃣ Inherited Methods Methods that the child class directly acquires from the parent without any modification. Example: takeoff() land() 2️⃣ Overridden Methods Methods that the child class inherits and then modifies. Example: fly() Each plane type flies differently. Java uses: @Override This annotation helps: Documentation Detecting coding mistakes 3️⃣ Specialized Methods Methods created only in the child class. Example: carryCargo() carryPassengers() carryWeapons() These methods do not exist in the parent class. 🔹 Real Example Used in Class We designed a Plane system using inheritance. Parent Class: Plane Methods: takeoff() fly() land() Child Classes: CargoPlane PassengerPlane FighterPlane Each child: inherits takeoff() and land() overrides fly() adds specialized methods This demonstrated how code reuse reduces development effort. 🔹 Access Modifiers in Java To understand inheritance properly, we also explored Access Modifiers. Key observation: Public → Maximum visibility Private → Minimum visibility Visibility decreases in this order: public → protected → package access → private 💡 Biggest Takeaway Understanding inheritance is not just about writing extends. It requires clarity about: Constructor chaining Method overriding Code reuse Access control Class relationships These concepts are fundamental before moving to the next pillar of OOP – Polymorphism. #Day35 #CoreJava #Inheritance #SuperKeyword #MethodOverriding #JavaOOP #AccessModifiers #DeveloperJourney

Java 26 is released today. Brief look at some of its highlights 1. Performance & JVM Improvements G1 GC: Improve Throughput (JEP 522): This update reduces synchronization between application and garbage collector threads. Improves throughput by 5–15% for write-heavy applications and slightly decreases pause times. Ahead-of-Time (AOT) Object Caching (JEP 516): Building on Project Leyden, this allows the JVM to cache pre-initialized objects in a GC-agnostic format. It significantly accelerates application startup and "warm-up" times across all garbage collectors, including ZGC. G1 Humongous Object Reclamation: G1 now more eagerly reclaims "humongous" objects (those taking up >50% of a region) even if they contain references, which helps reduce heap pressure. 2. Core Library & Networking HTTP/3 Support (JEP 517): The HttpClient API now supports HTTP/3. This allows developers to take advantage of the performance and reliability benefits of QUIC with minimal code changes. PEM Encodings of Cryptographic Objects (JEP 524): Currently in its second preview, this provides a standard API for encoding and decoding cryptographic keys and certificates into the PEM format, including support for encrypted KeyPairs. Vector API (JEP 529): Now in its 11th incubator phase, this API allows developers to write vector computations that the JIT compiler can translate into optimal SIMD instructions, which is crucial for AI and data-heavy applications. 3. Language & Modernization Primitive Types in Patterns (JEP 530): This 4th preview allows primitive types to be used in instanceof and switch pattern matching. It removes previous restrictions, making code more uniform and reducing friction when working with primitives. Prepare to Make Final Mean Final (JEP 500): This is a foundational change to how the JVM handles final fields. It aims to prohibit the modification of final fields via reflection, which currently generates a warning but will eventually lead to an exception. Lazy Constants (JEP 526): In its second preview, this introduces "Stable Values"—constants that are computed lazily and then remain immutable, providing a thread-safe and efficient alternative to existing lazy-initialization patterns. 4. Deprecations & Removals Removal of the Applet API (JEP 504): The long-deprecated Applet API has been fully removed from the JDK, reducing the footprint and cleaning up legacy security risks. https://lnkd.in/gxh9GCUG #java26