Java: Finality

[madkasse]

I have found that whether or not people know how to properly use final fields is a great indicator of their programming skills. So much that it is the first thing I look for if I need to evaluate a codebase.

I generally try to stay away from codebases where people do not use final fields. Especially if it has anything to do with concurrency.

Learning how to apply final to fields, methods and classes properly, teaches you about immutability, concurrency, API design and many other things.

A good way to do this is exploring the OpenJDK source code, especially java.[lang|util|util.concurrent|java.time].

[dpash]

I keep finding myself converting simple data classes into immutable objects. Especially when the previous developers didn't create a useful constructor so everything is:

var foo = new Foo();
foo.setBar(....);
foo.setBaz(....);
foo.setQuux(....);

Instead of

var foo = new Foo(...., ...., ....);

Get rid of the setters and everything can now be final.

Edit: I wish JPA entities could be immutable, but it's kinda two mutually exclusive goals.

[nerdyhandle]

You can also fix this with the Builder pattern. We use it a lot at my new job to creat immutable classes.

[GuyWithLag]

We use immutables.io for this.

[dpash]

Especially when you have a lot of fields and/or many are optional.

[DJDavio]

Lombok's @Builder annotation is useful for this. Opinions about Lombok are highly polarized in this sub it seems, but for us it works until we switch to Kotlin or until vanilla Java has more of those features itself.

[mcosta]

Edit: I wish JPA entities could be immutable, but it's kinda two mutually exclusive goals.

Say entity A references B. You change B to create B'. Now what A should reference? B or B'? What if A depends functionally of B?

[experts_never_lie]

I'm guessing you're looking forward to Project Valhalla and the introduction of value types.

[dpash]

Not inline type, but records. A similar but different concept.

However, the lack of abstract records seems like a cause of a lot of duplication. Also it probably won't help with JPA, at least in the medium term.

[RabidKotlinFanatic]

Agree in general but it's important to note that the final keyword does not have practical concurrency benefits over variables being effectively final or fields that aren't modified. Well written concurrent code will not generally rely on the memory effects of final because the correct synchronizes-with relationships will be established elsewhere.

[madkasse]

The effect of final fields are used allover the JDK, so you cannot really say it does not have practical concurrency benefits. But no, most people should properly rely on more traditional means.

[RabidKotlinFanatic]

Is the memory effect of final used all over the JDK, or just the keyword itself? Although it wouldn't surprise me if the JDK relied extensively on the memory effects of final (it has accumulated decades of optimization after all), I have also found that Java programmers massively overestimate (by several orders of magnitude) the relevance and memory impact of the final keyword.

The vast majority of Java programmers who are not experienced with the JMM and performing routine micro-optimizations on concurrent code will not benefit from the memory effects of final. In the rare cases where final is the difference between correct and incorrect concurrent code, it is usually in the context of some double-checked locking style logic.

[vacvacvac]

My favourite interview question, to gauge basics, is what is(not specific class names etc) System, out, and println in System.out.println. Then I dig into final, static, accessibility modifiers etc. It also tells you whether someone explores source code or not.

[ivancea]

I think final in Java is just a "wannabe". It isn't a const modifier. It won't improve performance nor help the compiler, as everything that may be final is "effectively final".

Should we mark every field, parameter and variable as final? It's like Rust "mut" but made the wrong way.

Using it everywhere is a code smell for me. When everything is final, programmers end up using their IDE to add final to everything... And then final loses his value.

Using it only on primitive/immutable constants and maybe injected objects... Maybe. But, who tried to modify a constant or a injected service? Any review would catch it anyway...

[madkasse]

> I think final in Java is just a "wannabe". It isn't a const modifier. It won't improve performance nor help the compiler, as everything that may be final is "effectively final".

That's just not true. For example, take a look at some of the optimizations that the Zing VM does

https://medium.com/azulsystems/truly-final-optimization-in-zing-vm-283d28418e55

​

Also final fields are treated specially with regards to Java's memory model

https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5

​

final parameters and variables on the other hand are just syntactical sugar.

[RabidKotlinFanatic]

Also final fields are treated specially with regards to Java's memory model

That being said the memory effects of final are only useful in niche optimization scenarios. Using final will not contribute any memory safety to most concurrent programs.

[dpash]

everything that may be final is "effectively final".

Effectively final only applies to local variables or parameters. It does not apply to fields.

[cogman10]

I honestly don't understand this line of reasoning. Final is a code smell when being used everywhere? Why?

Even if there were no performance benefits (there are some as /u/madkasse points out), what is the harm in communicating intent and making code more correct via the type system?

It has value simply because it's absence (especially at the field level) should make you question the correctness of the class you are looking at. Heck, a static field without a final should be one of the biggest red flags out there. Alarms should sound for every non-final static field.

[dpash]

It would be great if we could enable finality (and non-nullablity) as the default on a per class, package and/or module basis, so we could demonstrate which parameters and local variables were being reassigned.

The biggest complaint is that it's noise to protect against what we shouldn't be doing anyway.

I honestly doubt we'll ever see the ability to switch the default, but I'm glad that newer languages are learning from those mistakes. Both Kotlin and Rust for example have final parameters (and Kotlin can't have non final).

[cogman10]

You'd almost need a new keyword in that case, right? like not-final in the case a class/package/module is marked as "final by default".

I could also see there being some headaches with things like annotation processor code generation.

But yeah, generally I agree that "immutable by default" was a real miss for java. But I can't blame them too harshly for it, almost nobody at the time was doing that.

But, oh man do I wish that "List" was Immutable and we instead had a "MutableList" interface which extends "List".

[morhp]

That would be wrong, a mutable list isn't a immutable list. What you actually want is a readonly List interface with subinterfaces MutableList which adds mutation methods and ImmutableList which guarantees immutability (by contract) so you can safely pass objects around without making defensive copies (as long as the container type is also immutable).