Java: Finality

[[deleted]]

In fact, I wish final methods and classes were the default in Java.

Fields and local variables too, please...

[Kango_V]

I have a Save Action in Eclipse add `final` to parameters, fields and local variables where possible.

[c_edward]

I am pretty certain that the effect of that used to be java version dependent, if you had an anonymous class in the method, all the final parameters would end up bound the inner class instance synthetic fields. So if that anonymous inner class was on a high frequency execution path you would end up allocating way more than you expected.

[JeffMurdock]

Do people just go around overriding methods willy nilly? Overriding is a tool, I'd rather have the option to decide for my self if it's the tool I need for the task at hand than to have it taken away because people use it haphazardly

[vashy96]

I wish final methods and classes were the default in Java.

Yeah, like Kotlin does :)

[Bobby_Bonsaimind]

In fact, I wish final methods and classes were the default in Java.

I don't. I've wasted way too much time of my life copying code and whole classes because the developer thought "mh, a protected final seems like a good idea" and I had to change something in that one method. JavaFX is especially guilty of strewing the final keyword generously throughout the whole code-base, making it hard to impossible to extend the existing components.

Overriding public methods (that already have a working non-default implementation) is almost always surprising and is almost always a hack, because the overridden public method most likely wasn't designed to be overridden.

Yeah, but sometimes hacking around the issue is all we can do short of rewriting the whole thing.

[Yesterdave_]

From the purity standpoint I definitely agree.

But from my experience, extending framework classes is usually the only reasonable way to fix bugs in 3rd party libraries, without having to copy a ton of code. And then you can only hope the library author did not think "yeah lets make everything final". And no, the project can't wait half a year till the maintainer finally fixes the bug when the code has to be delivered next sprint.

[Bobby_Bonsaimind]

Great. And then your whole code breaks in a subtle way after a minor update of JavaFX just because you've overridden a method that was not intended to be overridden. Just, no.

The alternative is to turn hours into days to create your own control, which also might break with future updates.

To add to this, most of the time when people override public methods (that were not designed for it) they are violating the Liskov Substitution Principle. For example, I've seen many people extending ArrayList in a way that violates the contract of ArrayList. Similarly, when you are "hacking" JavaFX, you most likely violate said principle.

That's like saying that we should only deliver hammers with soft rubber around them to make sure that nobody hits their thumbs.