Spring Boot Singleton-Prototype Injection Problem Solved with @Lookup

Most developers use Spring Beans daily. Very few understand what actually happens inside the container. Here’s the Spring Bean lifecycle — technically simplified: 🔁 Container Startup 1️⃣ Instantiation Bean object is created (via reflection). 2️⃣ Dependency Injection @Autowired / constructor injection resolves dependencies. 3️⃣ Aware Interfaces (optional) BeanNameAware, ApplicationContextAware, etc. 4️⃣ BeanPostProcessor (Before Init) postProcessBeforeInitialization() runs. 5️⃣ Initialization Phase @PostConstruct InitializingBean.afterPropertiesSet() Custom init-method 6️⃣ BeanPostProcessor (After Init) postProcessAfterInitialization() runs. 👉 This is where Spring may wrap your bean with a proxy. That’s how @Transactional, @Async, @Cacheable, and AOP work. The injected object is often a proxy — not your original class. 7️⃣ Bean Ready for Use 🔻 Shutdown Phase 8️⃣ Destruction @PreDestroy DisposableBean.destroy() (Default applies to singletons.) Why this matters: • @Transactional fails in self-invocation • Proxy-based behavior confuses debugging • Prototype inside Singleton behaves unexpectedly • Circular dependency issues during early creation Once you understand the lifecycle, Spring stops feeling like magic. It becomes predictable. #SpringBoot #SpringFramework #Java #BackendEngineering #AOP #Microservices

🚀 Day 14/100 - Dependency Injection (DI) - 1️⃣ One of the most important concepts in Spring Boot and modern backend development❗ ➡️ What is it? A design/programming technique where an object receives its dependencies from an external source (like the Spring container) instead of creating them itself. In simple words: 👉 Objects don’t create dependencies, they are provided. ➡️ Why to use? DI helps you write clean, scalable, and maintainable code: 🔹Promotes loose coupling between classes 🔹 Improves testability and maintainability 🔹 Encourages modular & reusable code 🔹 Follows SOLID principles - especially the "D: Dependency Inversion Principle" ➡️ Example: The attached image shows Dependency Injection via Constructor 👇 📌 Key Takeaway DI shifts responsibility from objects to the Spring container, making applications: - Easier to read - Easier to test - Easier to maintain Next post: https://lnkd.in/de9hpKXR Previous post: https://lnkd.in/dYC2XdM3 #100Days #SpringBoot #DependencyInjection #Java #BackendEngineering #SoftwareEngineering

Spring annotations that don’t get enough attention (but matter in real systems) Most Spring Boot tutorials focus on the basics: @RestController, @Service, and @Autowired. While those are essential, they are rarely the annotations that make a meaningful difference once an application grows or moves into production. 1. One annotation I started using more frequently is @ConfigurationPropertiesScan. Instead of manually registering every configuration class, this annotation allows Spring Boot to automatically detect and bind configuration properties across the application. The result is a much cleaner main application class and a more organized configuration structure. 2. Another annotation that quietly prevents production issues is @Validated, especially when used on configuration classes. By combining it with constraint annotations like @NotNull or @Min, Spring fails fast if a required configuration value is missing or invalid. This avoids situations where an application starts successfully but behaves unpredictably later. 3. For conditional behavior, @ConditionalOnProperty has proven extremely useful. It allows beans to be created only when a specific property is enabled, which is ideal for feature toggles, environment-specific integrations, or gradually rolling out new functionality without changing code paths. 4. When working with distributed systems, resilience becomes an unavoidable necessity. @Retryable from Spring Retry offers a declarative way to add retry logic for transient failures such as timeouts or temporary network issues. It keeps retry behavior explicit and close to the business logic, without cluttering the code with manual loops. 5. Observability has also improved significantly in newer versions of Spring Boot. The @Observed annotation integrates directly with Micrometer to automatically generate metrics and traces. This makes it much easier to understand system behavior in production without writing custom instrumentation code everywhere. 6. Another annotation that helps keep services loosely coupled is @EventListener. It enables different parts of the application to respond to domain events without requiring direct dependencies. This leads to cleaner workflows and makes future changes easier to implement. The real value of Spring annotations is not in how many of them you know, but in understanding which ones reduce coupling, improve reliability, and make systems easier to operate at scale. Which Spring annotation have you found most valuable in real-world projects? #SpringBoot #SpringFramework #Java #Microservices #BackendEngineering #SoftwareDesign

