Forem: Linh Nguyen

#Rant: Java Is Not Dead, It Is Not Cool, It Is Lukewarm, But It Is Far From Dead!

Linh Nguyen — Wed, 04 Feb 2026 04:09:18 +0000

The original article is located here.

So, Java is dead. Again. For the unknown time this year, apparently.

The Uncomfortable Truth

It is now the early part of 2026, and yet, Java is still among the most popular programming languages, and especially dominates in the enterprise zone. Like a cockroach surviving a nuclear winter, Java just keeps chugging along, powering banks, e-commerce giants, and probably the app that processes your coffee order.

You ask why, and I shall give you answers.

The Lukewarm Reality

Java has existed for over 30 years now. Not too old compared to COBOL, but not too young to look shiny and cool like the new kids Go, Dart, etc...

Also:

Python is a few years older than Java (created in 1991, compared to Java being created in 1995). But because Python is more ~~handsome~~ concise, people think Java is the older one. It's like how everyone assumes the quiet kid in class is older because they seem so serious, while the loud, energetic one must be younger.

Being old means being widely adapted. And that means enterprises didn't want breaking changes. When you have a system processing millions of transactions per day, "move fast and break things" suddenly sounds like a lawsuit waiting to happen.

Sure, JVM costs some memory, and sure, startup time can be better, and its cloud service bills can scare you. But it is hardened, battle proven, constantly optimized, intelligent enough to make your app stable, fast and durable, and its tools are mature.

There is little reason to tell a bank to just dump Java to use Go or .NET or Python. No real benefits, actually.

Remember When They Said...

They once said: Applet is dead (it will get axed in JDK 26, scheduled to be released in March 2026), Flash is the future (spoiler alert: Flash got axed too). Turns out the web moved on, but Java didn't need applets to survive.

They said: Swing is ugly (yes, it abstracts over the UX provided by the host OS). And therefore, we now have React Native polluting everything (looking at you, Windows 11!), its RAM usage comparable to a single JVM instance. The irony is delicious.

And JavaFX? We don't talk about JavaFX.

But Wait, There's More

But did Java just exist in already existing systems, tied to its legacy reputation?

Hmm, not quite.

Just because some ugly, bloated code was written by devs who got pressured by deadlines doesn't mean the language itself is bad. Ugly Python is still... ugly, if not a bit more due to indentation madness. Bad code is bad code, regardless of the language choices.

Starting from JDK 9 in 2017, Java entered the 6-months release cycle, bringing faster testing, faster feedback, and more transparent communication between users and the JDK team.

A lot of projects like Amber (enhance quality of life when writing code), Valhalla (code like a class, work like an int), and Loom (Virtual Threads) are actively making Java attractive. These aren't just cosmetic changes; they're fundamental improvements that make Java feel modern again.

From JDK 8 (itself was a big change in 2014) to JDK 21, a lot has changed. The development experience has increased significantly. Records, sealed classes, pattern matching, text blocks... these features make Java feel fresh. Unless, of course, you brought the mindset of Java 8 to work with a project that uses Java 21.

So, for newer projects, Java is still a solid choice to start anew. There are still plenty of jobs available for Java developers all around the world.

Admit it, your eyes shine when you hear you can code in JDK 17 and Spring Boot 3.

Real World Examples

Active cases like Netflix building and embracing its entire ecosystem in Java, or Amazon heavily using Java for AWS are examples of how Java is still very hot and sexy. These aren't legacy systems limping along; these are cutting edge platforms choosing Java:

Netflix recently migrated thousands of services from JDK 8 to JDK 17+, achieving 20% less CPU time on garbage collection. They're using modern features like generational ZGC for near-zero pause times and Spring Boot with GraphQL Federation through their open-source DGS framework.
AWS added Java 25 support to Lambda in late 2025, and Amazon Q Developer now assists with upgrades to Java 21. Major cloud providers actively invest in Java tooling because their customers demand it.

Oh, Google uses Kotlin for Android apps, but nothing prevents you from using Java to write one. The compatibility is there, the tooling is there, the choice is yours. Though fair disclosure: over 90% of Android developers now prefer Kotlin for new development, but Java remains fully supported and essential for maintaining existing codebases.

