Jānis Ošs’ Post

🚀 Spring Framework 🌱 | Day 2 – Dependency Injection (DI) Today I understood Dependency Injection not just as a concept… but as a mindset shift 💡 👉 In real life, DI is everywhere. Think about this 👇 ☕ When you order tea in an office You don’t go to the kitchen, buy milk, sugar, tea powder and make it yourself. 👉 Someone provides it to you. 🚗 When you book a cab You don’t build the car or hire a driver manually. 👉 The system injects the service you need. 🏢 In a company project A developer doesn’t create every object manually. 👉 Framework like Spring injects dependencies automatically. 💡 Same happens in Spring Instead of: ❌ Creating objects using "new" We let Spring: ✅ Create objects ✅ Manage them ✅ Inject wherever needed 🔹 How it works internally (simple view): 👉 Spring scans classes 👉 Creates beans in IOC container 👉 Finds dependencies 👉 Injects them using annotations 🔥 Why this matters? - Loose coupling - Easy testing - Clean & scalable code 👉 Small concept, but it completely changes how you build applications. #SpringFramework #Java #BackendDevelopment #LearningJourney #SpringBoot #TechGrowth

💡 From a Small Spring Confusion to a Big Backend Realisation 🚀 Recently, while revising Spring fundamentals, I got stuck on a very simple doubt: 👉 Why does Spring create a proxy for @Configuration classes but not for normal @Component beans? At first, it sounded like a minor annotation difference. But digging deeper revealed an important concept about how the Spring container actually guarantees singleton behaviour. ✅ For @Component beans Spring creates the bean once during application startup and stores it in the singleton cache. Every injection or lookup simply returns the same instance. No interception or proxy is needed because developers don’t directly control the bean creation logic. ✅ For @Configuration classes Developers define @Bean methods that can call each other like normal Java methods. Without control, each method call could create a new object and break the singleton guarantee. This is where Spring uses CGLIB proxying. The proxy intercepts internal @Bean method calls and converts them into container lookups, ensuring that the already-created singleton bean is returned instead of creating a new instance. 🔥 Key Insight: Proxy is not created to “make beans singleton.” It is created to prevent accidental multiple object creation when bean factory methods are invoked directly. Understanding this changed the way I look at Spring — it’s not just annotations and auto-wiring, but a carefully designed lifecycle and container mechanism that protects consistency in large backend systems. Sometimes a small confusion leads to the biggest clarity 🙂 #SpringBoot #Java #BackendEngineering #Microservices #LearningJourney #SoftwareEngineering #SystemDesign

Most developers use Spring Boot. Very few truly understand what’s happening underneath. At the heart of Spring Boot lies one of the most powerful ideas in software engineering: Inversion of Control (IoC). Traditionally, an application controls the creation and lifecycle of its objects: "App → creates → Dependencies" Spring flips this relationship completely. Instead of your application managing objects, the Spring Container does it for you. Your classes simply declare what they need, and the container decides how and when to provide it. This is the essence of Dependency Injection. But the deeper layer most people overlook is how Spring Boot builds the entire application context automatically. Through Auto-Configuration, Spring Boot analyzes: • Classpath dependencies • Existing beans in the container • Application properties • Conditional annotations like "@ConditionalOnClass", "@ConditionalOnMissingBean", "@ConditionalOnProperty" Based on these conditions, Spring dynamically decides which beans should exist in the ApplicationContext. This means when you write something as simple as: "@SpringBootApplication" you are actually triggering a massive chain of mechanisms: "@Configuration" → declares bean definitions "@EnableAutoConfiguration" → loads conditional configurations "@ComponentScan" → discovers managed components Behind the scenes, Spring Boot is constructing a dependency graph, resolving bean lifecycles, handling scopes, applying proxies, and managing the entire runtime context. What looks simple on the surface is actually a highly sophisticated container orchestration system for Java objects. This is why mastering Spring isn’t about memorizing annotations. It’s about understanding how the container thinks. Once you grasp that, the framework stops feeling like magic—and starts feeling like engineering. #Java #SpringBoot #SpringFramework #BackendDevelopment #SoftwareEngineering #DependencyInjection #InversionOfControl #JavaDeveloper #Programming #TechLearning

