Java: When to Use == vs .equals() for Object Comparison

Java Practice — Palindrome Check Using Streams Today I revisited a small but powerful problem: checking if a string is a palindrome — this time using Java Streams for a more functional approach. Here’s the snippet I practiced: import java.util.stream.IntStream; public class PalindromeWithStreams {   public static void main(String[] args) {     String s = "madam";          boolean isPalindrome = IntStream.range(0, s.length() / 2)         .allMatch(i -> s.charAt(i) == s.charAt(s.length() - i - 1));     System.out.println(isPalindrome ? "Palindrome" : "Not palindrome");   } } > Key takeaway: 1: IntStream.range(0, s.length() / 2) generates indices for only half the string. 2: .allMatch() ensures every pair of characters (from front and back) are equal. 3: Clean, concise, and expressive — a great example of functional programming in modern Java. #Java #Streams #CodingPractice #ProblemSolving #CleanCode #DevelopersJourney

Checked vs unchecked exceptions in Java:- The primary difference between checked and unchecked exceptions in Java lies in whether the compiler forces you to handle them. 🧐 Checked Exceptions Definition: These are exceptions that are checked at compile time. The Java compiler ensures that a program either handles them (using a try-catch block) or declares them (using the throws keyword in the method signature). Inheritance: They generally inherit from the java.lang.Exception class (excluding RuntimeException and its subclasses). Purpose: They represent situations that are typically recoverable and outside the direct control of the programmer, such as issues with I/O, database connections, or network access. The program is expected to anticipate and handle these errors. Examples: IOException, SQLException, FileNotFoundException. 🚫 Unchecked Exceptions Definition: These are exceptions that are not checked at compile time. The compiler does not force you to handle or declare them. Inheritance: They inherit from the java.lang.RuntimeException class or its subclasses, and also from java.lang.Error. Purpose: They usually represent programming errors or defects (logic errors) that often cannot be reasonably recovered from at runtime, such as passing a null argument or accessing an array index out of bounds. The expectation is that the code should be fixed to prevent these. Examples: NullPointerException, ArrayIndexOutOfBoundsException, IllegalArgumentException, ArithmeticException. #java #corejava #automationtesting #fullstackdevelopmment

#day96 The Hidden Workings of Java’s Object Class The Object class in Java is the root class of the class hierarchy. Every class implicitly inherits from Object unless explicitly stated otherwise. All classes in Java inherit from java.lang.Object. In Java, object memory allocation involves several steps: Class Loading: The JVM loads the class definition into memory. Object Creation: When new is called, the JVM allocates memory for the object on the heap. Field Initialization: All fields are set to default values (e.g., 0 for int, null for objects). Constructor Execution: The constructor initializes fields as specified. Reference Assignment: The reference variable points to the object's memory address. Common Object methods include: toString(): Returns a string representation of the object. equals(Object obj): Checks if two objects are equal. hashCode(): Returns a hash code for the object. getClass(): Returns the runtime class of the object. clone(): Creates and returns a copy of the object (if Cloneable). finalize(): Called by the garbage collector before object destruction. notify(), notifyAll(), wait(): Used for thread synchronization. The JVM manages memory using the heap for objects and the stack for references and method calls. Garbage collection automatically frees memory when objects are no longer referenced #JVM #ANDROID #jvm_internal #java #android_automotive #androidautomotive #androidmiddleware #android_os #android_internals Author: Sairamkrishna Mammahe - Seeking Opportunities in Android OS Development

💡 String vs. StringBuffer: Why Mutability Matters in Java 📝 When working with text in Java, understanding the core difference between String and StringBuffer—Mutability—is key to writing efficient code. 1. String (Immutable) Immutability: Once a String object is created, its value cannot be changed. Behavior: Any operation that appears to modify a String (like concatenation using the + operator) actually creates a brand new String object in the Heap memory. Performance: This continuous creation of new objects is slow and consumes extra memory, especially when concatenating strings repeatedly within a loop. Use Case: Ideal for storing text that is constant and will not change (e.g., names, final identifiers, or configuration values). 2. StringBuffer (Mutable & Synchronized) Mutability: The value of a StringBuffer object can be changed in the same memory location. Behavior: Methods like append(), insert(), or delete() modify the sequence of characters directly within the existing object's allocated memory buffer. No new object is created for intermediate changes. Synchronization: StringBuffer is thread-safe (synchronized), meaning its methods can be safely used by multiple threads simultaneously without causing data corruption. Performance: Much faster than String for repeated text manipulation because it avoids the overhead of creating numerous temporary objects. Use Case: Ideal for text manipulation in a multi-threaded environment where concurrent access to the string data is a concern. The Golden Rule: If the text is constant, use String. If the text needs to be repeatedly changed (modified, appended, or inserted into), use StringBuffer. Thank you sir Anand Kumar Buddarapu,Saketh Kallepu,Uppugundla Sairam,Codegnan #Java #ProgrammingTips #String #StringBuffer #Codegnan