Beyond traditional enterprise, Java powers the entire big data ecosystem. Apache Hadoop and Apache Spark are Java-based, processing petabytes of data daily. The Hadoop market alone is projected to hit $196.53 billion in 2025. Java's reliability and performance make it increasingly popular for AI and machine learning platforms too. And let's not forget that tools like Elasticsearch, Cassandra and Kafka are written in Java, too!

Visiting JEP 0 Page and you will see a lot of Enhancement Proposals being made to make Java even better. The language is evolving, adapting, improving.

The Numbers Don't Lie

Over 90% of Fortune 500 companies use Java. The language ranks #3-4 globally in popularity indices. An estimated 18.7 million Java developer jobs are projected between 2024-2026, with median salaries of $116,000 in the US, up 11% over five years.

The Real Java

Java isn't a cool kid in the traditional sense, but it is a mature and responsible person who has seen enough of life and gained better appreciation for it. It's the friend who shows up on time, helps you move apartments, and actually remembers your birthday.

So, Java still being relevant is due to two main reasons:

Enterprise inertia;
Its new, shiny toys that are still very attractive to newer projects, as well as various improvements to the ecosystem.

The Verdict

Is Java dead? Not quite.

Is Java cool? Probably not. Java is verbose. But the recent additions to the language will make coding in Java "sexier". Just don't use JDK 8 as a baseline; the new one is now JDK 17!

But... There is always a catch