🌱 BeanFactory vs. ApplicationContext: Which One Should You Use in Spring? 🌱 If you’ve ever dived into the Spring Framework, you’ve probably encountered both BeanFactory and ApplicationContext. But what’s the real difference—and why should you care? Let’s break it down: BeanFactory: Think of BeanFactory as the basic bean container in Spring. It provides the fundamental features needed to manage beans—essentially, it’s responsible for instantiating, configuring, and managing objects (beans) in your application. It’s lightweight and only loads beans on demand (lazy loading), making it great for memory-constrained environments. ApplicationContext: ApplicationContext takes things to the next level! 🚀 It builds on top of BeanFactory and adds a whole suite of enterprise-ready features, including: Internationalization (i18n) support Event propagation Declarative mechanisms to create a bean (like annotations) Automatic bean wiring Integration with Spring AOP So, which should you use? BeanFactory is best for simple scenarios or resource-restricted environments. ApplicationContext is the go-to choice for modern Spring applications—offering more features, flexibility, and power for real-world projects. #SpringFramework #Java #SoftwareDevelopment #BeanFactory #ApplicationContext #SpringTips

🚫 Returning JPA Entities directly from a Spring Boot controller is convenient… until it breaks in production. Here’s why I prefer DTOs over Entities in REST APIs: - Entities are built for persistence (relationships, lazy loading, JPA annotations) — not for API responses. - Returning Entities can trigger serialization issues like `LazyInitializationException` when Jackson touches lazy fields. - Entities may accidentally expose internal/sensitive fields (passwords, roles, audit columns). - DTOs keep the API contract stable even when the database model changes. Quick example: // DTO public record UserDto(Long id, String name, String email) {} // Controller @GetMapping("/users/{id}") public UserDto getUser(@PathVariable Long id) { User user = userService.getUser(id); return new UserDto(user.getId(), user.getName(), user.getEmail()); } Do you currently return Entities directly from Controllers, or are you mapping to DTOs already? #Java #SpringBoot #ReactJS #FullStack #Coding #BackendDevelopment #RESTAPI

⏱️ How much time does System.out.println() actually take? (You might be surprised) Most of us use System.out.println() everywhere — for debugging, logging, and quick checks. But have you ever asked: how expensive is it? 🧠 The short answer System.out.println() is slow compared to normal Java operations. ⏳ On average: 1–5 milliseconds per call (can be more) Depends on OS, console, and I/O buffering That may look small… until you put it inside a loop. ⚠️ Why is it slow? Because System.out.println(): 🔹 Writes to I/O stream (not memory) 🔹 Is synchronized (thread-safe → slower) 🔹 Flushes output to the console 🔹 Waits for the OS to handle the write This is thousands of times slower than in-memory operations. 🔁 Real impact for(int i = 0; i < 10000; i++) { System.out.println(i); } 👉 This can take seconds, not milliseconds. Now imagine this inside: REST APIs Microservices High-traffic applications 😬 ✅ What to do instead? ✔️ Use logging frameworks (Logback, Log4j2) ✔️ Log at proper levels (DEBUG, INFO) ✔️ Avoid console printing in production code 🏁 Final thought System.out.println() is great for learning and quick debugging, but in real applications — it can silently kill performance. 🔔 Follow for more insights on Java internals & backend performance 🚀 #Java #JavaDeveloper #CoreJava #AdvancedJava #JavaProgramming #Spring #SpringBoot #Hibernate #JPA #BackendDevelopment #Microservices #RESTAPI #SoftwareEngineering #CleanCode #TechLearning #CodingJourney #Programming

🌱 My Spring Journey : Difference between BeanFactory and ApplicationContext BeanFactory Container : -> It can not pre-instantiate singleton scope spring bean -> It does not support to work with properties file -> It does not support for the Internationalization -> It does not support for Annotation driven configuration, 100% code driven configuration, spring boot application development ApplicationContext Container : -> It can pre-instantiate singleton scope spring bean -> It support to work with properties file -> It support for the Internationalization -> It support for Annotation driven configuration, 100% code driven configuration, spring boot application development -> But both containers support for the dependency injection, dependency lookup, autowiring, spring bean lifecycle and etc. Question : Where should we use BeanFactory and where should we use ApplicationContext container ? Answer : If in your application memory is big constraint then try to use BeanFactory otherwise we can use ApplicationContext container. ApplicationContext = Industry standard BeanFactory = Rarely used, basic container #Spring #SpringFramework #SpringBoot #Java #BeanFactory #ApplicationContext #DependencyInjection #JavaDeveloper

