I am all for languages like kotlin instead of Java as it is objectively speaking more ergonomic, more succinct and has more usefull fraturew. But this idea that we are missing out on something that whose purpose is to limit, is silly at best.
I will tell you magic trick that will blow your mind if you want your references to be immutable: don’t reassign them! There. Enjoy your super powers.
Honestly speaking, all these “final” in front of are useless. Why would you want to re-assign a symbol in the age of block scope. Don’t do it. There is really no reason to it. All the times I saw people o desses with prefixing declarations with final all over a codebase, was just a clear signal that theae people would otherwise re-aesign their references all over the place and aide effect them everywhere. Just don’t do it and everything will be much better. You don’t need those things you ask for.
This is why python is so popular. Its pragmatism. Many of functionality from java could be achieved in python but ultimately it boils down to: it is a gentlemen’s agreement in the end. Or: what exactly are you trying to accomplish?
Often the answer is “preventing someone to do something with the code in the future”.
I mean, Java already has a bunch of stuff that you need to do to pacify the compiler; it’s not like taking Scheme or Perl and introducing a strong static type system. Too, “just do better” is fine advice but not really actionable on any scale larger than a single dev – see, the entire history of software to this point. Compilers enforcing constraints means that there are certain assumptions about the shape of the world at system design and initial implementation time that are encoded in the program and automatically enforced. That’s a good thing, in my opinion.
Recently I had a discussion with my team about the usage of final keyword and the fact that it was widespreading in the sources and hurting readability for very little gain.
At first I found it was great to enforce immutability of a variable
or method paramater but when I started to see method signature like public void FirstType myMethod(@NonNull final AnotherType anotherType) {...} or method body with 3 lines of code but 2 final I was very annoyed because I was spending time reading keyword instead of reading the
important part of the code.
After thinking about it I don’t see big benefits of using final (except for instance field).
For final used for method parameter, what is the problem if I decide to reassign the reference ? The reference of the caller is not changed. For the case where the input parameter is returned it could have an impact but we don’t do this because we think it doesn’t help comprehension (return a copy or don’t mutate the object).
I think having immutable object is better than having a final mutable object.
This part is anecdotal: in our project, I never had a bug about a method parameter being reassigned. Even more, I never see someone doing it. Even if it happened, it would be catched in code review.
For final used for variable inside method/function it’s worst, I am the owner of the variable, it’s a function scope, if I want to reassign the variable, let’s do it.
I would love to have non-nullable for a variable reference or for the complete project (like in C#). Having to put @NonNull everywhere really increase verbosity.
For the generics and type erasure, yes it can be annoying (especially for method overload) but I think it’s part of the contract of Java prioritizing compatibility.
I am all for languages like kotlin instead of Java as it is objectively speaking more ergonomic, more succinct and has more usefull fraturew. But this idea that we are missing out on something that whose purpose is to limit, is silly at best.
I will tell you magic trick that will blow your mind if you want your references to be immutable: don’t reassign them! There. Enjoy your super powers.
Honestly speaking, all these “final” in front of are useless. Why would you want to re-assign a symbol in the age of block scope. Don’t do it. There is really no reason to it. All the times I saw people o desses with prefixing declarations with final all over a codebase, was just a clear signal that theae people would otherwise re-aesign their references all over the place and aide effect them everywhere. Just don’t do it and everything will be much better. You don’t need those things you ask for.
This is why python is so popular. Its pragmatism. Many of functionality from java could be achieved in python but ultimately it boils down to: it is a gentlemen’s agreement in the end. Or: what exactly are you trying to accomplish? Often the answer is “preventing someone to do something with the code in the future”.
Time has shown again and again that “just don’t do $BAD_THING” is far from pragmatic advice: it is in fact unrealistic.
We have these tools to help us for a reason. Otherwise, why are we doing typing at all? It’s all bytes.
Alternatively a linter can be used to enforce no re-assignments.
I mean, Java already has a bunch of stuff that you need to do to pacify the compiler; it’s not like taking Scheme or Perl and introducing a strong static type system. Too, “just do better” is fine advice but not really actionable on any scale larger than a single dev – see, the entire history of software to this point. Compilers enforcing constraints means that there are certain assumptions about the shape of the world at system design and initial implementation time that are encoded in the program and automatically enforced. That’s a good thing, in my opinion.
Recently I had a discussion with my team about the usage of
finalkeyword and the fact that it was widespreading in the sources and hurting readability for very little gain.At first I found it was great to enforce immutability of a variable or method paramater but when I started to see method signature like
public void FirstType myMethod(@NonNull final AnotherType anotherType) {...}or method body with 3 lines of code but 2finalI was very annoyed because I was spending time reading keyword instead of reading the important part of the code.After thinking about it I don’t see big benefits of using
final(except for instance field).For
finalused for method parameter, what is the problem if I decide to reassign the reference ? The reference of the caller is not changed. For the case where the input parameter is returned it could have an impact but we don’t do this because we think it doesn’t help comprehension (return a copy or don’t mutate the object). I think having immutable object is better than having a final mutable object. This part is anecdotal: in our project, I never had a bug about a method parameter being reassigned. Even more, I never see someone doing it. Even if it happened, it would be catched in code review.For
finalused for variable inside method/function it’s worst, I am the owner of the variable, it’s a function scope, if I want to reassign the variable, let’s do it.I would love to have non-nullable for a variable reference or for the complete project (like in C#). Having to put
@NonNulleverywhere really increase verbosity.For the generics and type erasure, yes it can be annoying (especially for method overload) but I think it’s part of the contract of Java prioritizing compatibility.