Tobias Unger’s Post

Go vs Java: my 2025 take on multithreading ⚔️ Go or Java for crazy concurrency? Actually both of them just with different ergonomics 😅 The mental model 🧠 Go: go fn() spawns a goroutine; the runtime’s G-M-P scheduler multiplexes tons of goroutines onto few OS threads. Blocking is cheap, so writing straightforward code is fine Java: Before, threads ≈ OS threads (expensive). Since Java 21, virtual threads make “one-request-per-thread” practical again with the same Thread API. Coordination style? Go: CSP out of the box channels for hand-off/backpressure; fall back to sync/atomics when needed Java: Keep locks/executors/futures, just swap pool workers for virtual threads and write simple blocking I/O. Oracle positions them for high-throughput, mostly I/O-bound apps. Memory guarantees 🔒 Go: Read the Go Memory Model visibility via happens-before (channels, mutexes, atomics). Don’t share without sync Java: The JMM rules stay the same; virtual threads change cost, not semantics. When you need pick what 🎯 Go for tiny deploys, fast startup, CSP pipelines, network services/workers the scheduler makes “just block” a sane default Java for the ecosystem/tooling (Spring, JDBC, etc.) and now massive concurrency without reactive rewrites thanks to virtual threads. Bottom line: Go popularized cheap concurrency; Java 21 closed the cost gap while keeping the classic API. Bench it under your workload and let the numbers speak. 📊 #golang #java #loom #virtualthreads #concurrency #multithreading #backend #performance

The Java Feature That Makes Lambdas Even Cleaner When Java added lambdas in Java 8, I was thrilled — no more anonymous inner classes everywhere. But then I discovered method references, and my code got even cleaner. They use the :: operator to pass a method directly, without writing the lambda wrapper. Before (with lambdas): users.stream() .map(u -> u.getEmail()) .forEach(e -> System.out.println(e)); After (method references): users.stream() .map(User::getEmail) .forEach(System.out::println); Same logic. Less noise. It’s one of those features that looks small, but adds real clarity once you start using it. Why I like it: ✅ Removes redundant syntax (u -> u.method()) ✅ Easy to read when used sparingly ✅ Works for static methods, instance methods, and constructors You can even do this: Supplier<User> createUser = User::new; It’s been around since Java 8, but it still feels like modern, expressive Java to me. 👉 Do you use method references often, or do you still prefer the explicit lambda style? #Java #CleanCode #SoftwareEngineering #Java17 #Lambda #Refactoring

I recently experimented with Virtual Threads in Java 21, and the performance improvement was honestly impressive. For years, Java developers (including me) have been limited by the cost of traditional threads. Each thread maps directly to an OS thread, which consumes a lot of memory and doesn’t scale well for high concurrency. With Virtual Threads, that model changes completely. These are lightweight, JVM-managed threads that allow you to create tens or even hundreds of thousands of concurrent tasks — without killing performance or memory. What I tested: I wrote a small program that performs 10,000 HTTP GET requests to an external test endpoint using the standard HttpClient with blocking I/O. I ran it twice — once with regular threads, once with virtual threads. The results: Platform threads (traditional): 1,000 requests → ~25 seconds, ~600 MB memory 10,000 requests → Failed (OutOfMemoryError) Virtual threads (Java 21): 1,000 requests → ~3 seconds, ~200 MB memory 10,000 requests → ~5 seconds, ~350 MB memory That’s roughly a 5x–10x improvement in time and efficiency. The JVM handled thousands of concurrent blocking operations smoothly. What I learned: Virtual Threads are perfect for I/O-bound workloads (like HTTP or database calls). Using Virtual Threads in Java 21 can significantly improve scalability and reduce infrastructure costs, saving a lot of money for the company by handling more concurrent requests with fewer servers and lower resource usage. You can write simple, blocking-style code that scales like async code. The code is cleaner, easier to read, and performs far better under load. For CPU-heavy tasks, platform threads or fixed pools are still better. This feels like a big step forward for Java. With frameworks like Spring Boot 3.2+ already adding support for Virtual Threads, I can see this becoming the default way to write scalable backends. If you haven’t tried it yet, I highly recommend experimenting with it. You might be surprised how much performance and simplicity you gain — without rewriting your code.

🚀 When Java’s HashMap Switches from Linked List to Balanced Tree — and Why It Matters! Did you know that Java’s HashMap got smarter since Java 8? 😎 When multiple keys land in the same hash bucket (due to hash collisions), older versions of Java stored them in a linked list — giving O(n) lookup time in the worst case. But Java 8+ said: “Let’s fix that!” 🔧 Here’s what happens now 👇 ✅ If a bucket gets 8 or more entries, it’s converted from a LinkedList to a Balanced Red-Black Tree. ✅ This makes lookups much faster — turning worst-case O(n) into O(log n). ✅ If the number of entries later drops below 6, it switches back to a linked list. ✅ Treeification only happens when the map capacity is at least 64 — otherwise, it just resizes. 💡 Performance insight: You’ll almost never notice this change in everyday use — because good hash distribution keeps buckets small. But it’s a great defensive design that keeps your application safe from performance drops or hash-collision attacks. 🔍 Pro tips for developers: Always implement a strong hashCode() for custom objects. Initialize maps with a sensible capacity if you know their expected size. Remember, this feature doesn’t replace good design — it’s just a safety net! 📊 In short: Java 8’s HashMap automatically switches to a red-black tree when collisions get heavy, improving lookup speed from O(n) → O(log n). #Java #SpringBoot #HashMap #Coding #Performance #Java8 #DeveloperTips #TechLearning

