@Korges: Albo wcześniej powiedział, że chodzi o optymalizację na poziomie kompilatora i wykonywania na JVM, albo p...bzdety.
Klasa finalna - to akurat naiwne podejście Java. Właściwie każda klasa powinna być final, chyba, że autor pisząc ją naprawdę przemyślał jej budowę pod kątem bezpiecznego przeciążania składników. Jeżeli masz jakąkolwiek logikę w metodach publicznych klasy, to właściwie z automatu dziedziczenie bezpieczne nie jest. Pochodną tego jest final na metodzie.
Pole klasy - wiadomo, że zostało zainicjalizowane przy tworzeniu obiektu, wiadomo, że ta wartość tam jest. To, że można je nadpisać jakąś magią nie ma znaczenia, jak używasz java.unsafe
to powinieneś się domyślić, że tam jest coś "unsafe". Jak piszesz w C++,. odwołasz się pointerem, przeskoczysz parę bajtów i coś nadpiszesz, to też powinieneś zdawać sobie sprawę, że robisz to na własne ryzyko.
Zmienna - ja staram się pisać. to final, bo później jasno widzę, że wartość nie została zmieniona, nie może zostać normalnie zmieniona, jak mi przyjdzie ją zmienić, to kompilator mnie ochrzani i będę mieć okazję się zastanowić. Jak ktoś inny będzie w tym kodzie grzebać, to też dostanie te same wskazówki.
Parametry - tutaj nie stosuję z lenistwa. Zakładam, że nie jestem dość szalony, żeby nadpisywać wartość parametru metody. Ale uważam też, że sam fakt, że parametry metody nie są final nienajlepiej świadczy o projektantach języka.
Gdyby OP, jak to było już napisane korzystał z bardziej współczesnego języka, to problemu by nie dostrzegł, bo np. zawsze trzeba wprost określić, czy zmienna/pole ma być final, czy nie, klasy są domyślnie final, parametry też. A w Javie wiadomo- gdyby chcieć zrobić normalnie, to połowa kodu zamieniłaby się w final
.