Java Program to Find Second Highest Number

🚀 Day 2 – Subtle Java Behavior That Can Surprise You Today I explored the difference between "==" and ".equals()" in Java — and it’s more important than it looks. String a = "hello"; String b = "hello"; System.out.println(a == b); // true System.out.println(a.equals(b)); // true Now this: String c = new String("hello"); System.out.println(a == c); // false System.out.println(a.equals(c)); // true 👉 "==" compares reference (memory location) 👉 ".equals()" compares actual content 💡 The catch? Because of the String Pool, sometimes "==" appears to work correctly… until it doesn’t. This small misunderstanding can lead to tricky bugs, especially while working with collections or APIs. ✔ Rule I’m following: Always use ".equals()" for value comparison unless you explicitly care about references. #Java #BackendDevelopment #JavaBasics #LearningInPublic

🚀 Day 20 – Optional in Java (Handling Nulls the Right Way) One common issue in Java: NullPointerException Today I explored how "Optional" helps handle this more safely. --- 👉 Traditional way: String name = user.getName(); if (name != null) { System.out.println(name); } --- 👉 Using "Optional": Optional<String> name = Optional.ofNullable(user.getName()); name.ifPresent(System.out::println); --- 💡 Why use "Optional"? ✔ Avoids direct null checks everywhere ✔ Makes code more readable and expressive ✔ Encourages better handling of missing values --- 💡 Useful methods: - "orElse()" → default value - "orElseGet()" → lazy default - "orElseThrow()" → throw exception if empty --- ⚠️ Insight: "Optional" is great, but should be used wisely—not for every variable, mainly for return types. --- 💡 Takeaway: Handling nulls properly = more robust and maintainable code #Java #BackendDevelopment #Java8 #Optional #CleanCode #LearningInPublic

🔥 Day 13: Optional Class (Java 8) Handling null values is one of the most common problems in Java — and that’s where Optional comes in 👇 🔹 What is Optional? 👉 Definition: Optional is a container object introduced in Java 8 that may or may not contain a non-null value. 🔹 Why use Optional? ✔ Avoids NullPointerException ❌ ✔ Makes code more readable ✔ Encourages better null handling 🔹 Common Methods ✨ of(value) → creates Optional (no null allowed) ✨ ofNullable(value) → allows null ✨ isPresent() → checks if value exists ✨ get() → gets value (use carefully ⚠️) ✨ orElse(default) → returns default if null ✨ ifPresent() → runs code if value exists 🔹 Simple Example import java.util.Optional; Optional<String> name = Optional.ofNullable(null); // Check value System.out.println(name.isPresent()); // false // Default value System.out.println(name.orElse("Default Name")); 👉 Output: false Default Name 🔹 Better Way (Recommended) Optional<String> name = Optional.of("Java"); name.ifPresent(n -> System.out.println(n)); 🔹 Key Points ✔ Optional is mainly used for return types ✔ Avoid using get() without checking ✔ Helps write cleaner and safer code 💡 Pro Tip: Use orElseThrow() when you want to throw exception instead of default value 📌 Final Thought: "Optional doesn’t remove null — it helps you handle it better." #Java #Optional #Java8 #Programming #JavaDeveloper #Coding #InterviewPrep #Day13

Why String Pool exists in Java (and how it actually works) ? Most developers know this: Java has something called a String Pool. But why does it even exist? The problem: Strings are used everywhere In real applications, the same string values get created again and again. Example: "hello" Without optimization, this would create multiple identical objects in memory. The solution: String Pool Java stores string literals in a special memory area called the String Pool. So instead of creating new objects every time: 👉 Java reuses existing ones How it works: When you write: String s1 = "hello"; String s2 = "hello"; Java checks the pool: If "hello" already exists → reuse it If not → create and store it So both s1 and s2 point to the same object But, String s3 = new String("hello"); This forces a new object creation even if "hello" exists in the pool. Why this matters: String Pool helps: • Save memory • Improve performance • Avoid unnecessary object creation #Java #JVM #StringPool #CSFundamentals #BackendDevelopment

🎯 Java Performance: String Concatenation Stop using `+` for string concatenation in loops: ```java // Bad - O(n²) String result = ""; for (int i = 0; i < 1000; i++) { result += i; // Creates new String each time } // Good - O(n) StringBuilder sb = new StringBuilder(); for (int i = 0; i < 1000; i++) { sb.append(i); } String result = sb.toString(); // Better - Java 8+ streams String result = IntStream.range(0, 1000) .mapToObj(String::valueOf) .collect(Collectors.joining()); ``` What's your Java performance lesson? #Java #Performance #StringBuilder #Optimization

Same result. Half the code. Most Java developers don’t use this 😱 Java Fundamentals Series | Part 21 Can you spot the improvement? 👇 List<String> names = Arrays.asList( "Alice", "Bob", "Charlie" ); // ❌ Verbose Lambda names.forEach(name -> System.out.println(name)); // ✅ Method Reference names.forEach(System.out::println); Cleaner. More readable. More professional. 💪 4 Types of Method References 👇 // 1. Static method Function<Integer, Integer> abs = Math::abs; // 2. Instance method of object Function<String, String> upper = String::toUpperCase; // 3. Instance method of instance String prefix = "DBS: "; Function<String, String> addPrefix = prefix::concat; // 4. Constructor reference Function<String, StringBuilder> builder = StringBuilder::new; Real-world example 👇 // ❌ Lambda transactions.stream() .map(t -> t.getAmount()) .forEach(a -> System.out.println(a)); // ✅ Method Reference transactions.stream() .map(Transaction::getAmount) .forEach(System.out::println); Summary: 🔴 Writing lambdas everywhere 🟢 Use method references when method already exists 🤯 Cleaner code = fewer lines + better readability ⸻ 👉 Posting more real-world fixes like this. Have you used method references? Drop a :: below 👇 #Java #JavaFundamentals #BackendDevelopment #LearningInPublic #SDE2

