Final in Java: Design Decision and Thread Safety

Hitting a 0ms runtime is the developer equivalent of hitting a game-winning shot at the buzzer. I just optimized my solution for finding the Intersection of Two Linked Lists and reached that "Beats 100%" milestone. The beauty of Linked List problems isn't just in solving them—it’s in the pointer magic that makes them run instantly. For this one, the two-pointer approach kept the logic clean and the execution lightning-fast. The Stats: * Runtime: 0ms (Beats 100.00% of Java users). * Complexity: Pure O(m + n) efficiency. Coding is often about trade-offs, but when you find that sweet spot where simplicity meets peak performance, you have to celebrate it. Keep grinding, keep optimizing. #LeetCode #Java #SoftwareEngineering #DataStructures #CodingLife #Optimization

Day 38/100 | Building Consistency 😃 Showing up every day. Learning, growing, and improving. #TightCoupling vs #LooseCoupling in #Java Some code works today. Some code survives change. That difference often comes down to coupling. Tight coupling happens when classes depend directly on each other. A small change in one class can force changes across the system. It’s quick to write — but hard to maintain. Loose coupling is when classes depend on abstractions (interfaces) instead of concrete implementations. This allows behavior to change without breaking existing code. Simple rule to remember: - Depend on what it does, not how it does it. Why this matters: - Makes code easier to maintain - Helps scale features without rewriting logic - Reduces risk during refactoring 🌍 Real-world analogy: - A phone with a non-removable battery → tight coupling - A phone with replaceable components → loose coupling This is why modern frameworks like Spring emphasize interfaces and dependency injection. #Day38 #OOPS #LooseCoupling #TightCoupling #Java #SoftwareDesign #BackendEngineer #FullstackDeveloper

0ms. 100% Beats. Thinking outside the box. There is nothing quite like the feeling of seeing your code hit a 0ms runtime. Today’s win was the "Delete Node in a Linked List" problem. At first glance, it feels impossible—how do you delete a node when you don't have access to the head of the list? The Solution: Instead of trying to "delete" the node in the traditional sense, I just copied the data from the next node into the current one and skipped the next node entirely. The Result: * Runtime: 0ms (Beats 100.00% of Java users). * Logic: O(1) Time and Space complexity. * Efficiency: 41/41 test cases passed instantly. In software engineering, we often get stuck trying to solve a problem the "standard" way. This was a great reminder that sometimes, the best solution is to reframe the problem itself. One optimization at a time. Do you prefer clever "hacks" like this, or do you stick to standard procedural logic? Let’s discuss in the comments! 👇 #Java #LeetCode #SoftwareEngineering #CodingLife #DataStructures #Optimization #TechCommunity

🚀 Why @RestController is a Game Changer in Spring Boot 🔥 One annotation that instantly elevates your API development: @RestController Behind the scenes, it combines: @Controller + @ResponseBody 💪 Why it’s powerful: 👉 Automatically converts Java objects into JSON 👉 Eliminates unnecessary boilerplate 👉 Makes REST APIs clean, readable, and production-ready 👉 Encourages modern API design practices Sometimes, one annotation makes all the difference. 💡 #Java #SpringBoot #BackendDevelopment #SoftwareEngineering #TechGrowth

We all use @Transactional. But what actually handles the commit and rollback? Spring doesn’t magically modify your method. It wraps your bean in a proxy. So the real flow is: Client → Proxy → TransactionManager → Your Logic → Commit / Rollback What the proxy basically does: • Start transaction (autoCommit = false) • Bind connection to current thread (ThreadLocal) • Execute your method • If everything’s fine → commit • If RuntimeException happens → rollback Small but important detail: By default, Spring does not roll back on checked exceptions. And that’s usually where “why didn’t this rollback?” bugs come from. Understanding proxy-based transactions helps you debug: • Self-invocation issues • Async breaking transactions • Unexpected commits in prod Using @Transactional is easy. Knowing what’s happening behind it? That’s real backend depth. #SpringBoot #Java #BackendEngineering