Understanding Dependency Injection in Spring Boot - In real-world backend development, writing clean and maintainable code is essential. One principle that makes this possible in Spring Boot is Dependency Injection. - Although we use it daily in Spring Boot projects, Dependency Injection is actually a core feature of the Spring Framework. 🔎 What is Dependency Injection (DI)? Dependency Injection means a class does not create its own dependencies. Instead, the framework provides them. 👉 Your class focuses only on its responsibility 👉 Spring manages object creation and lifecycle 💡 Why it matters in real projects ✅ Promotes loose coupling ✅ Improves readability ✅ Makes unit testing easier ✅ Encourages better architecture ✅ Helps in scaling applications ⚙️ Types of Dependency Injection in Spring ✅ Constructor Injection (Recommended) ☑️ Setter Injection (useful for optional dependencies) ⚠️ Field Injection (generally not recommended) 📝 Example (Constructor Injection) @Service public class OrderService { private final PaymentService paymentService; public OrderService(PaymentService paymentService) { this.paymentService = paymentService; } public void placeOrder() { paymentService.processPayment(); } } Here, OrderService does not create PaymentService. Spring injects it automatically. ✔ Dependencies are explicit ✔ Easier to test ✔ Cleaner design 🚀 Best practices to follow • Prefer Constructor Injection • Avoid field injection • Keep dependencies minimal • Design small, focused classes Dependency Injection is not just about annotations. It’s about writing code that is clean, testable and built for long-term maintainability. #SpringBoot #Java #BackendDevelopment #CleanCode #SoftwareArchitecture #DependencyInjection

🚀 Day 3/100: Spring Boot From Zero to Production. Topic: Development Environment. The time has come! You’ve heard about Spring Boot enough, and you’ve finally decided to get that hands-on experience. 💻 But where do you actually begin? To build anything great, you need a solid foundation. For us, that means setting up the right tools from the very start. 🛠️ Here are the Big Three requirements: 1️⃣ The JDK (Java Development Kit) Think of this as your primary toolbox. It contains: javac: The compiler that turns your code into bytecode. JRE: The runtime environment that lets your apps run. JVM: The "engine" inside the JRE that executes that bytecode. jdb & javadoc: Tools for debugging and documentation. 💡 Pro Tip: Always go for an LTS (Long Term Support) version (like Java 17 or 21). Don't forget to set your JAVA_HOME environment variable and add the /bin folder to your PATH! 2️⃣ An IDE (Integrated Development Environment) This is the workspace where the magic happens. For Spring Boot, IntelliJ IDEA is the gold standard. It comes packed with features that make backend development a total charm. ✨ 3️⃣ A Build Tool (Maven or Gradle) You need this for Dependency Management. Trust me, trying to manage Java libraries manually is a massive pain. Maven handles the heavy lifting so you can focus on coding. 🏗️ And there you have it! Your environment is ready to start building industry-standard enterprise applications. 🚀 It’s only Day 3 and we are already moving fast. Stick around to become a Spring Boot expert! See you in the next post! 👋 #Java #SpringBoot #SoftwareDevelopment #100DaysOfCode #Backend

🚀 Spring Boot Auto-Configuration & Starters — Why Spring Boot Feels Effortless One of the biggest reasons developers move from traditional Spring to Spring Boot is the massive reduction in configuration. Instead of manually wiring dozens of components, Spring Boot uses Auto-Configuration to set up your application automatically based on the dependencies present in your project. Add a dependency → Spring Boot configures the required beans behind the scenes. For example: If you include the web dependency, Spring Boot automatically configures: Embedded Tomcat Spring MVC Default configurations for web applications This happens through Auto-Configuration classes that activate only when certain conditions are met — such as the presence of specific libraries on the classpath. But the real productivity boost comes from Starters. Spring Boot Starters are curated dependency bundles that bring together everything needed for a specific feature. Instead of adding multiple libraries individually, you add one starter. Examples: spring-boot-starter-web → builds REST APIs spring-boot-starter-data-jpa → database access with JPA spring-boot-starter-security → authentication and authorization spring-boot-starter-test → testing support This eliminates dependency conflicts and simplifies project setup. 💡 Key takeaway: • Auto-Configuration answers “How does Spring Boot configure my app automatically?” • Starters answer “How do I add complete functionality with minimal dependencies?” Together, they transform Spring from a configuration-heavy framework into a rapid application development platform. #Java #SpringBoot #SpringFramework #AutoConfiguration #SpringBootStarters #BackendDevelopment #SoftwareEngineering #JavaDeveloper #Microservices #APIDevelopment #TechLearning #Programming #JVM #CleanArchitecture

🚀 Reactive Programming While exploring ways to improve backend performance in Spring / Spring Boot applications, I came across an interesting concept - Reactive Programming. 🔹 Traditional Spring MVC (Blocking Model) In a typical Spring MVC application, the flow looks like this: Request → Thread assigned → DB/API call → Thread waits → Response returned Here, the thread stays blocked until the operation completes, which can limit scalability when handling many concurrent requests. 🔹 Reactive Programming (Non-Blocking Model) Reactive programming changes this approach: Request → Async operation triggered → Thread becomes free → Data arrives → Response returned This non-blocking and asynchronous model allows applications to handle more concurrent requests with fewer threads. 🔹 Reactive Stack In the Spring ecosystem, reactive applications are built using Spring WebFlux with Project Reactor, mainly using: • Mono → Represents 0 or 1 asynchronous result • Flux → Represents a stream of multiple results #ReactiveProgramming #SpringBoot #Spring #WebFlux #BackendDevelopment #Java

