Autowire in Spring XML Configuration Simplified

🔥 Part 2 of the series is live: We just implemented @Autowired from scratch. Not just reading about it. Actually building it. Most Java developers use Spring every day — @Component, @Autowired, @Transactional — without ever understanding what's happening underneath. The answer to all of it is one API: Java Reflection. In this series, we use Reflection as the lens AND the tool. Every concept we cover, we immediately apply to build a real piece of the framework. Theory and implementation, side by side. By the end, you won't just know how Reflection works. You'll know how frameworks think. Second blog is live now 👇

4 things nobody tells you about JPA's @PrePersist and @PreUpdate: 1. @PreUpdate only fires if Hibernate actually issues an UPDATE. No field changed = no callback. 2. JPQL bulk updates bypass callbacks completely. Your timestamps won't refresh. 3. Don't call other repositories inside callbacks. That's how you get mysterious exceptions at 2 AM. 4. For pure audit fields, @EnableJpaAuditing is cleaner. Save @PrePersist for actual domain derivation, slugs, counts, computed fields. Full breakdown with code examples 👇 https://lnkd.in/guSfFfVV #Java #SpringBoot #JPA #Hibernate

🚀 Day 19 – map() vs flatMap() in Java Streams While working with Streams, I came across a subtle but important difference: "map()" vs "flatMap()". --- 👉 map() Transforms each element individually List<String> names = Arrays.asList("java", "spring"); names.stream() .map(String::toUpperCase) .forEach(System.out::println); ✔ Output: JAVA, SPRING --- 👉 flatMap() Flattens nested structures List<List<Integer>> list = Arrays.asList( Arrays.asList(1, 2), Arrays.asList(3, 4) ); list.stream() .flatMap(Collection::stream) .forEach(System.out::println); ✔ Output: 1, 2, 3, 4 --- 💡 Key insight: - "map()" → 1-to-1 transformation - "flatMap()" → 1-to-many (and then flatten) --- ⚠️ Real-world use: "flatMap()" is very useful when dealing with: - Nested collections - API responses - Complex data transformations --- 💡 Takeaway: Understanding when to use "flatMap()" can make your stream operations much cleaner and more powerful. #Java #BackendDevelopment #Java8 #Streams #LearningInPublic

Spring Boot DAY 21 –PathVariable vs RequestParam Understanding the difference between @PathVariable and @RequestParam is very important while building REST APIs 👇 Both are used to extract data from the URL, but they serve different purposes. --- 🔹 1️⃣ @PathVariable ✔ Used to extract values from the URL path ✔ Part of the resource identity ✔ Mandatory by default ✅ Example URL: /users/10 ✅ Code Example: java @GetMapping("/users/{id}") public String getUser(@PathVariable int id) { return "User ID: " + id; } 👉 Here, 10 is part of the URL path. 👉 It represents a specific resource (User with ID 10). 📌 Mostly used when: Fetching single record Updating a specific resource Deleting a specific resource --- 🔹 2️⃣ @RequestParam ✔ Used to extract values from query parameters ✔ Used for filtering, sorting, searching ✔ Can be optional ✅ Example URL: /users?id=10 ✅ Code Example: java @GetMapping("/users") public String getUserById(@RequestParam int id) { return "User ID: " + id; } 👉 Here, id=10 is passed as a query parameter. 👉 Mostly used for filtering or optional data. 📌 Example: /users?city=Nashik /users?page=1&size=5 /users?sort=asc 💡 When to Use What? 👉 Use @PathVariable when the value is required to uniquely identify a resource. 👉 Use @RequestParam when passing optional filters or additional parameters. 🎯 Interview Tip: If the data changes the identity of the resource → use PathVariable If the data modifies how results are returned → use RequestParam

#Post4 In the previous post, we understood how request mapping works using @GetMapping and others. Now the next question is 👇 How does Spring Boot handle data sent from the client? That’s where @RequestBody comes in 🔥 When a client sends JSON data → it needs to be converted into a Java object. Example request (JSON): { "name": "User", "age": 25 } Controller: @PostMapping("/user") public User addUser(@RequestBody User user) { return user; } 👉 Spring automatically converts JSON → Java object This is done using a library called Jackson (internally) 💡 Why is this useful? • No manual parsing needed • Clean and readable code Key takeaway: @RequestBody makes it easy to handle request data in APIs 🚀 In the next post, we will understand @PathVariable and @RequestParam 🔥 #Java #SpringBoot #BackendDevelopment #RESTAPI #LearnInPublic

