Java Reserved Keywords: 67 in Total, But How Many Do You Use Daily?

🛡️ Shipped a major upgrade to AI-MR-Reviewer — a GitHub App that reviews your Java pull requests the moment you open them. Inline comments on the diff. Three severity levels. Zero configuration. Built for teams who want fast feedback without setting up SonarQube. What lands in this release: 19 hand-tuned Java rules. 🔴 HIGH RISK — 9 rules - Empty catch blocks (silent exception swallowing) - printStackTrace() in production code - Broad catches — Exception / Throwable / RuntimeException - SQL injection in createQuery / prepareStatement (concat + String.format) - Hardcoded credentials (password / apiKey / authToken) - Thread.sleep() in non-test code - Resource leaks — FileReader / Socket without try-with-resources - String compared with == instead of .equals() - Raw generics — new ArrayList() without the diamond operator 🟡 MID RISK — 5 rules - System.out / System.err in production - Magic strings in local assignments - PascalCase class / interface / enum naming - Methods with more than 5 parameters (god-method signal) - new Date() — prefer java.time (Instant, LocalDateTime) 🔵 LOW RISK — 5 rules - Numbered method names (toResponse2, handler3) - Wildcard imports (import java.util.*) - Missing Javadoc on public API surfaces (Service / Controller / Facade) - Unresolved TODO / FIXME / HACK comments - Files left behind as "ClassName copy.java" Every rule is tuned for a low false-positive rate. JPA/Spring annotation attributes are whitelisted, so @Table(name = "user") will never show up as a "magic string". Common numeric suffixes — sha256, base64, int32, ipv4 — are excluded from the numbered-method rule. Under the hood: TypeScript · Node.js · Octokit · Express · Docker. Deployed on Hostinger. Reviews land within seconds of opening the PR. Next up: the same treatment for Python and PHP, plus a semantic layer on top of the regex foundation — equals()/hashCode() pairing, Optional misuse detection, and blocking calls inside reactive chains. If your team reviews Java PRs every day, this saves an hour per dev per week. DMs open. #Java #SpringBoot #CodeReview #DeveloperTools #StaticAnalysis #OpenSource #DevEx

Day 15 — #100DaysJava three things in one day. Collections, DSA, and JUnit revision. ☕ Some days you just lock in. ----------------------------- Thing 1 — Collections detail I never knew I always used ArrayList without thinking. Today I learned there are actually three different ways to create a list in Java and they behave completely differently. Arrays.asList() — fixed size. You can update values but you cannot add or remove. Most people think it works like ArrayList. It does not. List.of() — completely immutable. Nothing can change. Not even the values. And it does not allow null. This is the safest option when you want data that should never change. ArrayList — fully dynamic. Add, remove, update — everything works. This is what you use when the data needs to change. One line to remember: Arrays.asList = fixed, List.of = immutable, ArrayList = flexible. Small difference. Huge impact in interviews and real code. --- Thing 2 — Queue in Java (DSA) Queue follows FIFO — First In, First Out. Like a line at a ticket counter. First person in line gets served first. Three ways to use Queue in Java: LinkedList — simple, most common PriorityQueue — automatically sorts elements, smallest comes out first ArrayDeque — fastest, preferred in interviews The method pairs every Java developer should know: offer() vs add() — offer is safe, add throws exception if it fails poll() vs remove() — poll returns null if empty, remove throws exception peek() vs element() — peek returns null if empty, element throws exception Always use the safe version — offer, poll, peek. Problems I practiced: Reverse a queue using a stack Generate binary numbers using a queue Implement queue using two stacks --- Thing 3 — JUnit 5 revision Went back through everything from Day 13 and 14. Rewrote test cases for Calculator and String utilities from scratch without looking at notes. The AAA pattern is now muscle memory — Arrange, Act, Assert. Also revised edge cases — null inputs, empty strings, boundary values. This is where real bugs hide. --- 15 days in. The concepts are connecting now. DSA problems feel less scary when you understand the data structures behind them. If you are learning Java — save this post. Arrays.asList vs List.of vs ArrayList comes up in almost every Java interview. 📌 Day 1 ........................................Day 15 ✅ What DSA topic do you find hardest to crack in interviews? Drop it below — let us discuss! 🙏 #Java #DSA #DataStructures #Queue #Collections #JUnit #100DaysOfJava #JavaDeveloper #LearningInPublic #BackendDevelopment #100DaysOfCode #InterviewPrep #CodingInterview

