Java isn't dead yet, but it can't avoid Valhalla

Wed, 28 Oct 2026 19:00:00 +0100

Recently, somewhere on social media, I saw a code snippet. I guess the intention was to show how “Java is bad and dead”. I think it’s a good time to focus on some claims, falsehoods and half-truths that appeared in the comments, which I found pretty amusing. It also answers some of the criticisms raised in conference talks in autumn (checks the calendar) of 2026!

TL;DR: compact source files are already here, value objects from Valhalla are coming, you can keep your head in 2005, but be aware what year it is now.

The riddle

The snippet (I’m recreating it from memory) was something like this:

void main() {
 Integer a = 127,
 b = 127,
 c = 128,
 d = 128;
 IO.println(a == b);
 IO.println(c == d);
}

Of course, to prove the point, it was using System.out.println(). Since I no longer live in early 2000s, I allowed myself to go more modern, hence IO.println.

This might be one of the riddles that ~~pretending to be clever~~ Super Senior Software Engineers use to torment candidates ;-) So let me ask you two questions:

The questions

What Java version do I need to run this code?
What is the output of this code?

The versions

The answer to the first one is (if we count only GA features) 25. It was released over a year ago! With JEP-512 (and two preview JEPs before it), there’s really no need to keep your head in the past and keep saying, “oh, Java needs so much ceremony to start”.

Maybe you didn’t get the memo, or maybe you missed the Happy New Year 2026 party, but now you don’t need public static void main (String[] args) wrapped in a class. I mean, you still can, but that’s not mandatory, especially if you wish to teach people so they can take their first steps in Java. Or, as an experienced Software Engineer, you can use it for prototyping too!

What’s more, it comes with a bunch of handy overloaded IO.println() and IO.readln() methods, so writing to standard output and reading from standard input (think: keyboard) is not a tedious task. And sure, if IO. is too much of a headache for you, you can use a static import, but that makes things more obscure for newcomers to software engineering, so maybe we shouldn’t. Personally, I like this prefix because it clearly shows the intent and that IO is involved.

So, you can copy the code above, save it to a file, say riddle.java, and then run it with Java 25 or later:

java riddle.java

That’s really all that’s needed! You don’t need to javac it first! Seriously, it’s late 2026; no need to whine about your parents’ experience. The world moves on, Java moves on, maybe you should too?

The output

Some people will love the answer to the second question, because… “it depends”! ;-)

Wait, what do you mean it depends? Shouldn’t it always be the same?

And most of the time it is ;-) But before we answer this, allow me to detour via some explanations.

Yes, in Java you can’t override operators (which is allowed even in some other JVM languages).
Yes, the equality of objects is checked with the equals method (like it or not, it is what it is).
Yes, the == operator,
- in the case of objects, actually checks if we’re dealing with the same object, because it checks where the object is located in memory,
- in the case of primitive values, compares, well, their value.

Reminder: in Java primitive types are like int, long, double, boolean. Strings and Integers (which are [auto]boxed) are objects, not primitive types. Therefore, if you have Integer c = 128, d = 128; and later on you c == d, then you’re comparing the references, not the values stored in the [auto]boxed objects.

Here’s where things get a bit tricky

This is why c == d yields false: we created two different objects, like it or not. But Integer a = 127, b = 127; followed by a == b gives us… true. And yes, you kinda have to know this, because the Integers for values between -128 and 127 are pooled. So when you autobox them, you won’t get two different instances; both a and b point to the very same object. So the output of our riddle is:

true
false

It’s about to change

When? Most probably since March 2027, when Java 28 is going to be released. And even then, not for everyone, but only for folks eager to try preview features ;-)

As of today, Java 28 is expected to come with JEP 401, Value Objects (preview). It’s going to be the first Java version with Value Objects available (apart from previous custom builds). The very example we’re focusing on in this post, the Integer class, since Java 16, has been annotated with @ValueBased, and in Java 28 it is also a value, if you decide to go with preview features.

I’ll write more about value objects in Java, since right now, for us, the masses, they’re no longer beyond the horizon. For now, the short explanation is: if you add value to a class, the JVM won’t create a new object for this class as long as there is already an object of this class which holds exactly the same value(s).

In our example, when we run it using (an early build of) Java 28 with --enable-preview, Integer c = 128; creates a new instance. And Integer d = 128; doesn’t create a new one; instead, we get the same object which was created for c, hence c == d gives us true.

The reasoning behind this is quite straightforward, I’d say. 128 is 128. It doesn’t change. If it did, it’d be 127 or 129, and that’s a completely different number, so we don’t have to create a boxed 128 every time the user wants one; we can create it just once and (as long as it’s not garbage collected) keep returning the very same object representing 128. Even if it’s outside “the pooled range” of Integers.

So you can also answer the riddle with

true
true

if you specify you ran Java 28 with preview features enabled, as shown in the screenshot below.

Summary

Whenever you want to rant about Java, please make sure you rant about a recent / the latest version. Otherwise, it’s as if you pulled out an ancient map of the world and kept arguing the Earth is flat because the map says so. Guess what: it is round. (Even if just “round as a pancake”.)
Evaluating things, having an opinion, and sharing it in a polite way are key to progress in general, and Java’s progress in particular; so running preview features, using incubation modules, and sharing what you’ve learnt, did or didn’t like, is simply awesome.
void main() is a thing and it’s fine.
value objects are about to shake and (re-)shape how we think about processing and storing data in Java.

For more meta-rants like this, please hit Subscribe and the bell button :-P

Java 28 on SoftwareGarden.dev