Ramdane Oualitsen’s Post

🚦🧊 JAVA IMMUTABILITY: THE WORDS MOST DEVS MIX UP: Unmodifiable, Immutable, Shallowly/ Deeply immutable, final 🔸 TL;DR In Java, unmodifiable does not mean immutable. And final does not mean the object can’t change either. If you confuse terms like mutable, unmodifiable view, immutable, shallowly immutable, and deeply immutable, you can easily design APIs that look safe but still leak state and bugs. 👉 I put together a carousel cheat sheet to make this crystal clear. Swipe through it. 🔸 TAKEAWAYS ▪️ Mutable = state can change after creation ▪️ Unmodifiable = this reference blocks mutation, but backing data may still change ▪️ Immutable = state cannot change after construction ▪️ Shallowly immutable = outer object is fixed, inner objects may still mutate ▪️ Deeply immutable = the full reachable state is frozen ▪️ Collections.unmodifiableList(...) is not the same as List.copyOf(...) ▪️ final freezes the reference, not the object ▪️ Records are concise, but they are not automatically deeply immutable 🔸 WHY IT MATTERS A lot of Java codebases say “immutable” when they really mean “harder to mutate accidentally.” That shortcut creates confusion in code reviews, APIs, concurrency discussions, and interviews. Precise vocabulary = better design. And better design = fewer side effects, safer models, cleaner code. ☕ 🔸 SWIPE THE CAROUSEL I turned the whole taxonomy into a simple PPT carousel with: ▪️ one term per slide ▪️ code snippets ▪️ short explanations ▪️ the distinctions that actually matter in real projects 👉 Swipe the carousel and tell me: Which term do you think developers misuse the most: unmodifiable or immutable? #Java #JavaProgramming #SoftwareEngineering #CleanCode #BackendDevelopment #Programming #Developers #Architecture #CodeQuality #JavaDeveloper #TechEducation #CodingTips

Coming from a Java + Spring Boot background, I’ve built and consumed REST APIs for years. Recently, while experimenting with FastAPI, I stumbled upon a subtle but very interesting difference in how request routing works—and it genuinely made me pause and think. Consider this scenario: In FastAPI, if you define routes like: /books/{book_title} /books/harry and you place the dynamic route first, a request to /books/harry will be handled by the dynamic path, not the static one. Why? 👉 FastAPI resolves routes in the order they are defined. The first matching route wins—even if a more specific route exists later. As a Java developer, this felt counter‑intuitive at first. In Spring Boot, the framework does things differently: Routes are not resolved by order Spring calculates path specificity A static route like /books/harry will always win over /books/{bookTitle}, regardless of how methods are ordered So the same API behaves differently across frameworks—not because one is wrong, but because of different design philosophies: FastAPI / Python → explicit, developer‑controlled, minimal magic Spring Boot / Java → convention‑driven, framework‑managed, intelligent dispatching 📌 Key takeaway for me: When working with FastAPI, route ordering matters. Static routes should be defined before dynamic ones to avoid unexpected behavior. This small difference reinforced something important: Understanding the framework internals matters just as much as knowing the language. Learning new stacks like FastAPI as a Java developer has been both refreshing and humbling—and these nuances are what make the journey exciting. Curious to hear from others who’ve switched between ecosystems—what surprised you the most? #Java #SpringBoot #FastAPI #Python #BackendDevelopment #RESTAPI #LearningJourney #SoftwareEngineering

Most Java developers think switching to Kotlin means learning a whole new language. Here's the truth: 𝘆𝗼𝘂'𝗿𝗲 𝗮𝗹𝗿𝗲𝗮𝗱𝘆 𝟳𝟬% 𝘁𝗵𝗲𝗿𝗲, and the remaining 30% will make you wonder why you didn't switch sooner. First, embrace data classes. That 50-line Java POJO with equals, hashCode, toString, and getters? Gone. ```kotlin data class User(val name: String, val email: String, val age: Int) ``` That's it. One line. The compiler generates everything for you, and it's less error-prone than any IDE-generated boilerplate. Second, stop writing null checks everywhere. 𝗞𝗼𝘁𝗹𝗶𝗻'𝘀 𝘁𝘆𝗽𝗲 𝘀𝘆𝘀𝘁𝗲𝗺 𝗱𝗶𝘀𝘁𝗶𝗻𝗴𝘂𝗶𝘀𝗵𝗲𝘀 𝗻𝘂𝗹𝗹𝗮𝗯𝗹𝗲 𝗳𝗿𝗼𝗺 𝗻𝗼𝗻-𝗻𝘂𝗹𝗹𝗮𝗯𝗹𝗲 𝘁𝘆𝗽𝗲𝘀 𝗮𝘁 𝗰𝗼𝗺𝗽𝗶𝗹𝗲 𝘁𝗶𝗺𝗲. Instead of littering your code with `if (user != null)` chains, you get elegant safe calls like `user?.address?.city` and the Elvis operator `user?.name ?: "Unknown"`. Entire categories of NullPointerExceptions simply vanish. Third, learn extension functions early. They let you add methods to existing classes without inheritance. Need a utility method on String? Just write `fun String.isValidEmail(): Boolean` and call it naturally. No more StringUtils classes with static methods scattered across your codebase. The biggest mindset shift isn't syntax. 𝗜𝘁'𝘀 𝗮𝗰𝗰𝗲𝗽𝘁𝗶𝗻𝗴 𝘁𝗵𝗮𝘁 𝗹𝗲𝘀𝘀 𝗰𝗼𝗱𝗲 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗺𝗲𝗮𝗻𝘀 𝗺𝗼𝗿𝗲 𝗰𝗹𝗮𝗿𝗶𝘁𝘆. Kotlin rewards you for writing less. What was the single Kotlin feature that made you never want to go back to pure Java? #Kotlin #Java #AndroidDev #SoftwareEngineering #Programming

