Sergiy Yevtushenko’s Post

🚀 Dependency Injection: The Heart of Spring Most developers write code where objects create their own dependencies. Spring flips this on its head — and that's what makes it powerful. Dependency Injection (DI) means an object receives its dependencies from the outside instead of creating them itself. The IoC (Inversion of Control) container manages object creation, wiring, and lifecycle. // ❌ Without DI — tight coupling public class OrderService { private PaymentService payment = new PaymentService(); // hard-coded! } // ✅ With DI — loose coupling @Service public class OrderService { private final PaymentService paymentService; public OrderService(PaymentService paymentService) { this.paymentService = paymentService; // injected by Spring } } Why does this matter? ✔ Testability — swap real dependencies with mocks ✔ Flexibility — change implementations without touching consumers ✔ Single Responsibility — objects focus on their job, not wiring ✔ Less boilerplate — Spring handles object lifecycle Spring's ApplicationContext is the IoC container. It scans your classes, creates beans, resolves dependencies, and injects them automatically. You declare what you need; Spring figures out how to provide it. This is the concept everything in Spring Boot builds upon. Master this, and the rest clicks into place. #Java #SpringBoot #BackendDevelopment #DependencyInjection #IoC #SoftwareEngineering

Most observability tools can tell you that a request was slow. Few can tell you why. In recent testing conducted by an external engineering partner, we evaluated how Oteligence Maestro extends OpenTelemetry tracing inside a Java application. With the standard OpenTelemetry Java Agent alone, a request trace looked like this: POST /api/orders One span. One total duration. Useful, but it doesn’t reveal what actually happened inside the application. When the same service was run with a Maestro-generated OpenTelemetry extension, the trace automatically revealed the internal execution path of the request: POST /api/orders ↳ createOrder ↳ validateOrder ↳ calculatePricing ↳ processPayment Instead of just seeing that a request took ~300ms, engineers could immediately see where the time was actually spent. Why does this matter? Because most production incidents aren't caused by infrastructure, they're caused by business logic inside the application. And traditional auto-instrumentation rarely exposes that layer. By automatically extending OpenTelemetry with deeper visibility into application execution, Maestro helps teams move from: “Something is slow.” to “This method is responsible.” That shift can dramatically reduce investigation time and speed up root cause identification. We’re excited about what this means for the future of observability, where traces don’t just show requests, but how applications actually execute. #OpenTelemetry #Observability #Java #DevOps #DistributedTracing #PlatformEngineering

𝗧𝗵𝗿𝗲𝗮𝗱𝗟𝗼𝗰𝗮𝗹 𝘃𝘀 𝗦𝗰𝗼𝗽𝗲𝗱 𝗩𝗮𝗹𝘂𝗲𝘀: 𝗰𝗼𝗻𝘁𝗲𝘅𝘁 𝗶𝗻 𝗝𝗮𝘃𝗮 (𝗟𝗼𝗼𝗺 𝗲𝗿𝗮) 🧵 𝗧𝗵𝗿𝗲𝗮𝗱𝗟𝗼𝗰𝗮𝗹 Pros ✅ Zero “param passing” (requestId / tenant / MDC) ✅ Works with legacy libraries and frameworks ✅ Compatible with virtual threads (context is bound to the logical thread) Cons ❌ Hidden dependency (methods read context “from the air”) ❌ Doesn’t reliably propagate across async/reactive boundaries ❌ On pooled platform threads: stale context + memory retention if you forget cleanup ❌ Bad fit for “per-thread caches” in a world of many short-lived virtual threads Use it when ✅ Request-scoped, mostly read-only context ✅ You must integrate with ThreadLocal/MDC-based tooling 🚫 Never store heavy objects / large graphs / caches Typical mistakes 🚫 Forgetting cleanup (remove()/reset) in long-lived threads / pools 🚫 Using it as a global service locator 🚫 Assuming it “just works” through CompletableFuture/reactive chains 𝗦𝗰𝗼𝗽𝗲𝗱 𝗩𝗮𝗹𝘂𝗲𝘀 What it is Context bound to a scope (execution block), not “stored on a thread” Automatic lifetime: when scope ends, the value is gone Pros ✅ Clear boundaries + automatic cleanup ✅ Better match for Loom + structured concurrency thinking ✅ Encourages immutable request context Cons ❌ Still evolving (preview in Java 21) ❌ Ecosystem/tooling support is not as universal as ThreadLocal/MDC yet Use it when ✅ New Loom-first code: requestId / tenant / trace context ✅ You want explicit lifetime and fewer “implicit state” bugs 𝗠𝘆 𝗼𝗽𝗶𝗻𝗶𝗼𝗻 * Default for new services: 𝗦𝗰𝗼𝗽𝗲𝗱 𝗩𝗮𝗹𝘂𝗲𝘀 for request context. * Keep ThreadLocal only as a compatibility layer (MDC/legacy libs) and treat it as “unsafe by default”. Rule of thumb * “Context for this execution tree” → Scoped Values * “Legacy integration needs it” → ThreadLocal 𝗤𝘂𝗲𝘀𝘁𝗶𝗼𝗻: 𝗪𝗵𝗲𝗿𝗲 𝗱𝗼 𝘆𝗼𝘂 𝗸𝗲𝗲𝗽 𝗿𝗲𝗾𝘂𝗲𝘀𝘁 𝗰𝗼𝗻𝘁𝗲𝘅𝘁 𝘁𝗼𝗱𝗮𝘆 - 𝗠𝗗𝗖/𝗧𝗵𝗿𝗲𝗮𝗱𝗟𝗼𝗰𝗮𝗹 𝗼𝗿 𝗲𝘅𝗽𝗹𝗶𝗰𝗶𝘁 𝗽𝗮𝗿𝗮𝗺𝘀? 👇 #Java #Concurrency #VirtualThreads #ProjectLoom #Observability