If some recruiters tell you to work with a project using JDK 8 and Spring Boot 2, chances are high that it is a red flag job. Java got its bad reputation mostly from bloated, unstable and brittle old legacy codes (again, not Java's fault, but whoever was in charged of said codes), and chances are that you don't want to get stuck in such a project. JDK 17 is the new norm now. We don't live in the pre-Covid era anymore.

But What About...

Python is cooler? Cool, but try making sense of GIL (recently became optional in the 3.14 version) or indentation, and unexpected runtime errors that only show up in production.

JavaScript is better? Why did they have to invent TypeScript then?

Kotlin replacing Java? Maybe, but not in a foreseeable future. Groovy and Scala tried to, and look where they are now (if TIOBE is reliable, then Scala is at #33 and Groovy is not even among the top 50).

Is Java fast? Its memory usage and startup time can be improved, but once everything is set, its speed, with a warm enough JVM, can be very close to native C/C++.

No language is perfect. Understanding advantages and tradeoffs, and you will see why people still choose Java in 2026.

Final Thoughts

So yeah, Java is "dead" again. See you next week when someone writes another blog post declaring its demise for the n+1 time.

Java isn't going anywhere. Deal with it.

[Boost]

Linh Nguyen — Tue, 18 Nov 2025 06:29:50 +0000

Remember to Make Use Of Lazy Evaluation

Linh Nguyen ・ Nov 18

#java

Remember to Make Use Of Lazy Evaluation

Linh Nguyen — Tue, 18 Nov 2025 03:50:32 +0000

Sometimes, being lazy is good. But that's no excuse for being lazy in work! It is only a valid excuse in programming if you apply at the right time and right place. The original article is here.

Our Simple Example of Null-Coalescing

Let's take this simple null-coalescing example:

var object = object == null 
    ? getDefaultObject() 
    : object;

A simple but elegant solution when you want to assign a default value to a variable if the object is null. Classic Java 101!

Then, you get fancy and create a helper method to adhere to the DRY principle:

// Sweet, sweet juicy usage of generics
<T> T getOrDefault(T object, T defaultValue) {
  return object == null
    ? defaultValue
    : object;
}

Also, FYI:

DRY principle stands for Don't Repeat Yourself (ironically, I just repeated that)

And then, riding high on your DRY-fueled motivation, you refactor your entire code base like a caffeinated code warrior. You feel invincible. You feel productive. You feel... oh so proud of yourself.

Hold your horses, cowboy!

When Reality Hits (Hard)

Before your brain drowns in dopamine, and you start updating your LinkedIn with "Refactoring Ninja" as a skill, let me burst your bubble with a question:

What do you think will happen in this code snippet?

var object = getOrDefault(object, expensiveComputation());

Plot twist: The expensiveComputation() will ALWAYS execute, regardless of whether our lovely object is null or not. Surprise! Java won't help you optimize the hell out of this, so you are on your own!

The consequences?

Could range from wasting precious CPU cycles (your laptop fan is already judging you) to the dreaded "oh no, I've accidentally launched the nuclear missiles twice" scenario. That's programmer speak for "your non-idempotent operations fired twice and caused chaos that should've only happened once, but here we are, with two charges on the customer's credit card and an angry email in your inbox."

Catastrophic indeed.

Is There a Fix?

TL;DR: Yes, but you will need JDK 8+. Otherwise, you will need some ugly modification or even give up and switch to JavaScript or Python.

Use lazy evaluation.

Or in layman's terms, use Supplier<T>. Think of it as saying "I'll tell you the answer... but only when you actually need it."

Specifically, don't delete your current helper method yet (we're collectors, not destroyers). We'll add an overloaded one:

// Are you ready to get your OCP certificate?
// This is the bliss of Generics Usage
<T> T getOrDefault(T object, Supplier<? extends T> defaultValueSupplier) {
  return object == null
    ? defaultValueSupplier.get()
    : object;
}

And then, modify the expensive method call like this:

var object = getOrDefault(object, () -> expensiveComputation());

You can now rest easy knowing that expensiveComputation() will only be called if your shiny object is null. Otherwise? It stays asleep. Lazy. Unbothered. Living its best life.

And to think that the humble ternary operator from our first example could masterfully handle both eager and lazy evaluation without the hassle of having two methods. Truly a How do you do, fellow kids moment for the ages.

No, No, No, Don't Press the Delete Button!

But wait, don't delete the original helper method! It's still useful. Let's talk about when to use which:

The eager evaluation version is perfect for already computed values (simple getters, defined constants, that sort of thing). It's like having fast food: already prepared, ready to go, no waiting.
The lazy evaluation one is suitable when the default value requires invoking some rather expensive computations.
On the other hand: using lazy evaluation on already computed values is wasteful. You're creating a Supplier<T> wrapper just to contain a value that's already sitting right there. It's like gift-wrapping a gift that's already unwrapped. Inefficient and slightly ridiculous.

Choose your approach carefully! Know what you need to do, and know which method to use (both versions are lovingly supported by Apache Commons Lang 3 libraries, bless their hearts). Our null-coalescing task is just a simple one, but the same principle can also be applied to other stuff, for example: hit the database only if the cache does not contain our desired value.

Java's Funny Little Heresies

Linh Nguyen — Fri, 14 Nov 2025 04:53:10 +0000

Okay, calling them heresies may be a bit overexaggerating. Calling them quirks or gotcha would be more appropriate. So let's dig into some of the Java's most unexpected gotcha.

When 1000 Is NOT Equal to 1000

You saw this kind of post all over LinkedIn, by people who copy/paste and then post to their profile. No charges here, just a funny poking.

TL;DR:

Integer a = 1000;
Integer b = 1000;

// Yes, you don't use this method
// But this is to prove the point
Assertions.assertFalse(a == b); // a == b will return false

Ah, yes, the classic equality by identity versus equality by value. Never ever compare two objects using == if your intention was to compare their values (the exception being enum).

But this will return true:

Integer a = 100;
Integer b = 100;

Assertions.assertTrue(a == b); // True

For Integer, value from -128 to 127 (by default) are cached, so you have this funny ~~heresy~~ gotcha.

And then again, why would you use Integer instead of int?

The Great Type Erasure

The code below will NOT compile:

class Utils {

  void doSomething(List<String> strings) {
    // Do something
  }

  void doSomething(List<Integer> ints) {
    // Do something
  }
}

You will get a nasty warning:

'doSomething(List<String>)' clashes with 'doSomething(List<Integer>)'; both methods have same erasure

That's not your fault, that is how Java becomes too committed to preserve backward compatibility. At runtime, the types are erased, leading to two methods with identical signature doSomething(List), and by the ultimate rule of overloading, this is not acceptable.

Can this ever be fixed? Who knows? Will Valhalla fix this? Probably? Do people use Java version 4 or less? They are now old boomers now.

The original intention of Generics was mainly to turn the nasty ClassCastException hiccups during runtime to errors that can be caught by compiler, so yeah, get used to it.

Unsigned When?

Why didn't Java have unsigned data types? Is there any reason why this was not a thing in Java? Can I have an int value of 4 billion without needing the 8 bytes of long?

String's Questionable Immutability

Read my post here.

The Collection Shenanigans

Look at this code:

Collection<Integer> collection = new ArrayList<>(Arrays.asList(1, 2, 3, 4, 5));
List<Integer> list = new ArrayList<>(Arrays.asList(1, 2, 3, 4, 5));

collection.remove(1);   // Result: [2, 3, 4, 5] - removes the VALUE 1
list.remove(1);         // Result: [1, 3, 4, 5] - removes the element at INDEX 1

Yes, the culprit is due to method overloading. See here:

// From Collection interface
boolean remove(Object o);

// From List interface  
E remove(int index);

By the rule of method overloading, primitive types trump over Object ones, so for the List instance, the overloading version of remove(int) is used, leading to this weird case.

The fix? Use one of those:

// Remove the first occurrence of element `1`
list.remove(Integer.valueOf(1)); // Yes, why would you?

// Remove all element `1` in this list
// This is for JDK 8+ only
list.removeIf(e -> Objects.equals(1, e));

Still, Java please, can we not have a removeAt(int index) method, belongs to List interface?

The Hostility Between Primitive Types Versus Generics

Have a look

var ints = new int[] {1, 2, 3, 4, 5, 6};

var list = Arrays.asList(ints);

What do you think the data type of list would be?

Is it List<Integer>?

Nope. It is List<int[]>.

Ah yes, how dare the primitive types throw a hissing fit here. How dare they!

So we have:

An int[] is an Object, but int[] is NOT Integer[], sorry, no autoboxing here.
On the same vein, an Integer[] is indeed an Object[], which in turn, an Object 🤡 Yes, what do you even expect?

So yes, this is also a thing:

void doSomethingObj(Integer... a) {
  // Do something
}

void doSomethingInt(int... a) {
  // Do something
}

doSomethingObj(new int[] {1, 2}); // Not complile
doSomethingInt(new Integer[] {1, 2}); // Also not compile

You can't have everything, I guess. Primitive types have harbored an intense hatred to everything object it seems.

The Great Profileration of `UnsupportedOperationException`

That nasty exception is everywhere in Collections API. Yes, it is there to ensure the immutability of the collections. And also yes, it meant stepping out from comfort zone of ArrayList, HashSet and HashMap means walking into an uncharted territory, where every step is a potential trigger to detonate the land mines (except the mines here are the presence of said exception).

The convenience of List.of, Set.of and Map.of? Those things throw UnsupportedOperationException when you try to mutate them. Again, why would you, but there are cases when you genuinely need to mutate your collections.

Do your collections accept null? Some do, others would ruin your day, for example, thread-safe collection like ConcurrentHashMap, or some specialized collections like TreeSet do not tolerate null. Again, working with null is generally frowned upon, but again, there will always be null in data, just like there will always be shadow accompanying someone under a sunny day.

Test your code carefully!

Speaking of `UnsupportedOperationException`

Take a look at this code:

var array = new Integer[] {1, 2, 3, 4, 5};
var list = Arrays.asList(array);
list.add(6); // Nope, UnsupportedOperationException
list.remove(1); // Also nope, UnsupportedOperationException
list.set(0, -1); // This is okay

So we have some sort of half-hearted immutable collection. Technically, Arrays.asList creates a view over a backing array. The original array cannot shrink or expand, so add and remove are not supported. However, modification is accepted.

But then, you run this code:

// Welcome to JDK 25, folks!
IO.println(Arrays.toString(array));

// Prints -1, 2, 3, 4, 5

The change you made to the list now reflects back to the backing array. The nature of a view, isn't it?

To truly ensure the complete immutability, use List.of in JDK 9+, or Collections.unmodifiableList.

Let me know if you have any other gotcha you wish to share, or an experience when you are the victim of above heresies 😂

Is String truly immutable? Believe me, I am not engaging in clickbait.

Linh Nguyen — Fri, 14 Nov 2025 02:23:06 +0000

Linh Nguyen

Nov 13 '25

Is String Truly Immutable?

#java

Comments

4 min read

Is String Truly Immutable?

Linh Nguyen — Thu, 13 Nov 2025 07:27:23 +0000

Okay, the title might or might not be clickbait. The original article is here, you can check it for yourself.

Or if you don't want to, you can view this short by Jose Paumard:

TL;DR

Here is your poison:

String is technically mutable, but effectively immutable

Long Answer (Sorry Jose, Let Me Steal Your Catchphrase)

Examining the String class, we will immediately see these fields:

private final byte[] value; // Actual holder of String value
private final byte coder; // either LATIN (0) or UTF16 (1)

private int hash;
private boolean hashIsZero;

If you still use JDK 8 and below (why would you?), you will see this instead:

private final char[] value;

private int hash;

Do you see something?

The Mutability Gotcha

Yes, you saw that right, there are rebellious non-immutable fields in the String class.

And by most definitions of an immutable class (being a final class and all of its fields must be final), this makes String not qualified to be one. The most technical representations of an immutable class in Java include Optional, LocalDate, UUID, and all Java Records.

Note: The finality here is shallow, not deep, but we don't talk about that here.

Another problem here is the backing array. Sure, it is final, but you know that even though the reference to said array is final, nothing really prevents the elements in said array from being changed. You know, the simple assignment?

char[] chars = new char[5];

chars[0] = 'H';
chars[1] = 'e';
chars[2] = 'l';
chars[3] = 'l';
chars[4] = 'o';

// Nothing prevents you from doing this
chars[0] = 'h';

That's why the method .toCharArray() needs a defensive copy instead of returning the array that backs the string directly.

There is a JEP Proposal to make truly frozen arrays, but it is still in draft stage, and there are no words about its prospect of ever making it into production JDK.

No Valhalla for You!

For this reason, as explained by Jose Paumard, String cannot be made into a value class (a class that lacks identity), because a value class requires all of its fields to be final, shallowly or not.

Why?

Short Answer

Performance, by using lazy evaluation on the hash value of the String and storing it for future uses.

Long Answer

String uses the hash (and hashIsZero if you use JDK 9+) field to store the computed hash value.

The calculation of a String object's hash can be very expensive if the string is long (like a blog post, an HTML page, or your feelings for your crush, j/k), and the hash code is only used in some hash-based use cases (like putting one into a HashMap).

It is due to this reason that Java makers decided to lazily evaluate the hash code of a String and store this value for future uses.

You can check the String class source code and see the implementation of its hashCode() method:

public int hashCode() {
  int h = this.hash;

  if (h == 0 && !this.hashIsZero) {
    h = isLatin1()
      ? StringLatin1.hashCode(value)
      : StringUTF16.hashCode(value);

    if (h == 0) {
      this.hashIsZero = true;
    } else {
      this.hash = h;
    }
  }

  return h;
}

However, the String is still effectively immutable due to its design:

The internal array does not get exposed to the outside due to defensive copying.
The hash and hashIsZero value initialization only happens once (the exception is zero hash value, I am not sure why), and they will never change after that because there are no public ways to mutate those values. This mutation is completely invisible to outside observers.

It is also worth mentioning that String is subjected to a lot of internal optimization, for example, the @Stable annotation on its value field, and more recently, on its hash field in JDK 25, allowing some optimizations by the JVM, like constant folding (detailed article is here).

Final Notes

No, String is not technically immutable in the truest sense.

But yes, String is still effectively immutable. You can only read its final fields, and you cannot do anything to its non-final ones (Reflection API can do something about it, but don't, just... don't).

String embodies the exact definition of a value class, but unless its internal design is changed (like frozen arrays and stable value JEPs), the journey to Valhalla will not permit an entry for our beloved String class. We'll see how the future will unfold, with a lot of effort putting into making integrity in Java a high priority (layman's term: what cannot be change will not be changed).