🚀 What Actually Happens When a Spring Boot Application Starts? Most developers just run the app and see: "Started Application in 3.2 seconds" But inside the JVM, a lot more is happening 👇 1️⃣ JVM Starts The JVM launches and executes the "main()" method from the JAR. 2️⃣ Class Loading Begins Classes are loaded using: • Bootstrap ClassLoader • Platform ClassLoader • Application ClassLoader 3️⃣ Bytecode Verification JVM verifies bytecode to ensure security and correctness. 4️⃣ SpringApplication.run() Executes This initializes the Spring Application Context. 5️⃣ Component Scanning Spring scans the project for beans like: "@Controller" "@Service" "@Repository" "@Component" 6️⃣ Dependency Injection Spring connects all beans automatically. 7️⃣ AOP Proxies Created Spring creates proxies for features like logging, transactions, and security. 8️⃣ Embedded Server Starts Tomcat/Jetty starts and the application becomes ready to serve APIs. ⚡ Most startup errors occur during: • Bean creation • Dependency injection • Auto configuration • Missing environment properties Understanding this flow helps in debugging Spring Boot applications faster. 📌 Currently exploring Spring Boot internals and backend architecture. If you're learning Java & Spring Boot, let’s connect and grow together! 🤝 #Java #SpringBoot #JVM #BackendDevelopment #Programming

🚀 Spring Boot Internals Series – Part 1 Ever felt like this? You can build APIs in Spring Boot… but when something breaks, you have no idea what’s actually happening inside. I was in the same situation. I could write this easily: @GetMapping("/users") public List<User> getUsers() { return userService.getUsers(); } But I didn’t really understand: 👉 How does this request reach this method? 👉 Who decides which controller gets called? 👉 What happens before and after this line runs? --- 🔍 Here’s what actually happens (simplified flow) 1️⃣ Client sends HTTP request 2️⃣ Request hits DispatcherServlet (the front controller) 3️⃣ It checks HandlerMapping to find the correct method 4️⃣ Spring prepares method arguments (request → Java objects) 5️⃣ Your controller method executes 6️⃣ Response is converted to JSON using Jackson 7️⃣ Response is sent back to the client --- ⚠️ Why this matters If you don’t understand this flow: - Debugging becomes guesswork - Errors feel random - You rely too much on tutorials --- 💡 Key takeaway Spring Boot feels “magical” —but internally, it follows a clear and predictable flow. Once you understand it, you stop guessing and start debugging like an engineer. --- 📌 In the next post: I’ll break down how DispatcherServlet actually works internally Follow if you want to truly understand backend systems, not just use them. #SpringBoot #JavaDeveloper #BackendDeveloper #SoftwareEngineering #Microservices #LearningInPublic

🚀 Spring Boot Startup Flow: What Happens Behind the Scenes A Spring Boot application may look simple to start, often with just a single line of code: SpringApplication.run(Application.class, args); But behind the scenes, Spring Boot performs several important steps to bootstrap the entire application. 🔹 Step 1 — SpringApplication.run() is triggered This method starts the complete lifecycle of the Spring Boot application and prepares the framework to initialize all required components. 🔹 Step 2 — Environment Preparation Spring Boot loads configuration from multiple sources such as: • "application.properties" or "application.yml" • Environment variables • Command-line arguments These configurations help the application adapt to different environments like development, testing, or production. 🔹 Step 3 — Creating the Application Context Spring Boot initializes the ApplicationContext, which acts as the central container responsible for managing all Spring Beans and application configurations. 🔹 Step 4 — Component Scanning Spring scans the project packages to detect classes annotated with: "@Component" "@Service" "@Repository" "@Controller" These classes are automatically registered as Beans inside the Application Context. 🔹 Step 5 — Auto Configuration Based on the dependencies added to the project (for example, "spring-boot-starter-web"), Spring Boot automatically configures required components such as: • Embedded Tomcat server • DispatcherServlet • Spring MVC configuration • JSON message converters 🔹 Step 6 — Bean Initialization Spring creates all beans and resolves their dependencies using Dependency Injection, ensuring that components are properly connected. 🔹 Step 7 — Embedded Server Startup Finally, Spring Boot starts the embedded server (Tomcat/Jetty/Undertow), making the application ready to receive HTTP requests. Once the application is running, the request flow typically follows: Client → DispatcherServlet → Controller → Service → Repository → Database Understanding what happens internally helps developers gain deeper insight into Spring Boot architecture, application lifecycle, and request handling. Spring Boot simplifies development, but learning what happens under the hood makes system design and debugging much more effective. #Springboot #Java #BackendDevelopment #SoftwareEngineering #Microservices