Your Java app didn’t crash because something broke. It crashed because it kept holding on. We’ve all been told this: Java has Garbage Collection… memory is handled for you. And that’s where the misunderstanding begins. Because GC doesn’t clean unused objects. It only cleans objects that are no longer reachable. So if somewhere in your system… → a static cache keeps growing → a ThreadLocal is never cleared → a listener is never removed Then those objects don’t die. They stay. And they keep everything they reference alive too. Nothing looks wrong. The code compiles. The system runs. The APIs respond. But underneath… 📈 memory keeps climbing 📈 objects keep accumulating 📈 pressure keeps building Until one day… it collapses. What makes this tricky is: This isn’t a typical bug. It’s not about logic. It’s about ownership. 👉 Who owns this object? 👉 When should it be released? 👉 Who is still holding the reference? Because in Java: Memory isn’t freed by the GC. It’s freed when your system lets go. I broke this down with a simple whiteboard + real scenarios. It’s one of those things… once you see it, you start noticing it everywhere. https://lnkd.in/etAYAswr #Java #MemoryLeak #GarbageCollection #SystemDesign #BackendEngineering #JVM #SpringBoot #Performance #Microservices #SoftwareEngineering #Coding #TechLeadership

🚨 Java is finally fixing “final” — and it’s a BIG deal for backend devs For years, we trusted this: final String name = "Alok"; 👉 Meaning: this value will never change But under the hood… that wasn’t always true 😶 Using reflection: Field f = User.class.getDeclaredField("name"); f.setAccessible(true); f.set(user, "Hacked"); 💥 Your "final" field could still be modified No error. No warning. (Yes, since JDK 5!) --- 🤯 Why was this allowed? Because popular frameworks relied on it: • Jackson / Gson → deserialization • Hibernate → entity hydration • Mockito → mocking • Old DI → field injection 👉 Reflection made it possible to break immutability --- 🚨 What’s changing now? With Java 26 (JEP 500): ➡️ “Prepare to Make Final Mean Final” ✔️ Today: You’ll see warnings ❌ Tomorrow: It will be blocked (error) --- ⚠️ Why this matters This is not just syntax — it impacts: 🔹 Thread safety (immutability = safe concurrency) 🔹 JVM optimizations (compiler trusts "final") 🔹 Security (no hidden mutation) --- 🛠️ What you should do NOW ✅ Prefer constructor injection private final Service service; public MyClass(Service service) { this.service = service; } ✅ Use immutable DTOs (Java Records) public record UserDTO(String name, int age) {} ✅ Update libraries (Jackson, Hibernate, Mockito) ✅ Run your app on newer Java & check warnings --- 💡 Final Thought 👉 “final” was never truly final… until now. And honestly — it’s about time. --- #Java #SpringBoot #Backend #JavaDeveloper #CleanCode #JVM #Programming #SoftwareEngineering