The Modular Monolith isn't a stepping stone. For many, it's the destination. The standard narrative paints the monolith as a phase to escape on the way to microservices. But this skips a critical, and often better, alternative: the well-structured modular monolith. This isn't your classic 'big ball of mud'. A modular monolith is a single deployable artifact composed of independent, loosely-coupled modules. The key is enforcing strict boundaries at the code level. Think of it as microservices-style separation, but without the network calls. Modules communicate through public, stable interfaces, just like services would. Direct access to another module's internal logic or database tables is forbidden. This can be enforced with tooling like ArchUnit in Java or custom linter rules in other ecosystems. You get the organizational benefits of clear ownership and team autonomy over specific domains. What you don't get is the operational chaos of a distributed system. No service discovery, no distributed tracing complexity, no network latency between components. Refactoring across module boundaries is a simple code change, not a coordinated cross-service deployment. Transactions are local and ACID-compliant by default. A well-structured monolith can scale further than most teams think.

🚀 Spring IoC — The Foundation Behind Spring When developers start using Spring, annotations like @Autowired or @Component feel convenient. But the real power lies underneath: Inversion of Control (IoC). In traditional Java applications, objects are responsible for creating and managing their dependencies. Spring flips this responsibility. Instead of classes controlling object creation, the Spring IoC Container manages: Object creation Dependency wiring Lifecycle management Configuration This shift is called Inversion of Control. According to the Spring Framework documentation, dependencies are provided externally by the container rather than being created inside the class itself. The objects managed by this container are called Beans — the core building blocks of any Spring application. Why this matters: Without IoC → tightly coupled code With IoC → loosely coupled, testable, scalable systems You stop worrying about how objects are created and focus on business logic instead. 💡 Key takeaway: • IoC answers “Who controls object creation?” • Dependency Injection answers “How dependencies are provided?” • Spring Container answers “Who manages the application lifecycle?” Once you truly understand IoC, Spring stops feeling magical — and starts feeling architectural. #Java #SpringFramework #SpringBoot #IoC #DependencyInjection #BackendDevelopment #SoftwareEngineering #JavaDeveloper #CleanArchitecture #Microservices #APIDevelopment #TechLearning #JVM #Programming

Optimising the Entry Point: @SpringBootApplication's Internal Mechanisms 🚀⚙️ Efficiency in the field of corporate Java development is determined by how well we use our frameworks. The Annotation Hierarchy is what distinguishes a coder from an architect, even though most developers are aware that @SpringBootApplication launches the application. 🔹01. @SpringBootConfiguration 🛠️ A modified version of the common @Configuration. By designating the class as a source of bean definitions for the application context, it guarantees that the framework will identify your configuration as native to Spring Boot. 🔹02. @EnableAutoConfiguration 🤖 That's the main idea behind "Convention over Configuration." It causes Spring Boot to automatically instantiate beans based on the libraries you've included to your pom file by scanning the classpath.XML. It successfully removes the requirement for manual boilerplate configuration based on Java or XML. 🔹03. @ComponentScan 🔍 This takes care of the process of discovery. It tells the framework to look for and register classes that are marked with @Component, @Service, or @Repository by scanning the current package and its sub-packages. Professional Edge 💡 Clean entry points and modularity are essential in a microservices architecture. Making use of @SpringBootApplication guarantees that your service adheres to the Clean Code industry standard and stays Cloud-Native ready. #SpringBoot #JavaDevelopment #SoftwareArchitecture #BackendEngineering #Microservices #CleanCode #JavaDeveloper #TechInsights #EnterpriseSoftware