Spring Boot Pagination & Sorting Made Simple! Working with large datasets? Showing everything at once can kill performance and user experience. That’s where pagination and sorting come in! ✅ Pagination: Breaks data into pages. You define: page → which page you want (0-based) size → how many records per page ✅ Sorting: Controls the order of results: Sort.by("field").ascending() or .descending() Combine with pagination using PageRequest.of(page, size, sort) Pageable pageable = PageRequest.of(0, 5, Sort.by("firstName").ascending()); Page<UserEntity> page = userRepository.findAll(pageable); Pagination + sorting = better performance, faster APIs, and happy users! 😎 #SpringBoot #Java #SpringDataJPA #Pagination #Sorting #BackendDevelopment

One of the most important pillars of structural software quality is coupling and decoupling. Decoupling means reducing how much one part of the system depends on another. When components know less about each other, the code becomes easier to maintain, test, and evolve. To reduce coupling between classes and objects, there are many design patterns that can be applied. Dependency Injection is a design pattern that allows objects to receive their dependencies instead of creating them directly. This removes tight coupling, because classes depend on abstractions rather than concrete implementations — making changes safer and cleaner. Using Spring Boot, we can make Dependency Injection much easier through annotations: @Component, @Service, @Repository → define beans without manual instantiation @Autowired → inject dependencies instead of creating them @Configuration + @Bean → control dependencies explicitly when needed By combining decoupling principles with Spring’s Dependency Injection, we can build systems that are more flexible, testable, and ready to scale. #Java #SpringBoot #SoftwareArchitecture #CleanCode #softwareengineering #Backend

While working with legacy code, we often see long if-else chains used to decide behavior. They work, but as the system grows, they become hard to read, hard to maintain, and risky to change. Instead of this, we can use a HashMap to make the code cleaner and more functional. Replace multiple conditions with a map lookup: Put the behavior in a Map Fetch it using a key Use a default when nothing matches This small refactor: Improves readability Makes adding new cases easy Reduces code changes Keeps logic open for extension What approaches do you usually use when refactoring long if-else logic? #Java #SoftwareDevelopment

A backend skill that’s getting more attention lately: Observability As systems grow, logs alone stop being enough. When multiple services are involved, knowing what failed is less useful than knowing where and why. That’s where observability comes in. Instead of looking at logs, metrics, and traces separately, observability connects them. A slow API call can be traced across services, correlated with metrics, and backed by logs — all in one flow. This changes debugging completely. You don’t guess. You follow the request. Tools like OpenTelemetry also standardize how data is collected. That means less vendor lock-in and more consistent visibility across environments. Most production issues aren’t code bugs. They’re system behavior problems — and observability helps teams understand that behavior clearly. Good backend systems aren’t just built to run. They’re built to be understood in production. #Observability #BackendEngineering #OpenTelemetry #Microservices #DistributedSystems #Java

𝑷𝒐𝒕𝒆𝒏𝒕𝒊𝒂𝒍 𝑩𝒖𝒈 𝑰𝒅𝒆𝒏𝒕𝒊𝒇𝒊𝒆𝒅 𝒊𝒏 𝑳𝒆𝒆𝒕𝑪𝒐𝒅𝒆 𝑬𝒙𝒆𝒄𝒖𝒕𝒊𝒐𝒏 𝑻𝒊𝒎𝒆 𝑪𝒂𝒍𝒄𝒖𝒍𝒂𝒕𝒊𝒐𝒏  I recently noticed an issue with how LeetCode calculates and displays code execution time. By adding a simple static block with a shutdown hook, it is possible to alter the displayed runtime of a submitted solution. This indicates that the execution time can be influenced outside the actual algorithm logic, which should ideally not be possible. Below is the code snippet that demonstrates this behavior: static { Runtime.getRuntime().addShutdownHook(new Thread(() -> { try (FileWriter writer = new FileWriter("display_runtime.txt")) { writer.write("0"); } catch (IOException e) { e.printStackTrace(); } })); } This suggests a bug on LeetCode’s end, where execution time tracking may be relying on artifacts that can be manipulated during JVM shutdown. Sharing this for awareness and hoping the LeetCode team can look into it to ensure fair and accurate performance measurement for all submissions. #LeetCode #Java #JVM #CompetitiveProgramming #SoftwareEngineering #Performance #Debugging LeetCode