April 13, 2026 | Daily Dev Log Java split "isn't" into two tokens today. That sentence sounds wrong. Here's why it's completely logical. HackerRank — Java Tokens: A token = a continuous sequence of letters (A–Z, a–z) A separator = any character that is NOT a letter So when Java hits the apostrophe in "isn't": → isn = first token → t  = second token The regex that handles all separators: s.split("[ !,?._'@]+"); Breaking it down: → [ ] groups all separator characters → + means one or more in a row → trim() prevents empty strings at the start → Empty check handles all-whitespace input Input: He is a good boy, isn't he? Tokens: He is a good boy isn t he = 10 tokens One concept that looks simple until you hit the edge cases. trim() and the empty string check are what separate a passing solution from a failing one. Also today — the Todo App left the console. Yesterday it was pure JavaScript in a terminal. Today it runs in the browser with: → querySelector to grab DOM elements → addEventListener for add button → createElement to build new list items → Event delegation to handle delete → CSS red delete button The same logic from yesterday. The same array concept. Just connected to a real UI now. That is what DOM manipulation means — taking logic you already know and connecting it to what users actually see. posting daily until I'm hired. Open to opportunities in: Web Development | Java | Data Analytics | Cloud Computing #OpenToWork #Java #JavaScript #DOM #WebDevelopment #BuildInPublic #100DaysOfCode

🚀 Understanding Inheritance in Java: Building Scalable Object-Oriented Systems Inheritance is a foundational concept in Java that enables developers to create structured, reusable, and maintainable code by establishing relationships between classes. At its core, inheritance allows a subclass (child class) to acquire the properties and behaviors of a superclass (parent class) — promoting code reusability and logical design. 🔹 Why Inheritance Matters in Modern Development • Encourages code reuse, reducing redundancy • Enhances readability and maintainability • Supports scalable architecture design • Models real-world relationships effectively 🔹 Basic Example class Animal { void eat() { System.out.println("Eating..."); } } class Dog extends Animal { void bark() { System.out.println("Barking..."); } } In this example, the Dog class inherits the eat() method from Animal, while also defining its own behavior. 🔹 Types of Inheritance in Java • Single Inheritance • Multilevel Inheritance • Hierarchical Inheritance (Note: Java does not support multiple inheritance with classes to avoid ambiguity, but it can be achieved using interfaces.) 🔹 Key Concepts to Remember • extends keyword is used to inherit a class • super keyword allows access to parent class members • Inheritance represents an "IS-A" relationship (e.g., Dog is an Animal) 💡 Final Thought Mastering inheritance is essential for anyone aiming to build robust backend systems or work with frameworks like Spring. It forms the backbone of clean architecture and object-oriented design. 📌 I’ll be sharing more insights on Encapsulation, Polymorphism, and real-world Java applications soon. #Java #OOP #SoftwareEngineering #BackendDevelopment #CleanCode #Programming #Developers

Every language community deserves first-class auth tooling. JavaScript. Python. Go. Java. C#. Ruby. PHP. At FusionAuth we've been thinking a lot about the developer experience. Today we're shipping the FusionAuth Brainf SDK. It handles login, token refresh, user retrieval, registration, and user creation against a real FusionAuth instance - with real JWTs, real JSON parsing, and a real wire protocol built on ASCII control characters from 1963. A few implementation notes worth flagging before you evaluate it for production: ✅ The compiled output is 14.7 MB. This is normal. ✅ Arithmetic is implemented as repeated addition and repeated subtraction. This has no impact on correctness. ✅ Initialization time on an M4 Pro with 48 GB of RAM is approximately 28 hours. For a buffer. We believe this is technically correct behavior. ✅ "It is slow" is not a valid bug report. The SDK is available on GitHub now. The authentication is real. The JWTs are real. A user record in FusionAuth's database has been touched by a program written in Brainf. We have mixed feelings about this. A huge effort by Blair Ewalt to get this across the line.

Functional style in Java is easy to get subtly wrong. This post walks through the most common mistakes — from returning null inside a mapper to leaking shared mutable state into a stream — and shows how to fix each one. https://lnkd.in/ey-7r7BW

Seriously I am considering stop using Lombok in my new java projects. To be honest, It help quite a bit to avoid Boilerplate of code. Por ejemplo @Slf4j, @RequiredArgsConstructor, @Getter, @Setter, @Value, etc. But Lombok comes with trade-offs that compound over time: - Lombok hooks into javac internals. Every major JDK release risks breakage, and the fix cycle can block your upgrade path. - Security and supply chain risk: Every dependency is a potential vulnerability. Lombok runs as an annotation processor inside your compiler and has deep access to your build. Even if Lombok itself is safe today, it’s one more artifact in your supply chain to monitor, and one more entry point if compromised. If you were around for the Log4j CVE during the 2021 holidays, you know how painful an urgent dependency patch can be. The fewer dependencies you carry, the smaller your blast radius when the next CVE drops. - IDE support gaps: Annotation processing surprises new team members. Code navigation, refactoring tools, and static analysis don’t always see Lombok-generated code. - Debugging blind spots: Stack traces reference generated methods you can’t step into or read in source. - Dependency on a single library: Lombok is maintained by a small team. If the project slows down, your codebase depends on it. For more details you have to read this post autored by Loiane G. https://lnkd.in/e54x8G8V