Spring Boot Validation with @NotNull Annotation

Hi everyone 👋 Continuing the Spring Boot Validation Series part 28 👇 📌 Validation Annotation – @Size The @Size annotation is used to define minimum and maximum length for a field 👇 🔹 Why do we use @Size? Sometimes we need to restrict input length. 👉 Example: - Username should be at least 3 characters - Password should be at least 8 characters @Size helps us enforce these rules. 🔹 Simple Example - public class User { @Size(min = 3, max = 20) private String name; @Size(min = 8) private String password; } @PostMapping("/users") public String createUser(@Valid @RequestBody User user) { return "User created"; } 👉 If value is too short or too long → validation fails ❌ 🔹 Important Point 👉 @Size works with: - String - Collection (List, Set, etc.) - Arrays 🔹 Example with List @Size(min = 1, max = 5) private List<String> roles; 👉 Ensures list size is between 1 and 5 🔹 Common Mistake 👉 @Size does NOT check for null ❌ So often we combine it with: @NotNull @Size(min = 3, max = 20) private String name; 🔹 In simple words @Size controls how short or long a value can be. 👉 🧠 Quick Understanding - Used for length validation - Works on String, List, Array #SpringBoot #Java #Validation #SizeAnnotation #BackendDevelopment #LearningInPublic

👉Arrays vs ArrayLists. Looks similar. But difference matters! Many people start with Arrays. Fixed size. Simple syntax. Everything feels under control. Then comes ArrayList. Dynamic size. Easy to use. No need to worry about capacity. Sounds like ArrayList is better, right? Not always. That’s where the realisation comes in. 👉Arrays are faster. They use fixed memory. Better when size is known. 👉ArrayLists are flexible. They resize automatically. But come with slight overhead. Same data. Different behavior. And that difference shows up in performance. The real takeaway is simple. ✨Use Arrays when size is fixed and performance matters. ✨Use ArrayList when flexibility is needed. Don’t just learn syntax — understand use cases. 👉Because in the end, choosing the right structure > writing more code. 👉 When do you prefer Arrays over ArrayList? #DSA #Java #CodingJourney #SoftwareDevelopment #CareerGrowth

🎯Day 14 🎯 Problem Name: Implement Queue using Stacks 🚀 Problem Statement: Design a queue using two stacks. Implement the following methods: 1️⃣ push(x) - Add an element to the back of the queue. 2️⃣ pop() - Remove the element from the front of the queue. 3️⃣ peek() - Get the front element of the queue. 4️⃣ empty() - Return whether the queue is empty. 💡 Solution Approach: 1️⃣ Use two stacks stack1 (main) and stack2 (helper). 2️⃣ Push: Push all elements directly into stack1. 3️⃣ Pop/Peek: Transfer elements from stack1 to stack2, pop/peek the front element, and transfer elements back to stack1. 4️⃣ Empty: Check if stack1 is empty. 📊 Time Complexity: Push: O(1) O(1) Pop: O(n) O(n) (Transfer elements between stacks). Peek: O(n) O(n) (Similar to pop). Empty: O(1) O(1) 📊 Space Complexity: O(n) O(n) (Space for two stacks).  #CodingChallenge #Stacks #ProblemSolving #DataStructures #Java #LeetCode

Day 77/100 Completed ✅ 🚀 Solved LeetCode – Search a 2D Matrix II (Java) ⚡ Implemented an efficient approach by starting from the top-right corner of the matrix and eliminating rows or columns based on comparison with the target. This reduces the search space at every step, achieving O(m + n) time complexity. 🧠 Key Learnings: • Smart traversal in a sorted 2D matrix • Eliminating search space using row & column properties • Moving left (col--) when value is greater • Moving down (row++) when value is smaller • Better than brute-force (O(m × n)) approach 💯 This problem improved my understanding of matrix traversal strategies and how to optimize searching using sorted properties. 🔗 Profile: https://lnkd.in/gaJmKdrA #leetcode #datastructures #algorithms #java #matrix #problemSolving #optimization #arrays #100DaysOfCode 🚀

🎯Day 13 🎯 Problem Name: Implement Stack using Queues 🚀 Problem Statement: Design a stack using two queues. Implement the following methods: 1️⃣ push(x) - Push element x onto the stack. 2️⃣ pop() - Remove the element on top of the stack. 3️⃣ top() - Get the top element. 4️⃣ empty() - Return whether the stack is empty. 💡 Solution Approach: 1️⃣ Use two queues q1 (main) and q2 (helper). 2️⃣ Push: Add the new element to q2, then move all elements from q1 to q2. Swap q1 and q2. 3️⃣ Pop: Directly remove the front element of q1. 4️⃣ Top: Return the front element of q1. 5️⃣ Empty: Check if q1 is empty. 📊 Time Complexity: Push: O(n) O(n) Pop: O(1) O(1) Top: O(1) O(1) Empty: O(1) O(1) 📊 Space Complexity: O(n) O(n) (for the two queues). #CodingChallenge #Queues #ProblemSolving #DataStructures #Java #LeetCode