🚀 CyclicBarrier in Java — Small Concept, Powerful Synchronization In multithreading, coordination between threads is critical ⚡ 👉 CyclicBarrier allows multiple threads to wait for each other at a common point before continuing — ensuring everything stays in sync 🔥 💡 Think of it like a checkpoint 🏁 No thread moves forward until all have arrived! 🌍 Real-Time Example Imagine a report generation system 📊 Multiple threads fetch data from different APIs 📡 Each processes its own data ⚙️ Final report should generate only when all threads finish 👉 With CyclicBarrier, you ensure: ✅ All threads complete before aggregation ✅ No partial or inconsistent data ✅ Smooth parallel execution 💻 Quick Code Example import java.util.concurrent.CyclicBarrier; public class Demo { public static void main(String[] args) { CyclicBarrier barrier = new CyclicBarrier(3, () -> System.out.println("All threads reached. Generating final report...")); Runnable task = () -> { try { System.out.println(Thread.currentThread().getName() + " fetching data..."); Thread.sleep(1000); barrier.await(); System.out.println(Thread.currentThread().getName() + " done!"); } catch (Exception e) { e.printStackTrace(); } }; for (int i = 0; i < 3; i++) new Thread(task).start(); } } 💪 Why it’s powerful ✔️ Keeps threads perfectly synchronized ✔️ Prevents incomplete execution ❌ ✔️ Reusable for multiple phases ♻️ 🔥 Final Thought 👉 It’s a small but powerful feature — use it wisely based on your project needs to ensure the right level of synchronization without overcomplicating your design. #Java #Multithreading #Concurrency #BackendDevelopment #SoftwareEngineering

🚀 Day 14 – Java Collections: Choosing the Right One Matters Today I focused on the Java Collections Framework—not just what they are, but when to use what. We often use collections like: List<String> list = new ArrayList<>(); Set<String> set = new HashSet<>(); Map<String, Integer> map = new HashMap<>(); But the real question is: Which one should I choose? --- 💡 My understanding: ✔ List (ArrayList) - Allows duplicates - Maintains insertion order - Best for indexed access ✔ Set (HashSet) - No duplicates - No guaranteed order - Best when uniqueness matters ✔ Map (HashMap) - Key-value pairs - Fast lookup using keys --- ⚠️ Real insight: Choosing the wrong collection can: - Impact performance - Complicate logic - Introduce unnecessary bugs --- 💡 Example: - Need fast search → "HashMap" - Need ordered data → "List" - Need unique values → "Set" --- Small decision, but a big difference in real applications. #Java #BackendDevelopment #Collections #JavaInternals #LearningInPublic

This crashes in production at 2 AM. Every single time. 😱 Java Fundamentals A-Z | Post 22 Can you spot the bug? 👇 public String getUserEmail(int userId) { User user = userRepository.findById(userId); return user.getEmail(); // 💀 NullPointerException! } String email = getUserEmail(999); System.out.println(email.toUpperCase()); // 💀 CRASH! findById() returned null. Nobody checked. App crashes. Users complain. 2 AM alerts. 💀 Optional eliminates this forever 👇 // ✅ Return Optional — make null explicit! public Optional<String> getUserEmail(int userId) { return Optional.ofNullable( userRepository.findById(userId)) .map(User::getEmail); } // ✅ Caller handles safely! getUserEmail(999) .map(String::toUpperCase) .ifPresent(System.out::println); // ✅ Or use default value! String email = getUserEmail(999) .orElse("default@dbs.com"); // Never null! ✅ Optional eliminated 3 recurring NullPointerExceptions in our user service. 🔥 Optional cheat sheet 👇 — Optional.of() → value exists, never null — Optional.ofNullable() → value might be null — orElse() → default if empty — ifPresent() → only runs if value exists — map() → transform if present Summary: 🔴 Returning null and hoping caller checks it 🟢 Optional = explicit contract that value might be absent 🤯 Null checks disappeared from our entire user service Have you replaced null returns with Optional yet? Drop a 🎁 below! Posting real-world Java bugs and fixes. #Java #JavaFundamentals #BackendDevelopment #LearningInPublic #SDE2

🔒 ReentrantLock in Java - More Control than synchronized When multiple threads try to access the same shared resource, we need locking. Most developers use synchronized. But Java also provides ReentrantLock - a more flexible and powerful locking mechanism. Why "Reentrant"? Because the same thread can acquire the same lock again without getting blocked. That means: If Thread-A already holds the lock, it can re-enter another locked method/block using the same lock safely. No deadlock with itself. ✅ Why use ReentrantLock? • Can manually lock and unlock critical section • Supports tryLock() → avoids waiting forever • Supports lockInterruptibly() → thread can be interrupted while waiting • Can create fair locks (first come first serve) • Better control in complex multithreading scenarios 🧠 Simple Example: Lock lock = new ReentrantLock(); lock.lock(); try { // critical section count++; } finally { lock.unlock(); } ⚠️ Why finally unlock() is important? Because if exception occurs and lock is not released, other threads stay blocked. That can freeze your application. 🚀 When ReentrantLock is preferred over synchronized? ✔ Need timeout while acquiring lock ✔ Need interruptible waiting ✔ Need fairness policy ✔ Need advanced thread coordination Rule of Thumb: synchronized = simple locking ReentrantLock = professional level locking with control 👉 If you are preparing for Spring Boot backend interviews, connect & follow - I share short, practical backend concepts regularly. #Java #Multithreading #Concurrency #SpringBoot #BackendDevelopment #JavaDeveloper #Programming #InterviewPrep #Backend