🚀 The Hidden Journey: What REALLY Happens When You Execute Java Code Spoiler: It's way more fascinating than you think! THIS flow completely changed how I write and optimize code. Let me take you behind the curtain 👇 ⚡ THE TWO-PHASE MASTERPIECE PHASE 1: COMPILE TIME ⏱️ → Your abc.java goes through the javac compiler → If errors exist? Game Over (fix them first!) → Success? Welcome abc.class (the mystical bytecode) PHASE 2: RUN TIME 🎯 (Where the real magic happens) Think of the JVM as a 5-star security system + performance optimizer: 🔐 Class Loader - Your bytecode's VIP entry pass 🛡️ Bytecode Verifier - The security bouncer (prevents malicious code) 🔄 Interpreter - Translates bytecode to machine code (line by line) ⚡ JIT Compiler - The GENIUS move! Identifies "hot spots" and pre-compiles them 🖥️ OS/Hardware - Final execution on your machine 💎 THE INSIGHTS THAT CHANGED MY CODING GAME: ✅ "Write Once, Run Anywhere" isn't just marketing - it's architectural brilliance. Same bytecode, ANY platform! ✅ Performance tip: First execution is slower, but JIT learns your patterns and SUPERCHARGES repeated operations. This is why production apps run faster over time! ✅ Security built-in: That bytecode verifier is your silent guardian against buffer overflows and unauthorized memory access. 🎯 PRO TIP FOR DEVELOPERS: Understanding this flow helps you: → Debug smarter (know which phase is causing issues) → Optimize better (leverage JIT compilation patterns) → Architect efficiently (understand platform independence costs) Question: Have you ever monitored JIT compilation in your apps? The performance gains are mind-blowing! 🔥 Double-tap ❤️ if this added value | Follow for more deep-dives that make you a better developer P.S. - What topic should I break down next? Drop suggestions below! 👇 #Java #SoftwareEngineering #Programming #JVM #TechInsights #DeveloperCommunity #CodeOptimization #SoftwareDevelopment #TechEducation #BackendDevelopment #EngineeringExcellence #LearnInPublic #100DaysOfCode #DevCommunity

A Spring Boot mistake that slows down your API. Using @Transactional on methods that don't need it. I've seen this pattern everywhere: @Transactional public User getUserById(Long id) { return userRepository.findById(id); } This is a read-only query. No updates. No writes. But @Transactional still opens a database connection, starts a transaction, and holds it until the method finishes. For simple reads, this adds unnecessary overhead. The fix is simple: @Transactional(readOnly = true) public User getUserById(Long id) { return userRepository.findById(id); } Or remove it entirely if you don't need transaction management. I optimized an API that had @Transactional on every method. Response time dropped by 25% just by cleaning this up. Small annotation. Big performance difference. What Spring Boot optimization gave you the best results? #SpringBoot #Java #Programming #BackendDevelopment #CodeReview

🚨 Your favourite collection might be your biggest bottleneck. We’ve all been there — we start out with ArrayList. It’s simple, fast, and works well for most cases. But as your application grows, that one-size-fits-all approach quietly becomes the reason for mysterious slowdowns. The Java Collections Framework (JCF) isn’t a buffet of similar options — it’s a power toolset designed for specific trade-offs. Knowing which one to pick can make your system faster and your code cleaner. Here’s a quick reality check 👇 ArrayList ➡️ Great for fast random access and cheap appends; but costly middle inserts or deletes. LinkedList ➡️ Best for frequent head/tail updates; but worse cache locality and higher memory cost. HashMap / HashSet ➡️ O(1) lookups; but no ordering, and hash collisions can bite you if keys aren’t well-designed. LinkedHashMap ➡️ Preserves insertion order — perfect for caches or predictable APIs. TreeMap / TreeSet ➡️ Keeps keys sorted; excellent when order matters more than speed. ⚙️ A few pro tips: Use ArrayList for “read-mostly” lists. If you’re iterating more than mutating, it’s your go-to. Avoid LinkedList unless you really need it. In most modern JVMs, it’s slower due to poor cache performance. Use EnumMap or EnumSet when keys are enums — highly memory and speed efficient. Initialize collection sizes upfront. Helps avoid resizing overhead, especially in tight loops. Prefer immutability — List.of() and Map.of() are your friends for static data. Choosing the right collection isn’t a micro-optimization — it’s a design decision that compounds as your system scales. So, what do you think? 👉 Which Java collection is overused or misused most in your experience? #Java #CollectionsFramework #DataStructures #Performance #SoftwareEngineering #CleanCode