Mastering volatile in Java: Ensuring Thread-Safe Visibility Without Compromising Performance Deep Dive: volatile in Java Multithreading In concurrent Java applications, ensuring thread safety and memory visibility is critical. The volatile keyword is often misunderstood, so here’s a clear perspective. Purpose of volatile Guarantees visibility: A write to a volatile variable by one thread is immediately visible to others. Prevents caching inconsistencies: Threads always read the latest value from main memory. volatile boolean running = true;Limitations of volatile ❌ Does not ensure atomicity. Operations like counter++ remain non-thread-safe. ❌ Does not provide mutual exclusion. Use synchronized blocks or AtomicInteger for compound operations. ❌ Only applies guarantees to the volatile variable itself, not to other related variables.Practical Example in Spring Boot @Component public class BackgroundTask { private volatile boolean running = true; @Scheduled(fixedRate = 1000) public void task() { if (running) { // task logic } } public void stopTask() { running = false; } } Here, the volatile keyword ensures the flag update is immediately visible to the scheduled task, avoiding subtle synchronization issues.Takeaway: Use volatile for shared state that requires visibility guarantees, but for atomic operations or complex data structures, prefer Atomic classes or explicit synchronization. Understanding these nuances is essential for building robust, high-performance multithreaded applications in Java This makes it ideal for flags, signals, or implementing double-checked locking in singleton patterns. #Java #SpringBoot #Multithreading #Concurrency #DeveloperInsights #CleanCode

Understanding ClassCastException in Java Today I ran into a classic Java runtime exception: java.lang.ClassCastException 😅 At first, it seemed confusing — my code compiled perfectly, but crashed at runtime. After debugging, I realized the cause 👇 🧠 What it means ClassCastException occurs when we try to cast an object to a class, but the object is not actually an instance of that class. In simple terms: ✅ The code compiles fine ❌ But at runtime, Java refuses the cast and throws an exception 📦 Example Object obj = "Hello World"; // a String object Integer num = (Integer) obj; // trying to cast String to Integer This will throw: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer 🔹 How to Avoid Use instanceof before casting: if(obj instanceof Integer){ Integer num = (Integer) obj; } Use generics for type-safe collections: List<String> list = new ArrayList<>(); String str = list.get(0); // No cast needed 💬 Lesson Learned Even if the compiler is happy, the runtime JVM enforces type safety. Always ensure your object is of the correct type before casting. #Java #JavaDeveloper #SpringBoot #BackendDevelopment #Debugging #ErrorHandling #ProgrammingTips #SoftwareEngineering #CodeWithMe #LearningByDoing

🎯 Java Generics — Why They Matter If you’ve been writing Java, you’ve probably used Collections like List, Set, or Map. But have you ever wondered why List<String> is safer than just List? That’s Generics in action. What are Generics? Generics let you parameterize types. Instead of working with raw objects, you can define what type of object a class, method, or interface should work with. List<String> names = new ArrayList<>(); names.add("Alice"); // names.add(123); // ❌ Compile-time error Why use Generics? 1. Type Safety – Catch errors at compile-time instead of runtime. 2. Code Reusability – Write flexible classes and methods without losing type safety. 3. Cleaner Code – No need for casting objects manually. public <T> void printArray(T[] array) { for (T element : array) { System.out.println(element); } } ✅ Works with Integer[], String[], or any type — one method, many types. Takeaway Generics aren’t just syntax sugar — they make your Java code safer, cleaner, and more reusable. If you’re still using raw types, it’s time to level up! 🚀 ⸻ #Java #SoftwareEngineering #ProgrammingTips #Generics #CleanCode #TypeSafety #BackendDevelopment

💡 Understanding Java Garbage Collection (GC): Why You Shouldn’t Call It Manually In Java, Garbage Collection (GC) automatically manages memory by removing unused objects from the heap — one of the core reasons Java is called a “memory-safe” language. 🗑️ How It Works: The Memory Cycle The JVM runs the garbage collector in the background, freeing up memory when it detects objects that are no longer reachable. This process often involves checking different memory pools, like the Young and Old generations, to efficiently prioritize removing short-lived objects. ⚠️ Can We Call It Manually? Yes, we can request garbage collection by calling: System.gc(); or Runtime.getRuntime().gc(); However, this is just a request — the JVM may or may not execute GC immediately. 🛑 Why We Shouldn’t Call GC Manually 🚫 It can impact performance significantly, as GC is a heavy operation that typically involves a "Stop-The-World" pause for the application. 🚫 The JVM’s own memory manager is much smarter at deciding the best, least disruptive time to perform GC based on heap usage and object lifetime. 🚫 Frequent or forced GC calls can cause unnecessary CPU usage and latency spikes, especially in high-throughput production systems. 👉 In short: Let the JVM handle it! The automatic garbage collector is optimized for efficiency, and manual intervention often does more harm than good. #Java #GarbageCollection #JVM #Performance #CodingTips #MemoryManagement

Java Enums are far more powerful and versatile than just constants. One of the interesting thing I learned is that Java has dedicated implementations for EnumMap and EnumSet — and EnumMap is even faster than HashMap for enum keys. Following blog is worth a read: https://lnkd.in/dKRY2m47