U completely missed the point.
Eloszor is, maga a JDK is ad optimalizaciora javaslatot a sajat API leirasukban. Ez pedig azonnal leakeles, mert olyan informaciot arul el, ami az objektum belso dolga kene legyen. De mint tudjuk, a valosag es a szep elmelet kozott van kulonbseg, nyilvan ezen okbol szerepelnek az ilyen "tippek" a leirasokban.
"A felesleges GC futásokat és a memleak gyártó kódokat többnyire a C/C++ irányból érkező programozók ejtik"
Jo lenne ha nem nezned le a C++ programozokat, foleg hogy a JVM nagy resze C++ kod. Miutan ezen tulestunk, folytassuk ott, hogy mi volt a GC igerete (amit ma mar ritkan hangoztatnak), vagy neadjisten fogalmazzuk meg azt az intuitiv igenyt hogy mit szeretnenk hogy elerjunk vele. Ezutan nezzuk meg valojaban mit muvel es rogton latszodik egy hasadek, ami kizarolag a GC mukodesi mechanizmusabol fakad, ergo ujabb leakkel allunk szemben.
"Az érdekes egyébként az, hogy ha az ember nem tödődik azzal, hogy optimalizáljon memóriafoglalásra a Java nyelvi szintjén, akkor alig tud olyan helyzetet előállítani, ami memleak jelenséggel jár."
Fail. Boven eleg, ha a nyelvi szinten mar nem scope-ban levo objektumodra szarik nagy ivben a GC. Ha neked ezzel megis nyelvi szinten kell foglalkoznod (es kell), akkor az nagyon ciki. Eppen a Sun leirasai emlitenek nem egy ilyen esetet, melyek nem csak ugy nagy ritkan neha esetleg megeshetnek, hanem _mindig_ tudnod kell hogy vannak ilyen helyzetek es sosem lehetsz biztos benne hogy az eppen aktualis JVM verzional (neadjisten platformnal) eppen milyen jatekszabalyok vannak.
Pontosan az ilyen mantrak azok, ami miatt eredetileg hozzaszoltam.