This is slightly random, but I couldn't help but "laugh in Java" when the very first feature shown, `Objects.requireNonNullElse`, is given with an example and text that states "This method helps streamline handling null values, removing the need for verbose null checks ." Except the version that uses `Objects.requireNonNullElse` is longer than the one that uses the ternary operator!

What is it with Java deciding "Why use 2 characters when 40 will do?" Is it to much to ask for a ?? or ?: operator?

Ah, but the ternary operator solution requires repeating the name of the variable twice. And obviously, since you're writing in Java, your variable name will be at least 50 characters long. Thus making `Objects.requireNonNullElse` shorter.

The null coalescing operator (??) works well for this

Exactly, which is why it's baffling that Java doesn't have it.

It's not only about the length of the method. Ternary operators may look simple enough, but they could lead to some subtle errors. For example, try to guess what's wrong with this code:

  List<String> trimAndAdd(List<String> input, String newItem) {
    List<String> result = new ArrayList<>(input.size() + newItem == null ? 0 : 1);
  ...

I'm surprised by how verbose some of these new APIs are, like:

    Objects.requireNonNullElse(str, "default")

or even worse, if you need the right-hand side to be evaluated lazily:

    Objects.requireNonNullElseGet(str, () -> "default")

while Javascript's null-coalescing operator allows writing this so much simpler:

    str ?? "default"

    str ?? getDefault()

(And not to mention the fact that the null-coalescing operator can also be used for conditional assignment, for which Java has no option at all!)

I thought this post might be a joke because it claimed that it was saving verbosity here! ?? is also the null coalescing operator in C#. Not only is it nice and short, but since it's an infix operator it chains in a much cleaner way than nesting static method calls.

I'm curious how often people upgrade their versions. What's your motivation for upgrading?

Personally I learned Java 7 when it was the latest, then stuck with it since. I'd prefer to continue on with the same thing, there's more depth than one person can learn anyway, than add more things.

These things look nice, but they're mainly add-on bits. The core language is still the same. Though streams are a bit more special.

IIRC we’ll be upgrading from 11 to 2x something in our project in the near-ish future. We are using spring / axon and (IIRC) there was some EOL coming up or at least some newer versions required newer Java. I might be wrong though, haven’t been in these discussions myself.

This is such a paltry list for 9 version steps. It does not include things like the module system which are the biggest pain points in my experience.

Honestly I would not recommend anybody migrate from 8 to 17 anyway. 8 to 11 or 8 to 21 are much better choices, depending on your appetite for migration pain.

I haven't worked with the module system myself so this is why I didn't include it, but what is the problem you faced before the module systems?

The main thing is it causes backwards compatibility problems.

For example where previously you could override a class by simply putting a different library ahead of the normal element in the classpath that resolves it, with modules, Java will respect the declared module dependencies. As another example, reflection is prevented from resolving things from other modules that are not exported, where previously reflection could resolve everything.

These things can be worked around and people will argue they are things you should not have relied on in the first place, but the reality is very many useful libraries did and very often the "fixed" version is only available with a new major version of the library. So you can quickly find that just moving to Java 9+ means upgrading your entire dependency tree.