💡 Is the finally block losing its importance in modern Java? If you’ve been working with Java for a while, you’ve surely used the finally block — the trusty companion that ensures resources are released no matter what happens in your try block. Example 👇 FileInputStream fis = null; try { fis = new FileInputStream("data.txt"); // process file } catch (IOException e) { e.printStackTrace(); } finally { if (fis != null) { try { fis.close(); } catch (IOException e) { e.printStackTrace(); } } } ✅ The intention was solid — guarantee cleanup, even when exceptions occur. ⚠️ But the problem? The finally block itself can throw exceptions or mask the original one. For example, if fis.close() fails, the real cause of the failure inside try might be lost. That’s why modern Java developers have largely moved away from finally for resource handling. 🚀 Enter try-with-resources (Java 7+) It automatically closes resources that implement AutoCloseable, making your code safer and cleaner. Example 👇 try (FileInputStream fis = new FileInputStream("data.txt")) { // process file safely } catch (IOException e) { e.printStackTrace(); } ✨ Benefits: No need for explicit finally cleanup. Prevents resource leaks. Preserves the original exception. More concise and readable code. So yes — the finally block still exists, but in most cases, it’s been gracefully replaced by try-with-resources, the safer and modern approach. #Java #CodingTips #Developers #CleanCode #JavaProgramming #ExceptionHandling #SoftwareEngineering

Why Every Developer Should Master Java 8 Even after more than a decade since its release, Java 8 continues to be one of the most impactful updates in the history of the Java platform. 💡 The Paradigm Shift Before Java 8, Java was purely imperative — you told the compiler how to do something. With Java 8, we moved toward a more declarative and functional style — you describe what needs to be done. This opened the door to writing cleaner, more concise, and parallelizable code. 🔍 Core Features That Changed Everything Lambda Expressions (→) Allow methods to be passed around as arguments, leading to more compact and readable code. list.forEach(item -> System.out.println(item)); No more verbose anonymous classes! Streams API A powerful tool for processing collections declaratively. You can filter, map, and reduce data in a single, elegant pipeline: List<String> result = list.stream() .filter(name -> name.startsWith("A")) .map(String::toUpperCase) .toList(); Behind the scenes, Streams can even leverage parallel processing for better performance. Functional Interfaces Interfaces with a single abstract method, like Predicate, Function, and Consumer. They’re the backbone of Lambdas — making functional programming in Java possible. Optional Class A smart wrapper for handling null safely and elegantly — helping reduce those dreaded NullPointerExceptions. Date and Time API (java.time) Finally, a modern, immutable, and thread-safe way to handle dates and times. #Java #Java8 #CodingTips #SoftwareEngineering #CleanCode #FunctionalProgramming #StreamsAPI #LambdaExpressions #DeveloperCommunity #TechLeadership

I wrote an article about Java classes—still in wide use today—that have had better replacements available for more than ten years and, in some cases, almost 30 years. I explain some of the problems with the old classes and what to use instead. Your code maintainers will thank you for using the replacement classes. https://lnkd.in/gRTyssRR

🚀 Top 3 Features of Java 8 🤔 Java 8 - The version that bridged the gap between classic & modern Java👇 1️⃣ STREAMS API 🔹Elegant Data Processing 🔹e.g., list. stream().filter(n -> n > 10).forEach(System.out::println); 🔹Process collections declaratively, no more manual loops. Streams let you filter, map, and reduce data in a clean, parallelizable way. 2️⃣ LAMBDA EXPRESSIONS 🔹Functional Power Unleashed. 🔹e.g., list.forEach(item -> System.out.println(item)); 🔹Simplify your code by treating behavior as data. Lambdas make your code concise, readable, and perfect for functional programming patterns. 3️⃣ OPTIONAL 🔹Goodbye to NullPointerException 🔹e.g., String result = Optional.ofNullable(name).orElse("Unknown"); 🔹A neat wrapper that encourages safer code by making the presence or absence of values explicit. 💡Even years later, Java 8 remains the foundation of modern Java development. #Java8 #SoftwareDevelopment #LambdaExpressions #StreamsAPI #OptionalClass #CodeBetter #CleanCode #FunctionalProgramming

Today I learned that from Java 23+ all annotation processors have been explicitly disabled by default. Before Java 23 the full classpath was scanned for any processors and those were automatically picked up. An attacker could exploit this by slipping a malicious processor into one of the many dependencies in your project. Otherwise known as a supply chain attack. That is why Bob stopped working according to some of my colleagues who switched from Java 21 to 25. Turned out it wasn't Bob after all. As such I updated Bobs documentation on how to explicitly set the annotation processor so you can happily generate your builders! https://lnkd.in/eQjD7hcq #java

💡Practical Use of Java 8 Streams — Think Beyond Just Loops Ever found yourself writing long loops just to filter or transform data from a list? That’s where Java 8 Streams shine — clean, readable, and efficient. Let’s look at a real-world example 👇 Imagine you have a list of employees and you want to: • Get all employees earning more than ₹50,000 • Sort them by salary (descending) • Collect just their names Before Java 8: List<String> result = new ArrayList<>(); for (Employee e : employees) { if (e.getSalary() > 50000) { result.add(e.getName()); } } Collections.sort(result); With Streams: List<String> result = employees.stream() .filter(e -> e.getSalary() > 50000) .sorted(Comparator.comparing(Employee::getSalary).reversed()) .map(Employee::getName) .collect(Collectors.toList()); ✅ Readable – you describe what to do, not how to do it ✅ Chainable – each step flows like a pipeline ✅ Parallelizable – add .parallelStream() for large datasets Key takeaway: Streams make your code more declarative, concise, and less error-prone. Once you start using them, you’ll rarely go back to old-style loops. Question for you 👇 What’s one Stream operation you use the most — filter, map, or collect? #Java #Programming #Streams #Java8 #CleanCode #CodingTips