[Java lista] final formalis parameter

[Laszlo.Marai at nokia.com]

  Hali!

>Egyrészt optimálisabb lesz (C esetén ilyenkor ha tudja, akkor 
>proci-regiszterbe teszi ehlyből, nem stack/heap whatever , 
>hogy java-nál hogy van azzal kapcsolatban majd tapasztaltabban 
>kisegítenek minket :))

Nem lesz optimalisabb. Valoszinuleg (en nem latom, hogy mitol
lenne az). De biztos, hogy altalanossagban nem lehet ilyen 
kijelenteseket tenni, mert ahany VM, annyi fele optimalizalas.

Meg aztan tok jelentektelen is, hogy hany ns ideig tart elerni
egy int parametert egy metodusban. Feltehetoleg csinal
valami ertelmes dolgot is, es akkor egeszen biztosan 
elhanyagolhato lesz a parameter kiolvasasanak az ideje.

>Thinking in Java idevonatkozó része: (jó, static-ról beszél, 
>na) :L) "static final variables can be optimized by the JVM to 
>improve program speed. Program constants should thus be 
>declared as static and final. "

Hat az a nem mindegy, hogy static az a final, vagy nem.
A static final, _ha primitiv tipusrol beszelunk_ es
forditasi idoben kiszamolhato az erteke, akkor gyakorlatilag
egy konstans kifejezes, amit a fordito az eleres helyere szepen
be tud helyettesiteni. Ha nem primitiv a tipus, vagy nem
derul ki az erteke forditasi idoben pl.: 
static final int SOMETHING = calculateSomething() ),
akkor ez az allitas mar nem lesz igaz, hiszen csak
furas kozben, az osztaly betoltodesekor kap erteket a valtozo.
(Viszont itt a JIT meg megteheti, hogy amikor elso alkalommal
eri el egy kodreszlet a kerdeses valtozot, akkor allandora 
behelyettesiti a static final erteket a hivas helyen.)

>Sokkal fontosabb hogy ha nem fog változni a metóduson belül 
>akkor azért (si) érdemes finalt-t elétenni (és itt jön be a 

Igy van. Sot, altalaban nem kivanatos, hogy a metodus parametere
valtozzon, mert megteveszto, es konnyu elnezni, ezert akar
mindenhova is ki lehetne irni a final-t. (Sot, olvastam olyan 
velemenyt is, hogy eleve hibat kene jeleznie a forditonak,
ha megprobalod modositani a metodus parameter erteket.)

Ez foleg konstrukltorokban illetve set metodusokban lehet
erdekes, ahol viszonylag gyankran szerepel a 
this.something = something; formaju ertekadas, es ha
elfeledkezik a this-rol az ember, akkor csak nez, hogy miert
nem inicializalodott az objektum something nevu mezoje.

Ha tudjuk, hogy az objektum eletciklusa folyaman nem fog
valtozni a valtozo erteke, akkor azt is erdemes final-re
venni:

Pl.

public class Clazz {
    private final int something;

    public Clazz( final something ) {
        // Mivel mindket something final, ezert barmilyen ettol
        // eltero ertekadasert hibat jelez a fordito.
        this.something = something;

        // Hibas (gyakori eliras):
        something = something;
      
       // Az is hiba, ha elfelejtesz erteket adni a this.something -nak!
    }
}

>(de a kék+zöld könyv is jó, csak abból ilyeneket nem fogsz 
>kiolvasni...) Persze mindig az a kérdés hogy mi a cél.

Az nem programozni tanit, csak egyszeruen a java nyelvet plusz
a classlib egy reszet :).

Ami meg lenyeges (az eredeti kerdezonek): mar a kerdesfelvetes is
hibas gondolkodast sugall. Ha az is lenne a valasz, hogy gyorsit
a final kiirasa, akkor sem lenne szabad csak emiatt hasznalni.
Legalabbis addig nem, amig el nem keszult a kerdeses programreszlet, es
ki nem merted, hogy valoban ez okozza a problemat. A legfontosabb az,
hogy a programod azt irja le pontosan (es jol erthetoen), ami a feladat,
es optimalizalni csak akkor szabad, ha van mit. Azt meg csak akkor
tudod, ha kimerted (erre a profiler nevu eszkozt hasznaljuk). A
java-val a VM es JIT miatt amugy is eleg nagy meglepetesek erhetik
az embert, eleg nehez a kod irogatasa kozben elore meghasalni, hogy
hol is kell majd (es foleg hogy) optimalizalni. (Ez mas nyelvekre is
igaz, csak itt a JIT meg a VM pluszban is bekavar.)

  Ba'ly,
    Atleta