We've been building something quietly for a while, and I'm ready to share it. OpenTaint is an open-source taint analysis engine with the most thorough Spring Boot support. https://lnkd.in/darQ5ZRN Not "Java support." Actual modeling of how Spring works. Spring Boot's annotation-driven architecture creates data flows that are invisible to conventional static analysis. A bean injection crosses class boundaries with no call site in the source. JPA persistence links two HTTP endpoints through the database with no shared code path. A Freemarker configuration object determines whether user input reaching template.process() is exploitable — or harmless. These are not edge cases. This is the default architecture of most Java web applications. OpenTaint traces tainted data through every layer: - Following data across file and class boundaries — through DTO field access and method chains. - Resolving configuration-aware sinks — tracing through DI to determine whether a resolver or handler is actually exploitable. - Connecting endpoints through persistence — where the database or service state is the only link. - Distinguishing dangerous fields from safe ones — at per-column granularity within those flows. The engine operates on bytecode, resolves virtual dispatch, and maps every finding back to its HTTP endpoint. If you're using Semgrep or CodeQL on your Java/Kotlin/Spring codebase — try OpenTaint on the same project and compare what it finds. We've published reproducible comparisons on the blog, but seeing it on your own code is more convincing. Apache 2.0 + MIT. Engine, rules, CLI, GitHub Action, GitLab CI — everything is open source. #java #kotlin #spring #springboot #security #appsec #opensource #sast #taintanalysis

🚀 Day 7/45 – Backend Engineering (JPA & Hibernate) Most performance issues in backend apps don’t come from logic — they come from how data is fetched from the database. Today I focused on one of the most common JPA pitfalls: ❗ The N+1 Query Problem 💡 What happens: You fetch a list of entities (1 query) For each entity, JPA triggers another query for related data Result → 1 + N queries 👉 This can silently kill performance in production. 🔍 Example: Fetching a list of users and their orders: 1 query for users N queries for orders ❌ 🔧 Fix: Use JOIN FETCH Use Entity Graphs Choose fetch type wisely (LAZY vs EAGER) 🛠 Practical: Tested API behavior with lazy loading and saw how queries multiplied without optimization. 📌 Real-world impact: Ignoring this leads to: Slow APIs High DB load Poor scalability 🔥 Takeaway: ORMs don’t guarantee performance. You must understand what queries are actually being executed. Currently building a production-ready backend system — sharing real backend lessons daily. https://lnkd.in/gJqEuQQs #Java #SpringBoot #Hibernate #BackendDevelopment #Performance #LearningInPublic

🚀 Day 46: Mastering Data Binding in Spring MVC Continuing my Java Developer journey! Today was all about understanding how data moves from the frontend to my controllers and back. I spent the day diving deep into Spring MVC’s data handling capabilities. Here’s a breakdown of what I covered: @RequestParam vs. @PathVariable: Learned when to use Query Parameters (e.g., ?id=101) versus Path Variables (e.g., /user/101) to capture dynamic data from URLs. Data Binding (1-Way & 2-Way): 1-Way: Passing data from the Controller to the View using the Model object. 2-Way: Using Spring’s form handling to keep the View and the Model in sync, making form submissions seamless. Spring Tag Library: Explored how to use specialized JSP tags to bind form elements directly to Java objects, reducing boilerplate code and improving type safety. Seeing these pieces click together makes building web applications feel much more intuitive. Onward to Day 47! 👨💻 #Java #SpringFramework #SpringMVC #WebDevelopment #Backend #JavaDeveloper #LearningJourney #CodingLife #Telusko Hyder Abbas Naman Pahariya

In production Spring Boot services, scattered try-catch blocks create inconsistent API behavior. A better approach is centralized handling: ```@RestControllerAdvice public class GlobalExceptionHandler {   @ExceptionHandler(ResourceNotFoundException.class)   public ResponseEntity<ErrorResponse> handleNotFound(ResourceNotFoundException ex) {     return ResponseEntity.status(HttpStatus.NOT_FOUND)         .body(new ErrorResponse("RESOURCE_NOT_FOUND", ex.getMessage()));   }   @ExceptionHandler(MethodArgumentNotValidException.class)   public ResponseEntity<ErrorResponse> handleValidation(MethodArgumentNotValidException ex) {     return ResponseEntity.status(HttpStatus.BAD_REQUEST)         .body(new ErrorResponse("VALIDATION_ERROR", "Invalid request payload"));   }   @ExceptionHandler(Exception.class)   public ResponseEntity<ErrorResponse> handleGeneric(Exception ex) {     return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR)         .body(new ErrorResponse("INTERNAL_ERROR", "Unexpected error occurred"));   } }``` Benefits we observed: - Consistent contract for error payloads - Cleaner controllers/services - Accurate HTTP semantics (400, 404, 409, 500) - Better observability and incident response A strong error model is part of API design, not just exception handling. #SpringBoot #Java #Microservices #API #SoftwareEngineering #Backend

A small annotation that many developers overlook: @Transactional(readOnly = true) Does it really matter? Yes — but not in the way most people think. What it actually does: • Hints the persistence provider (e.g., Hibernate) to reduce dirty checking by adjusting flush behavior • Reduces overhead for read-heavy operations • May optimize transaction handling depending on configuration But here’s the catch: It does NOT: • Make queries faster automatically • Strictly prevent write operations at the database level In fact, if entities are modified, changes may still be flushed depending on the persistence context ❌ Real takeaway: Use readOnly = true for: • Pure read operations • High-throughput query services But don’t treat it as a safeguard against writes. Lesson: Framework optimizations are hints — not guarantees. #SpringBoot #Java #Transactions #Hibernate #BackendDevelopment #Microservices #SoftwareEngineering #JavaDeveloper