🎯 Day 9 🚶♀️➡️ 🚶♀️➡️🚶♀️➡️🚶♀️➡️🚶♀️➡️🚶♀️➡️🚶♀️➡️🚶♀️➡️🚶♀️➡️ Problem Name: Reorder List 🚀 Problem Statement: Given the head of a singly linked list, reorder the list in such a way that the nodes are rearranged as: First node → Last node → Second node → Second last node → and so on. 💡 Solution Approach: 1️⃣ Find the Middle: Use the slow and fast pointer technique to split the list into two halves. 2️⃣ Reverse the Second Half: Reverse the second half of the list using a pointer traversal. 3️⃣ Merge the Two Halves: Alternately merge nodes from the first and reversed second halves. 📊 Time Complexity: O(n) O(n) (Traverse the list three times: finding the middle, reversing, and merging). 📊 Space Complexity: O(1) O(1) (In-place operations with constant space). #CodingChallenge #LinkedList #ProblemSolving #DataStructures #Java #LeetCode

🚀 Day 15 – ArrayList vs LinkedList (It’s Not Just About Syntax) Today I explored the real difference between "ArrayList" and "LinkedList". List<Integer> list1 = new ArrayList<>(); List<Integer> list2 = new LinkedList<>(); At first glance, both implement "List"… but internally they are very different. --- 💡 ArrayList ✔ Backed by a dynamic array ✔ Fast for random access (get by index) ✔ Slower for insert/delete in middle (shifting required) --- 💡 LinkedList ✔ Uses a doubly linked list ✔ Faster for insert/delete (no shifting) ✔ Slower for access (traversal needed) --- ⚠️ Real insight: In most real-world scenarios, "ArrayList" is preferred due to better cache locality and overall performance. 👉 "LinkedList" is useful only when: - Frequent insertions/deletions in the middle - Less need for random access --- 💡 Takeaway: Don’t choose based on interface—choose based on use case and internal behavior #Java #BackendDevelopment #Collections #ArrayList #LearningInPublic

Hi everyone 👋 Continuing the Spring Boot Validation Series Part 29 👇 📌 Validation Annotations – @Min & @Max @Min and @Max are used to validate numeric values 👇 🔹 Why do we use them? Sometimes we need to restrict numbers to a certain range. Age should be at least 18 Quantity should not exceed 100 @Min and @Max help enforce these rules automatically. 🔹 Simple Example public class User { @Min(18) private int age; @Max(100) private int score; } @PostMapping("/users") public String createUser(@Valid @RequestBody User user) { return "User created"; } 👉 If age < 18 or score > 100 → validation fails ❌ 🔹 Important Points Works with numeric types: int, long, double, BigDecimal Often combined with @NotNull to ensure value is provided @NotNull @Min(1) @Max(100) private Integer quantity; 🔹 In simple words @Min → number must be greater than or equal to specified value @Max → number must be less than or equal to specified value 👉 🧠 Quick Understanding @Min(value) → minimum allowed value @Max(value) → maximum allowed value Works with all numeric types Often combined with @NotNull #SpringBoot #Java #Validation #MinMaxAnnotation #BackendDevelopment #LearningInPublic

If your class name looks like CoffeeWithMilkAndSugarAndCream… you’ve already lost. This is how most codebases slowly break: You start with one clean class. Then come “small changes”: add logging add validation add caching So you create: a few subclasses… then a few more or pile everything into if-else Now every change touches existing code. And every change risks breaking something. That’s not scaling. That’s slow decay. The Decorator Pattern fixes this in a simple way: Don’t modify the original class. Wrap it. Start with a base object → then layer behavior on top of it. Each decorator: adds one responsibility doesn’t break existing code can be combined at runtime No subclass explosion. No god classes. No fragile code. Real-world example? Java I/O does this everywhere: you wrap streams on top of streams. The real shift is this: Stop thinking inheritance. Start thinking composition. Because most “just one more feature” problems… are actually design problems. Have you ever seen a codebase collapse under too many subclasses or flags? #DesignPatterns #LowLevelDesign #SystemDesign #CleanCode #Java #SoftwareEngineering #OOP Attaching the decorator pattern diagram with a simple example.

Stop labeling your Spring Beans randomly! 🛑 I see many projects where @Component, @Service, and @Repository are used interchangeably. They all register a Bean in the context, so they are the same, right? Not exactly. Using the right stereotype is about Communication and Semantics. 🔹 @Service: Clearly states: "This is where the business logic lives." It's your domain's heart. 🔹 @Repository: Signals: "I talk to the database." Spring provides an extra layer of magic here: it automatically translates platform-specific exceptions (like SQLException) into Data Access Exceptions. 🔹 @Component: The generic catch-all. Use it for utility classes or anything that doesn't fit the service/repository pattern. Tip: Using the correct label makes your code readable for the next dev. It tells a story about what each class is responsible for before they even read a single line of implementation. How strict is your team with stereotyping their Spring components? Let’s talk below! 👇 #Java #SpringBoot #SoftwareArchitecture #CleanCode #Backend #SpringFramework #CleanDesign