For the Love of God, Please Use Java Records!

Linh Nguyen — Fri, 07 Nov 2025 07:47:28 +0000

Remember when creating a simple data class in Java felt like doing some sorts of heavy labor? A handful of fields, 100 lines of code (well, not 100 lines, but is pretty close), and the existential dread of knowing you'd have to do it all again, even with the help of IDE? Yeah, Java 16 finally said "our bad" and gave us Records.

If you're still writing POJOs like it's 2010, buddy, we are not the same.

Why Records Are Like Finding $20 in Your Old Jeans

A real life use case: You want to store a name, age, and email. In the old days, you'd write a class, add fields, generate getters, generate setters (even though you don't want them), generate equals(), generate hashCode(), generate toString(), and then realize you forgot to update equals() after adding a new field. The reviewers told you to update. You hate yourself.

Now? You write this:

public record Person(String name, int age, String email) {}

That's it. You're done. Enough said!

Here's what you get for free (and I mean actually free, not "free trial for 30 days" free, without any credit card tomfoolery):

Auto-generated equals(), hashCode(), and toString() that actually work
Getters named like normal people talk: person.name() instead of person.getName() (because JavaBeans Specification, why not?)
Everything's final by default (no surprise mutations at 3 AM)
Can't be extended (no inheritance drama)
Still lets you implement interfaces (because interfaces are the true power behind Java's OOP)

One line. That's all it takes.

The Immutability Situation

So here's the deal, or a gotcha: Records make your references final. Think of it like a GPS coordinate: the location is fixed, but someone can still vandalize the building at that address.

record TreasureChest(List<String> gems) {}

var chest = new TreasureChest(new ArrayList<>(Arrays.asList("ruby")));
chest.gems().add("CURSED_GEM"); // Plot twist: nothing stops you

The field references are locked down, but if you put a mutable collection in there? That collection is doing whatever it wants. It's giving "I didn't hear no bell" energy.

The usual suspects:

Collections - Lists, Sets, Maps that laugh at your immutability dreams
Arrays - These will betray you every single time
Any object with setters - Self-explanatory chaos

Your JVM is trying to do optimizations, but you keep handing it mutable state like "surprise, guess again!" The JIT compiler wants to inline constants and fold operations, but can't if it thinks your data might mutate. It's like trying to take a family photo when someone won't stop moving.

The fix? Just embrace immutability from the start. Making everything immutable is the easiest way to achieve thread safety in our chaotic world.

Where to Use Records

Use Records for:

DTOs that just shuttle data around
API requests/responses
Value objects (coordinates, money amounts, that kind of thing)
Configuration classes in Spring Boot. Seriously, it's beautiful:

@ConfigurationProperties(prefix = "app.features")
public record FeatureFlags(boolean darkMode, boolean betaAccess) {}

// Wire it up in your main class
@SpringBootApplication
@EnableConfigurationProperties(FeatureFlags.class)
public class Application { }

Spring Boot 2.2 introduced this (needed @ConstructorBinding), then 2.6 was like "nah, we're good" and made it automatic.

TL;DR: Anything that Records can do, except for the cases like below.

DO NOT use Records for:

JPA entities - They need no-arg constructors, mutable fields, and proxying via inheritance. Records have none of those, so yeah, they mix and match like water and oil.
- However, since Hibernate 6.2, you can use Records as composite IDs for your JPA entities. It's not much, but it's honest work. Records work great for JPA Projections too.
Mutable stuff - If you really need to mutate states, then Records cannot help you. You can, however, use "withers".
Custom exceptions - Records can't extend anything except java.lang.Record. And if you're using exceptions as data carriers, we have bigger problems to discuss. Why do you ask a programmer to fix the network issues? Why would you do that?

Oh, and Records are immune to those gnarly deserialization attacks by design, as everyone has to bow to its almighty canonical constructor (read: an all-args constructor). One less CVE to lose sleep over.

Data-Oriented Programming

Records aren't just "Ctrl+C, Ctrl+V prevention technology" (though they absolutely are). They're part of Java's whole vibe shift toward data-oriented programming. Combined with pattern matching, sealed classes, and switch expressions that don't make you want to cry, Records let you model your domain with immutable data and transformations.

It's like "here's some data, here's what we do with it without any ceremonies or red tapes." Honestly? It's kind of refreshing. Like finding out you can just... not have daily standup meetings.

Breaking Up With Lombok

If you've been using Lombok annotations like they're going out of style (they are), I have news. Most of them and Records go together like oil and water, or recruiters and accurate job descriptions (because why did they want someone to do the job of a whole IT department with intern salary? A.I are no excuses, you pathetic human scums!).

Most of Lombok's annotations will not work with records. You will get compiler errors or face other problems.

BUT two Lombok annotations still work:

@Builder - Because builder patterns are genuinely useful
@With - For those wither methods (and the JVM might optimize away the temporary objects, which is neat)

@Builder
@With
public record Person(String name, int age) {}

var alice = Person.builder().name("Alice").age(30).build();
var olderAlice = alice.withAge(31); // New instance, old one untouched

@Builder helps creating an record instance easier, especially if your records have a lot of fields, and @With allows you to do some thread-safe data transformation (and pray that JVM will back you up with optimizations).

If you're stuck on Java 8 or 11, Lombok's @Value can help with immutable classes. But it's like using a flip phone in 2025: it's technically functional with limited supports, but everyone will be giving you looks (even Japanese started replacing their old "stupid" phones with more modern ones now).

Upgrade Already

Real talk: If you're still on Java 8 or 11, you're not just missing Records. You're missing pattern matching, better garbage collectors, text blocks, sealed classes, and security patches that don't require a time machine.

You're basically that person still using Windows XP because "it works fine" (spoiler alert: You will immediately be bamboozled the moment you boot up a Windows XP machine with active internet connection). Until it doesn't, and suddenly you're scrambling to fix the CVEs like trying to hold an overflowing dam with duct tapes and harsh language.

Java 17+ isn't just nice to have. It's "do you enjoy your infrastructure being held together with duct tape and prayers?" levels of necessary. It's also a new norm, so embrace it!

Most frameworks and libraries are already moving on. It is time for you, too! No excuses!

TL;DR

Records are Java admitting that sometimes you just need a dang data container, and 100 lines of boilerplate is ridiculous. They cut the nonsense, play nice with modern Java features, and work with every major framework.

The age of hand-crafted artisanal POJOs is over. And honestly? Nobody's mourning it.

Welcome to a future with less boilerplate and more time for problems that actually matter. Like arguing about tabs vs. spaces. (It's spaces, fight me.)

Create a Smaller Docker Image for Our Spring Boot Application

Linh Nguyen — Thu, 06 Nov 2025 08:40:29 +0000

The original article is hosted on my website here, so for my first article, I'll keep it short, with step-by-step explanation.

TL;DR

You can check the sample repository, or here is the full Dockerfile:

FROM amazoncorretto:25-alpine-full AS build

WORKDIR /usr/src/project

ENV JAVA_VERSION=25
ENV APP_NAME=app.jar
ENV DEPS_FILE=deps.info

COPY pom.xml mvnw ./
COPY .mvn/ .mvn/
RUN chmod +x mvnw

RUN ./mvnw dependency:go-offline

COPY src/ src/

RUN ./mvnw clean package -DskipTests

RUN jar xf target/${APP_NAME}

RUN jdeps  \
    --ignore-missing-deps  \
    -q --recursive  \
    --multi-release ${JAVA_VERSION} \
    --print-module-deps  \
    --class-path 'BOOT-INF/lib/*' \
    target/${APP_NAME} > ${DEPS_FILE}

RUN jlink \
    --add-modules $(cat ${DEPS_FILE}),jdk.crypto.ec \
    --strip-java-debug-attributes  \
    --compress 2  \
    --no-header-files  \
    --no-man-pages \
    --output /jre-minimalist

FROM alpine:3.22 AS final

ENV JAVA_HOME=/opt/java/jre-minimalist
ENV PATH=$JAVA_HOME/bin:$JAVA_HOME/lib:$PATH
ENV USER=springuser
ENV GROUP=springgroup
ENV WORKDIR=app
ENV APP_NAME=app.jar

COPY --from=build /jre-minimalist $JAVA_HOME

RUN addgroup -S ${GROUP} \
    && adduser -S ${USER} -G ${GROUP} \
    && mkdir -p /app \
    && chown -R ${USER}:${GROUP} /${WORKDIR}

COPY --from=build /usr/src/project/target/${APP_NAME} /${WORKDIR}/

WORKDIR /${WORKDIR}

USER ${USER}

ENTRYPOINT ["java", \
    "-XX:+UseCompactObjectHeaders", \
    "-XX:MaxRAMPercentage=75.0", \
    "-XX:InitialRAMPercentage=50.0", \
    "-XX:MaxMetaspaceSize=512m", \
    "-jar", \
    "app.jar"]

The Multi-stage Build

This line:

FROM amazoncorretto:25-alpine-full AS build

and this line:

FROM alpine:3.22 AS final

indicate that our build uses multiple stages. This is an effective strategy that helps with our build by, for example, caching multiple RUN commands during the build phase, and (most importantly) helping reduce the final image size.

The Maven Wrapper

You can see this part:

COPY pom.xml mvnw ./
COPY .mvn/ .mvn/
RUN chmod +x mvnw

Both the .mvn folder and mvnw file (and possibly mvnw.cmd if you're using Windows) are from the Maven wrapper, which often accompanies your project if it is created using Spring Initializr. We'll be using the Maven wrapper with no need to use a Maven Docker image for our build phase.

The Maven Build

The build stage:

RUN ./mvnw dependency:go-offline

COPY src/ src/

RUN ./mvnw clean package -DskipTests

This will help with caching: as long as there are no dependency changes, we can speed up subsequent builds with all dependencies downloaded and cached.

We'll be copying everything from the src folder and the pom.xml file (see above) and start our build. We can skip the tests by specifying -DskipTests (we can defer unit tests to feature branch builds).

The Custom JRE Image Creation

This part:

RUN jar xf target/${APP_NAME}

RUN jdeps  \
    --ignore-missing-deps  \
    -q --recursive  \
    --multi-release ${JAVA_VERSION} \
    --print-module-deps  \
    --class-path 'BOOT-INF/lib/*' \
    target/${APP_NAME} > ${DEPS_FILE}

RUN jlink \
    --add-modules $(cat ${DEPS_FILE}),jdk.crypto.ec \
    --strip-java-debug-attributes  \
    --compress 2  \
    --no-header-files  \
    --no-man-pages \
    --output /jre-minimalist

does the following:

Extract the fat JAR file (in this project, the built JAR file name is app.jar)
Use jdeps to detect the required modules needed to run our Spring Boot application container and export the found module list to a file, in this case, deps.info.
Finally, use jlink to create our own JRE image. Note that we also include jdk.crypto.ec here, because my sample project uses HTTPS, and without this module, we cannot make HTTP requests to the application running in the container.

The Final Touches

This part:

COPY --from=build /jre-minimalist $JAVA_HOME

means we are copying our custom JRE image from the build stage to our $JAVA_HOME folder.

The rest:

RUN addgroup -S ${GROUP} \
    && adduser -S ${USER} -G ${GROUP} \
    && mkdir -p /app \
    && chown -R ${USER}:${GROUP} /${WORKDIR}

COPY --from=build /usr/src/project/target/${APP_NAME} /${WORKDIR}/

WORKDIR /${WORKDIR}

USER ${USER}

ENTRYPOINT ["java", \
    "-XX:+UseCompactObjectHeaders", \
    "-XX:MaxRAMPercentage=75.0", \
    "-XX:InitialRAMPercentage=50.0", \
    "-XX:MaxMetaspaceSize=512m", \
    "-jar", \
    "app.jar"]

simply performs some (not so) trivial tasks: creating a non-root user, copying the fat JAR file, specifying some JVM arguments, and voilà, the image is ready to be built!

For a better explanation of the whole process, please visit this article and leave your comments. I'd be happy to hear from you!

Forem: Linh Nguyen

#Rant: Java Is Not Dead, It Is Not Cool, It Is Lukewarm, But It Is Far From Dead!

The Uncomfortable Truth

The Lukewarm Reality

Remember When They Said...

But Wait, There's More

Real World Examples

The Numbers Don't Lie

The Real Java

The Verdict

But What About...

Final Thoughts

[Boost]

Remember to Make Use Of Lazy Evaluation

Linh Nguyen ・ Nov 18

Remember to Make Use Of Lazy Evaluation

Our Simple Example of Null-Coalescing

When Reality Hits (Hard)

Is There a Fix?

No, No, No, Don't Press the Delete Button!

Java's Funny Little Heresies

When 1000 Is NOT Equal to 1000

The Great Type Erasure

Unsigned When?

String's Questionable Immutability

The Collection Shenanigans

The Hostility Between Primitive Types Versus Generics

The Great Profileration of UnsupportedOperationException

Speaking of UnsupportedOperationException

Is String truly immutable? Believe me, I am not engaging in clickbait.

Is String Truly Immutable?

Is String Truly Immutable?

TL;DR

Long Answer (Sorry Jose, Let Me Steal Your Catchphrase)

The Mutability Gotcha

No Valhalla for You!

Why?

Short Answer

Long Answer

Final Notes

For the Love of God, Please Use Java Records!

Why Records Are Like Finding $20 in Your Old Jeans

The Immutability Situation

Where to Use Records

Use Records for:

DO NOT use Records for:

Data-Oriented Programming

Breaking Up With Lombok

Upgrade Already

TL;DR

Create a Smaller Docker Image for Our Spring Boot Application

TL;DR

The Multi-stage Build

The Maven Wrapper

The Maven Build

The Custom JRE Image Creation

The Final Touches

The Great Profileration of `UnsupportedOperationException`

Speaking of `UnsupportedOperationException`