📅 DAY 10 – Dependency Injection (DI) 📘 Spring Core – Day 10 💡 What is Dependency Injection? In real-world applications, classes often depend on other classes to do their job. The traditional approach is creating those dependencies using the new keyword — which tightly couples the code. 🚀 Dependency Injection (DI) changes this mindset. Instead of a class creating its own dependencies, Spring injects them from outside. This simple shift makes your application more flexible, maintainable, and test-friendly. 🔧 Types of Dependency Injection in Spring 🔹 Constructor Injection Dependencies are provided through the class constructor. ✔ Ensures required dependencies are available at object creation ✔ Preferred approach in modern Spring applications ✔ Encourages immutability and clean design 🔹 Setter Injection Dependencies are provided using setter methods after object creation. ✔ Useful for optional dependencies ✔ Allows flexibility when dependencies may change later 🎯 Why Dependency Injection matters so much? ✅ Loose Coupling – Classes depend on interfaces, not implementations ✅ Cleaner Code – No hardcoded object creation logic ✅ Easy Unit Testing – Dependencies can be mocked effortlessly ✅ Better Scalability – Code is easier to extend and modify ✨ Spring + Dependency Injection = Production-ready, professional Java applications If you truly want to write enterprise-level code, DI is not optional — it’s essential. #DependencyInjection #SpringCore #JavaDeveloper #CleanCode

𝐒𝐢𝐦𝐩𝐥𝐢𝐟𝐲𝐢𝐧𝐠 𝐃𝐨𝐜𝐤𝐞𝐫𝐟𝐢𝐥𝐞 𝐌𝐚𝐧𝐚𝐠𝐞𝐦𝐞𝐧𝐭 𝐢𝐧 𝐂𝐑𝐔𝐃𝐉𝐏𝐀𝐇𝐈𝐁𝐄𝐑𝐍𝐀𝐓𝐄 Managing Dockerfiles efficiently is crucial for modern application development. The CRUDJPAHIBERNATE project benefits from a Dockerfile that standardizes its environment, ensuring consistency across different stages of development and deployment. This file specifies the base image, sets the working directory, copies necessary files, and defines how the application is built and run. The Dockerfile uses instructions like FROM to define the base image, COPY to add source code, and CMD to specify the startup command. This containerization approach ensures that the application runs the same way regardless of the environment, reducing "it works on my machine" issues. Benefits include improved reproducibility, isolation, and scalability. A well-defined Dockerfile simplifies deployment, makes scaling easier, and ensures a consistent environment for the application. Check out the full article for a detailed example. #Java #Dockerfile 🔗 https://lnkd.in/dQ5eXM8i

JVM's latest generational JIT compilation strategy represents a significant advancement in runtime performance for Java applications. This intricate approach leverages a multi-tiered compilation pipeline, dynamically adapting to application behaviour over its lifecycle. The core mechanism involves segmenting compiled code into different generations based on its "hotness" and execution frequency. Initially, methods undergo rapid, less-optimised compilation to facilitate quick startup. As execution profiles mature, frequently invoked code paths are promoted to higher tiers, where more aggressive optimisations are applied, including speculative optimisations and aggressive inlining. A crucial element is on-stack replacement (OSR), allowing running methods to be recompiled and replaced mid-execution, ensuring that performance gains are immediately realised without requiring a method's complete return. Profiling feedback continuously refines these decisions, demoting rarely used or deoptimised code paths, thereby reducing memory overhead. This sophisticated strategy markedly improves developer workflows by delivering superior application responsiveness and sustained throughput without requiring extensive manual tuning. Startup times are noticeably reduced, and the adaptive nature of the JIT ensures that peak performance is achieved and maintained for long-running services. Resource utilisation becomes more efficient, as only truly hot code receives the most intensive optimisation, freeing up computational resources for application logic. #JVM #JITCompilation #PerformanceEngineering #SoftwareArchitecture #Optimisation

Why Doesn’t Rollback Happen in Self-Invocation with @Transactional? You annotate a method with @Transactional. An exception occurs. You expect a rollback. But the data is still committed. If this happens in Spring Framework, one common reason is self-invocation. What Is Self-Invocation? Self-invocation happens when a method inside a class calls another method of the same class. At first glance, this seems perfectly fine. But here’s the hidden problem. Why Rollback Doesn’t Happen: Spring applies @Transactional using a proxy mechanism. -When a method is called from outside the class, the call goes through Spring’s proxy. -The proxy starts the transaction and manages rollback. However, when a method calls another method inside the same class: -The call happens directly within the object. -It bypasses Spring’s proxy. -Spring never intercepts the call. -The transaction is never started. And if no transaction was started, rollback cannot happen. The Real Reason: Rollback doesn’t fail because of the exception. Rollback fails because Spring never got the chance to manage that internal method call. No proxy interception → No transaction → No rollback. Key Takeaway: @Transactional is not just an annotation. It works only when the method call goes through Spring’s proxy. #Java #SpringBoot #SpringFramework #BackendDevelopment #SoftwareEngineering #Microservices #AOP #Transactional