María Arias de Reyna Domínguez on Project Leyden's Java Performance Optimization Strategies

How is Project Leyden improving Java Performance? María Arias de Reyna Domínguez breaks down the fundamentals of Project Leyden in this first part of a three-part series. This article covers the basics: what Project Leyden aims to achieve, why it matters for Java applications, and the key concepts behind its optimization approach. If you're interested in Java's evolution and performance improvements, this is a good starting point. Read the full article: https://lnkd.in/dZqEaCxj Written by María Arias de Reyna Domínguez #Java #ProjectLeyden #Performance #JVM

How is Leyden improving Java Performance? Part 3 of 3 of our series on Project Leyden is now available on Foojay. María Arias de Reyna Domínguez wraps up this comprehensive look at how Project Leyden aims to enhance Java's startup time, time to peak performance, and footprint. This concluding article covers the practical aspects and real-world implications of the changes coming to the Java ecosystem. If you've been following parts 1 and 2, this is the piece that ties everything together. New to the series? You can still jump in and get valuable insights. Read the full article: https://lnkd.in/eihVDgKh #Java #ProjectLeyden #Performance #OpenJDK

Ever run into a ClassNotFoundException that made you want to pull your hair out? 🤯 Or worse, a LinkageError that defied all logic? Understanding the Java ClassLoader Delegation Hierarchy is crucial for any developer aiming to build robust and reliable applications. In this post, we'll break down this fundamental concept and explore the nuances of the Java ClassLoader. What is the Java ClassLoader? In Java, classes aren't loaded into memory all at once. The Java Virtual Machine (JVM) uses a ClassLoader to load classes as they are needed during runtime. There's not just one ClassLoader; they form a hierarchy. The Delegation Model The key to understanding the ClassLoader is the delegation model. When a ClassLoader needs to find a class, it doesn't just look in its own path. Instead, it follows a simple yet effective rule: Ask your parent first. This delegation continues up the chain. Only if no parent ClassLoader can find the class will the current ClassLoader try to find it itself. This prevents duplicate class definitions and maintains system security by ensuring core classes (like java.lang.String) are always loaded by the most trusted ClassLoader. Standard vs. Custom Delegation While the default delegation model works beautifully for most Java applications, complex environments like OSGi (Open Services Gateway initiative) require a more specialized approach. These modular systems need precise control over class visibility and versions, which the standard parent-first approach can struggle to provide. In such cases, a custom, child-first delegation model is used. The Challenge: Child-First/OSGi-style Delegation A child-first model prioritizes the local bundle's ClassLoader. However, this comes with its own set of challenges, particularly "split package" scenarios where different parts of the same package are loaded by different ClassLoaders. This can lead to the dreaded LinkageError. The graphic below illustrates the distinction between Standard and Custom delegation. The standard path is smooth sailing, but the custom route is a potential minefield of collisions! 💥 What are your experiences with ClassLoader issues? Share your stories and tips for troubleshooting in the comments below! 👇 #Java #ClassLoader #OSGi #Development #Programming #LinkageError

Java Streams Series – Day 7 Today I explored an efficient approach to check whether a string is a palindrome using Java Streams. Instead of using traditional loops or reversing the string, this approach applies a functional style to compare characters from both ends, progressing toward the center. By iterating through only half of the string, it maintains optimal performance while keeping the implementation concise and readable. This reinforces how Java Streams can help write clean, declarative, and efficient code for common problems. #Java #JavaStreams #CleanCode #FunctionalProgramming #100DaysOfCode

Today I explored the Executor Service in Java, and it completely changed how I think about multithreading. Instead of manually creating and managing threads (which can get messy very quickly), Executor Service provides a structured and scalable way to handle concurrency using thread pools. Here’s what stood out to me: • You don’t create threads directly — you submit tasks • It manages thread lifecycle efficiently • Supports both Runnable (no return) and Callable (returns result) • Works with Future to track task completion and results • Helps avoid performance issues caused by excessive thread creation One simple shift: From this 👇 new Thread(task).start(); To this 👇 executorService.submit(task); That small change brings better control, scalability, and cleaner code. Still exploring concepts like: • Fixed vs Cached Thread Pools • Future vs FutureTask • How thread pools actually work internally The more I learn, the more I realize — writing concurrent code isn’t just about “making things run in parallel”, it’s about managing resources smartly. If you’ve worked with Executor Service in real projects, I’d love to hear your experience 👇 #Java #Multithreading #BackendDevelopment #LearningInPublic #ExecutorService

📈 Does Java really use too much memory? It’s a common myth but modern Java tells a different story. With improvements like: ✔️ Low-latency garbage collectors (ZGC, Shenandoah) ✔️ Lightweight virtual threads (Project Loom) ✔️ Compact object headers (JEP 450) ✔️ Container-aware JVM & Class Data Sharing Java today is far more memory efficient, scalable and optimized than before. 💡 The real issue often isn’t Java it’s: • Unbounded caches • Poor object design • Memory leaks • Holding unnecessary references 👉 In short: Java isn’t memory hungry it’s memory aware. If your app is consuming too much RAM, start profiling your code before blaming the JVM. #Java #BackendDevelopment #Performance #JVM #SoftwareEngineering

Most Java devs write code every day without knowing what happens beneath it. This one diagram changed how I think about Java forever. 👇 Here's the complete internal working of the JVM + Garbage Collector — explained visually: 🔵 Class Loader → Loads your .class bytecode. Verifies it. Prepares it. Resolves it. All before execution begins. 🟣 Method Area → Stores class-level data, static variables & method code. Shared across all threads. 🟠 Heap (The heart of GC) ↳ Young Gen (Eden + Survivor) → New objects born here ↳ Old Gen → Long-lived objects promoted here ↳ Metaspace → Class metadata (replaced PermGen in Java 8+) 🟢 JVM Stack → Every thread gets its own stack. Every method call = one Stack Frame. 🔴 Execution Engine ↳ Interpreter → reads bytecode (slow start) ↳ JIT Compiler → converts hot code to native (blazing fast) ↳ Garbage Collector → watches Heap, frees dead objects automatically ♻️ Repost to help a Java developer in your network. Someone needs this today. #Java #JVM #GarbageCollection #JavaDeveloper #BackendDevelopment #SpringBoot #InterviewPrep #JavaInterview #Microservices #SoftwareEngineering #Coding #Programming

Today, with records, better IDE support, and a much more mature Java, adding Lombok to every new project feels a bit like installing turbo in a Corolla just to go to the bakery. That said, I wouldn’t turn this into a holy war. In legacy systems, Lombok can still be practical. But for new code, I agree: prefer plain modern Java first, and add dependencies only when they solve a real problem. Less magic, less hidden code, fewer surprises after a JDK upgrade. At this point, modern Java is basically saying: “Thanks Lombok, we got it from here.”

Largely agree with this take. Lombok solved a real pain point in Java, but a lot of what made it essential years ago is now built into the language or easily handled by modern IDEs. Records, var, and try-with-resources have removed much of the boilerplate Lombok used to justify. And beyond convenience, reducing dependency on annotation processors and compiler internals is usually a good architectural decision. The biggest point for me: immutability and explicitness win. Records encourage safer defaults, clearer intent, and fewer ways to put objects into invalid states. That said, Lombok can still be practical in legacy codebases, so this is less about “rip it out everywhere” and more about “stop reaching for it by default in new projects.”