Created 1 million objects. App crashed with OutOfMemoryError. Nobody understood why. 😱 Java Fundamentals A-Z | Post 25 Can you spot the bug? 👇 public void processTransactions() { for (int i = 0; i < 1000000; i++) { Transaction t = new Transaction(); // 💀 Heap! t.setId(i); t.process(); // t goes out of scope // But GC hasn't cleaned yet! 💀 } } // Result → OutOfMemoryError! 💀 // Heap filled faster than GC could clean! Every new Transaction() goes to Heap. GC couldn’t keep up. Understanding Stack vs Heap prevents this! 💪 Here’s how Java memory actually works 👇 public void calculate() { // ✅ Stack — primitive, fast, auto-cleaned! int x = 10; // Stack double rate = 0.05; // Stack boolean isValid = true; // Stack // ⚠️ Heap — objects, slower, needs GC! String name = new String("DBS"); // Heap List<Integer> nums = new ArrayList<>(); // Heap // ✅ Fix — reuse objects where possible! StringBuilder sb = new StringBuilder(); for (int i = 0; i < 1000000; i++) { sb.setLength(0); // ✅ Reuse — no new Heap allocation! sb.append("Transaction: ").append(i); } } Fixed batch job OutOfMemoryError by reusing objects instead of creating new ones in loop. Memory usage dropped 60%. 🔥 Stack vs Heap cheat sheet 👇 — Stack → primitives, method calls, references — fast, auto-cleaned — Heap → all objects — slower, needs Garbage Collector — Stack overflow → too many method calls (infinite recursion!) — OutOfMemoryError → too many objects in Heap — Solution → reuse objects, avoid new inside loops! Summary: 🔴 Creating new objects inside million-iteration loops 🟢 Reuse objects — Stack for primitives, Heap wisely for objects! 🤯 60% memory reduction by just reusing StringBuilder in batch job! Have you faced OutOfMemoryError in production? Drop a 🧠 below! #Java #JavaFundamentals #BackendDevelopment #LearningInPublic #SDE2

I spent my first 2 years writing Java the hard way. Verbose. Fragile. Full of boilerplate I didn't need. Then I discovered these 5 features — and I've never looked back. If you're a Java developer, save this post. 🔖 --- 1. Optional — stop pretending null doesn't exist How many NullPointerExceptions have you chased at midnight? I lost count. Then I started using Optional properly. Before: String city = user.getAddress().getCity(); // NPE waiting to happen After: Optional.ofNullable(user) .map(User::getAddress) .map(Address::getCity) .orElse("Unknown"); Clean. Safe. Readable. No more defensive if-null pyramids. --- 2. Stream API — ditch the for-loops I used to write 15-line loops to filter and transform lists. Streams cut that to 2 lines — and made the intent crystal clear. Before: List<String> result = new ArrayList<>(); for (User u : users) { if (u.isActive()) result.add(u.getName()); } After: List<String> result = users.stream() .filter(User::isActive) .map(User::getName) .collect(toList()); Once you think in streams, you can't go back. --- 3. Records — goodbye boilerplate data classes How many times have you written a POJO with getters, setters, equals, hashCode, and toString? Java Records (Java 16+) killed all of that in one line. Before (~50 lines): public class User { private String name; private String email; // getters, setters, equals, hashCode, toString... 😩 } After (1 line): public record User(String name, String email) {} Your DTOs and value objects will thank you. --- 4. var — let the compiler do the obvious work I was skeptical at first. Felt "un-Java-like." But for local variables, var makes code dramatically less noisy. Before: HashMap<String, List<Order>> map = new HashMap<String, List<Order>>(); After: var map = new HashMap<String, List<Order>>(); Still strongly typed. Just less noise. Use it for local scope — not method signatures. --- 5. CompletableFuture — async without the headache Threading used to terrify me. CompletableFuture changed that. Chain async tasks, handle errors, combine results — all without callback hell. CompletableFuture.supplyAsync(() -> fetchUser(id)) .thenApply(user -> enrichWithOrders(user)) .thenAccept(result -> sendResponse(result)) .exceptionally(ex -> handleError(ex)); Readable async Java. Yes, it's possible. --- I wasted months writing verbose, fragile code because nobody told me these existed. Now you have no excuse. 😄 Which of these changed your code the most? Drop a number (1–5) in the comments 👇 — I read every one. #Java #SoftwareEngineering #FullStackDeveloper #CleanCode #SpringBoot #CodingTips

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

🚨 𝗥𝗲𝗮𝗹 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻 𝗜𝗻𝘁𝗲𝗿𝘃𝗶𝗲𝘄𝘀 (𝗟𝟭 + 𝗟𝟮) – 𝗔𝗰𝘁𝘂𝗮𝗹 𝗤𝘂𝗲𝘀𝘁𝗶𝗼𝗻𝘀 🔹 𝗖𝗢𝗥𝗘 𝗝𝗔𝗩𝗔 / 𝗕𝗔𝗦𝗜𝗖𝗦 👉 What is Java? 👉 Your understanding of Java in project? 👉 static vs final? 👉 Access modifiers in Java (explain)? 👉 StringBuilder vs StringBuffer 👉 Why String immutable? 👉 Multiple catch with one try? 👉 Exceptions faced & handling 👉 Collections & usage? 👉 List vs Set vs HashMap 👉 Is StringBuilder thread-safe? 🔹 💻 𝗖𝗢𝗗𝗜𝗡𝗚 👉 Occurrence of chars/words 👉 Duplicates in array 👉 ArrayList → Set 👉 Compare two ArrayLists 👉 Merge lists 👉 Store mixed data 🔹 🌐 𝗦𝗘𝗟𝗘𝗡𝗜𝗨𝗠 / 𝗨𝗜 👉 Waits types 👉 Explicit wait usage 👉 enable keyword? 👉 findElement vs findElements 👉 If element not found? 👉 Dynamic dropdown 👉 Hidden elements 👉 Multiple windows (switch back) 👉 iFrames handling 👉 Page load check? 👉 getText vs getAttribute vs getTitle 👉 Action vs Actions 👉 XPath using class/role 👉 Multiple match → pick middle 👉 Scroll vs JS Executor (why) 👉 Count iframes (no XPath/iframe tag)? 👉 What you understood from your framework? 🔹 🧩 𝗙𝗥𝗔𝗠𝗘𝗪𝗢𝗥𝗞 / 𝗧𝗘𝗦𝗧𝗡𝗚 👉 POM (explain) 👉 POM vs Page Factory 👉 Singleton pattern 👉 TestNG annotations 👉 Priority & order 👉 dependsOn 👉 enabled 👉 Run specific test 👉 One test, multiple data 👉 Skip few DataProvider rows 👉 DataProviders usage 👉 Listeners (why) 👉 Rerun failed tests 👉 Extent Reports design 👉 Screenshot on failure 👉 Attach screenshots to report 🔹 🎭 𝗕𝗗𝗗 / 𝗣𝗟𝗔𝗬𝗪𝗥𝗜𝗚𝗛𝗧 👉 monochrome tag 👉 Background 👉 Feature ↔ step mapping 👉 Dynamic data in feature 👉 BDD execution start 👉 Feature for valid/invalid login 👉 Repeat step multiple times 👉 async/await in Playwright 👉 Fixtures (familiar?) 👉 What are fixtures? 👉 Setup Playwright (TypeScript) steps 👉 Multiple windows 🔹 🔗 𝗔𝗣𝗜 / 𝗦𝗤𝗟 👉 API testing experience 👉 Tools (Postman, Rest Assured) 👉 API automation flow 👉 AuthN vs AuthZ 👉 Handling authentication 👉 JSON validation 👉 SQL experience 👉 Basic SQL queries 🔹 ⚙️ 𝗠𝗔𝗩𝗘𝗡 / 𝗣𝗥𝗢𝗝𝗘𝗖𝗧 👉 Project structure 👉 pom.xml 👉 Maven lifecycle 👉 Plugins 👉 pom.xml issues 👉 Dependencies location? 🔹 🔁 𝗚𝗜𝗧 / 𝗖𝗜𝗖𝗗 👉 Push steps 👉 Pull steps 👉 pull vs fetch 👉 Resolve merge conflicts 👉 Avoid conflicts 👉 Commit messages 👉 Run tests (local/CI) 👉 Jenkins 👉 Cross-browser 👉 Multi-environment runs 🧠 𝗥𝗘𝗔𝗟-𝗧𝗜𝗠𝗘 👉 Element not found → approach 👉 Hidden element → solution 👉 Parallel data overlap → fix 👉 Skip specific data 👉 Dynamic IDs 🔹 🤖 𝗔𝗜 / 𝗘𝗫𝗣𝗘𝗥𝗜𝗘𝗡𝗖𝗘 👉 AI tools (Copilot, AI Hub, ChatPwC) 👉 Usage in project 👉 GitHub Copilot exp 👉 Roles & responsibilities 👉 Framework end-to-end 💬 𝗙𝗶𝗻𝗮𝗹 𝗧𝗵𝗼𝘂𝗴𝗵𝘁: 𝗜𝘁’𝘀 𝗻𝗼𝘁 “𝗪𝗵𝗮𝘁 𝘆𝗼𝘂 𝗸𝗻𝗼𝘄” → 𝗶𝘁’𝘀 “𝗛𝗼𝘄 𝘆𝗼𝘂 𝗮𝗽𝗽𝗹𝘆 𝗶𝘁” #AutomationTesting #Selenium #Playwright #TestNG #API #QA #SoftwareTesting #CareerGrowth

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

🛑 #Stop blindly using ArrayList<T>() and understand why ConcurrentModificationException is your friend. As Java developers, we use the Collection Framework daily. But we rarely stop to consider how it actually works under the hood—and that affects performance. Choosing the right structure—like ArrayList versus LinkedList—impacts your application’s speed and memory usage. This diagram visualizes how Java manages that data internally. Let’s break it down using real code: 1. ArrayList and the Cost of Dynamic Resizing ArrayList is excellent for random access, but it has to manage an underlying array. When it reaches capacity, Java must create a new, larger array and copy all the data over—an O(n) operation. The diagram shows: ArrayList -> Check Capacity -> Dynamic Resize -> MEMORY (Heap) How it looks in Java: import java.util.ArrayList; import java.lang.reflect.Field; public class ArrayListResizingDemo { public static void main(String[] args) throws Exception { // We initialize with a specific size. ArrayList<String> list = new ArrayList<>(5); System.out.println("1. New ArrayList created with capacity 5."); checkInternalCapacity(list); // Fill it up. The internal array size (5) matches the element count (5). System.out.println("\n2. Filling up capacity..."); for (int i = 0; i < 5; i++) { list.add("Element " + (i + 1)); } checkInternalCapacity(list); // The next addition triggers "Dynamic Resize." System.out.println("\n3. Adding the 6th element (triggers dynamic resize)..."); list.add("Element 6"); // The underlying array has now grown (~50%). checkInternalCapacity(list); } /** Helper function (uses Reflection, not for production!). */ private static void checkInternalCapacity(ArrayList<?> list) throws Exception { Field dataField = ArrayList.class.getDeclaredField("elementData"); dataField.setAccessible(true); Object[] internalArray = (Object[]) dataField.get(list); System.out.println(" --> Current internal array size: " + internalArray.length); System.out.println(" --> Number of actual elements stored: " + list.size()); } } #java #springboot

💡 Why do we need forEach() in Java 8 when we already have loops? Java has always supported iteration using traditional loops. But with Java 8, forEach() was introduced to align with functional programming and stream processing. Let’s break it down 👇 🔹 1. Traditional for Loop for(int i = 0; i < arr.length; i++){ System.out.println(arr[i]); } ✅ Gives full control using index ✅ Supports forward & backward traversal ✅ Easy to skip elements or modify logic ⚠️ Downside: You must manage indexes manually, which can lead to errors like ArrayIndexOutOfBoundsException ------------------------------------------------------------------------------ 🔹 2. Enhanced for-each Loop for(int num : numbers){ System.out.println(num); } ✅ Cleaner and simpler syntax ✅ No need to deal with indexes ⚠️ Limitation: Only forward iteration No direct access to index ------------------------------------------------------------------------------ 🔹 3. Java 8 forEach() (Functional Approach) Arrays.stream(numbers) .forEach(num -> System.out.println(num)); 👉 Even more concise: Arrays.stream(numbers) .forEach(System.out::println); ✅ Encourages functional programming ✅ Works seamlessly with Streams API ✅ More expressive and readable ✅ Can be used with parallel streams for better performance ------------------------------------------------------------------------------ 🔍 What happens internally? forEach() is a default method in the Iterable interface It takes a Consumer functional interface The lambda you provide is executed via: void accept(T t); ------------------------------------------------------------------------------ 🚀 Final Thought While traditional loops are still useful, forEach() brings a declarative and modern way of iterating data — especially when working with streams. #Java #Java8 #Programming #Developers #Coding #FunctionalProgramming

How the JVM Actually Runs Your Java Code After years of building Java services, one thing I’ve noticed is that most developers interact with the JVM every day, but rarely think about what actually happens between compiling code and running it in production. Behind the scenes, the JVM goes through several stages to safely and efficiently execute Java applications. Here’s the simplified flow 👇 1️⃣ Build The Java compiler (javac) converts .java source files into platform-independent bytecode stored in: • .class files • JAR archives • Java modules This layer is what allows Java applications to run on any platform with a JVM. 2️⃣ Load The Class Loader Subsystem dynamically loads classes when needed using the parent delegation model: • Bootstrap Class Loader → loads core JDK classes • Platform Class Loader → loads platform libraries • System Class Loader → loads application classes This mechanism improves security and prevents duplicate class loading. 3️⃣ Link Before execution, the JVM links the class through three steps: • Verify → ensures bytecode safety • Prepare → allocates memory for static variables • Resolve → converts symbolic references to direct memory references 4️⃣ Initialize The JVM assigns values to static variables and executes static initializer blocks. This step occurs only once when the class is first used. 5️⃣ Runtime Memory Areas Shared across threads: • Heap → object storage • Method Area → class metadata • Runtime Constant Pool Per thread: • JVM Stack → method frames & local variables • Program Counter (PC) → execution pointer • Native Method Stack The Garbage Collector continuously reclaims unused heap memory. 6️⃣ Execution Engine The JVM executes code using two mechanisms: • Interpreter → executes bytecode directly • JIT Compiler → compiles frequently used methods into optimized machine code Compiled code is stored in the Code Cache, improving performance over time. 7️⃣ Native Integration When Java needs system-level access, it uses JNI (Java Native Interface) to call C/C++ native libraries. 💡 What makes the JVM powerful is its hybrid execution model: • platform-independent bytecode • managed memory with garbage collection • secure class loading • runtime optimization with JIT This is why Java continues to power many large-scale backend systems. 🔍 Production insight If you’ve ever seen: • slow startup times • GC pauses • class loading conflicts • performance improving after warm-up those behaviors are directly tied to how the JVM executes and optimizes code at runtime. Understanding these internals makes debugging and performance tuning far easier. #Java #JVM #JavaDeveloper #BackendEngineering #SoftwareArchitecture #SystemDesign #PerformanceEngineering #DistributedSystems #JavaInternals