Hozzászólások
-
Bejegyzés
-
így van!
elv ha meghívjük explicit módon (System.gc()) akkor összetakarít mindent, amit csak lehet:
SUN Java System.gc() referencia: „When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.”„best effort” 🙂 és az elõzõ mondatban is suggest van…
Hm. ezt nem is tudtam… mindenesetre eddig nem volt rá szükség, hogy a finalize-t explicit módon hívjam. Felmerül azonban a kérdés ekkor, hogy egy objektum belülrõl tudja-e törölni saját magát?
nem, de ez miért kellene??
Mert gondolom a this=null; nem fog menni… 🙂
a this final…
hát elv mi is a gyenge referencia? Ha jól tudom épp az a lényege, hogy azt a gc nem veszi figyelembe… de ez nem biztos, csak vmi rémlik…
ha valamire csak gyenge ref van és kell mem azt automatikusan felszabadítja a gc
1-2 észrevétel:
-a dispose nem szünteti meg az objektumot, csak a natív erõforrsáokat szabadítja fel
-a gc nem „köteles” csinálni semmit amíg van memóra
-a finalize hívása nem jelent semmit (vagyis az hajtódik végre amit a finalize metódusba írtál, de más nem történik != C destruktor!!! )
-a null -ra állítás akkor kell, ha referencia marad rá, de már nem használod (jó példa a stack tömbbel megvalósítása, ugye a stack pointer alatti(vagy fölötti) tömbelemek már nem használtak de a tömbben a ref megmarad amíg felül nem írod, itt jól jöhet a nullázás)esetleg (bár ebben az esetben nem látom konkrétan értelmét, de talán active_frame lehetne) weakrefernce használata
A win menü megszüntetéséhez pedig minden bizonnyal szerkeszteni kell a az elsõdlegesen win-en lévõ config.sys és autoexec.bat file-okat
[align=right][snapback]143816[/snapback][/align]ez xp esetén a c:boot.ini lesz
vagy my computer -> properties ->advanced->startup and recovery->settingsSziasztok!
Szeretnék egy Tomcat szervert jail shell-ben futtatni, azonban amennyire én tudom,
ehhez a java-t is ide kell installálni. Ez viszont csakis a /usr/java alá pakolja magát, akárhogyan is szeretném rábírni, hogy máshová tegye magát.
Valaki tudna esetleg segíteni?üdv
[align=right][snapback]143901[/snapback][/align]az /usr/java könyvátrat átmásolod oda ahova kell…
(Linux alatt egy korlát volt – a boot partíciónak 1024 alatt kellett lennie -, de ez kb akkortájt meg is szûnt, amikor a bios, már tudott 1024 felett butulni.)
[align=right][snapback]142593[/snapback][/align]csak a pontosság kedvéért (remélem az lesz) a lilo-nak volt ez a korlátja, és pontosan azért mert a bios hívásokat használta(ja???) a rendszer betöltéséhez
„
Hja, de a te módszerednél meg kell nézni, hogy egyetlen modul se legyen egy csomagban egyetlen másikkal sem. Nálam meg csak annyi kell, hogy az õsosztállyal ne legyen egyetlen modul se egy csomagban… 🙂 Azért ez jelentõsen kevesebb ellenõrzéssel jár.”ok
„Ok, rendben, ez csak rémlett vhogyan, vagy nemtom. :blush: De akkor mi a különbség a static és a nem static belsõ osztály között?”
hja 🙂 , az hogy a static osztály létezik önmagában nem kell hozzá enclosing class (próbálj meg példányt létrehozni az enclosing classon kívülrõl egy nem static inner classból aztán majd meglátod mi a különbség 🙂 )
„Jó, de a modul ugye hova mentsen? Minden modulnak külön konfigfájl?
„Hja, de ekkor csak annyi a dolga a kémmodulnak, hogy magát egy csomagba pakolja a haxolni kívánt modullal és akkor hozzáfér.”
jó, oké a belsõ osztály egy fokkal jobb, bár a serializált fájlt még így is bárki olvashatja és akkor az egész móka semmit nem ér :)))
„Bár ezt télleg jó lenne kideríteni, mert ugye a getModuledata()/putModuledata() is protected, és lehet, hogy ez a mizéria a csomagokkal ott is megvan…”
ugyanabból a csomagból bárki meghívhatja azokat a függvényeket
„Mondjuk ott elég lenne csak azt ellenõrizni, hogy ne kerülhessen modul az õsosztállyal egy csomagba, hiszen ezek a metódusok ott vannak.”
ezt nyugodtan megteheted (de az „én” módszeremnél is)
„Hát… most lehet, h én értelmeztem félre vmit, de nézz utána a „Kék Bibliában”. Ott ír vmi ilyesmit, hogy a belsõ osztályoknál ha static, akkor olyan, mintha mondjuk C++-ban friend belsõ osztály lenne, azonban a nem static belsõ osztály teljesen más. Nem-static belsõ osztálynál a burkolóosztály minden egyes példányához létrejön 1 db belsõ osztálybeli példány (auto) és ezek ugyancsak oanok, mintha c++os friend osztályok lennének.”
nem tudom c-ben mi a friend, de a javas része tévedés az biztos!
egyszer sem írja ki, hogy létrejött:
(nagyon helyesen, hiszen senki nem hozta létre a belsõ osztályt, automatikusan sem jött létre nyilván)Code:public class Access {private class B {
{
System.out.println(„létrejött”);
}
int pp = 1;
protected int pro = 2;
private int pri = 3;}
public Access() {
}public static void main(String args[])
{
Access a = new Access();
}
}„hogy is gondolod? Lenne egy függvény a modul-interfészben, ami kikéri minden modultól a maga kis mentendõ objektumát?
De akkor mi a garancia, h nem a kémmodul kéri ki azt?”az,hogy nem kikérné hanem mondaná a modulnak, hogy mentsél amit kell mert kilépés van
(persze csak tipp volt)„rossz is belegondolni, mi mindenre kéne figyelni.”
így is lehetne, bár ez megint a te általad javasolt eljárás kicsit másképp, de ilyenkor sem kellene a serializációval szórakozni elég pl egy vectort serializálni
„De így kényelmesebb, mert azzal, hogy modul is, meg van oldva az automatikus adat-karbantartás.
Mert ugye pl. addContact absztrakt metódusnál õ elmenti a partnert. vagy addServer metódusnál elmenti a szerver objektumát, amit a metódussal kapott, etc.
Ugyanez fordítva is: removeServer/removeAccount/etc-nél törli a tárolt objektumát.
„
ha jól értem ezek az eirc modul adatai, azok hogy jönnek most ide (mármint nyilván azzal is foglalkozni kell, de nem ott ahol a többi modul menti az adatait)? vagy én nem látok valamit…..„Nos, igen, a hashCode()/etc is jó lehetett volna nekem e helyett az objectID-s rendszer helyett, de az objectID már korábban megvolt nekem, más célokra is használom a progiban, így egyszerûbbnek tûnt picit bebiztosítani (pl. gondoskodni róla, h ne lehessen klónozni/etc) és ezt használni ide is.”
de akkor ez az egész nem kellett volna… (persze lehet úgy is használni, hogy az ID helyett a hasht használod de az lényegében tényleg ugyanez)
kl223,2005. Jul. 18. – 11:18 wrote:„Najó, de épp az lenne a lényeg, hogy a modul ne saját magát pakolja be, hanem egy pici objektumot, ami tárolja minden adatát. Mivel egyetlen objektumot lehet bepakolni, ezért nyilván ha többmindent is akar a modul tárolni, akkor új osztályt kell erre a célra létrehoznia.”eddig én is így gondoltam
„Ha nem belsõ, akkor nem fog hozzáférni a private tagokhoz… 🙂 Ha meg írok neki vmi kikérõ fgv-t, akkor a kémmodul is kikérheti.”
igaz nem fogalmaztam elég érthetõen
ilyesmire gondoltam:
Code:package testa;public class Access {
public Access()
{
B b = new B();
b.pp = 0;
b.pro = 0;
}
}class B {
int pp = 1;
protected int pro =2;
private int pri = 3;}
itt nyilván nem lehet elérni B -t
Code:package testB;import testa.B;
public class Accesso {public Accesso()
{
B b = new B();
b.pp = 0;
b.pro = 0;
}
}„Ha pedig nem static, akkor egyetlen olyan objektum létezhet, és olyat még nem használtam… 🙂
(mert ugye ha a belsõ osztály static, akkor bármennyit létrehozhatok belõle, hozzáfér a szülõosztály az õ private tagjaihoz/etc, ha meg nem static, akkor egyetlen, a szülõvel speciális kapcsolatban lévõ belsõ objektum jön létre a belsõ osztályból)”ez most nem igazán értem…..
ha nem static akkor miért ne hozhatnál létre belõle többet??továbbra sem vagyok megyõzve, hogy ide nem kell (fõleg,hogy nem lehet) interface
ugyanis itt keverednek kicsit a dolgok, a modulnak kellene egy interface amiben a modul által megvalósítandó dolgoknak kell kerülnie, tehát ez a moduldata akármi akkor kerülne bele, ha a modulnak magának kéne errõl gondoskodnia (pl exit elõtt minden modulra meghívnád) ekkor nyilván nem lehet gond a „kémkedés” (vagyis nem ez a fajta)
ha nem így van, mint nálad is, akkor meg ez egy utiliti osztály igazából nem egy modul (nem kell impementálnia a modul interfacet) és van publikus metódusai amik tárolják az adatokat, és a modul „vigyáz” a saját adataira, ahogy itt éppen megbeszéljük, vagy te nyújtasz valami biztonsági mechanizmust (pl Object.getClass() vagyh Object.hashCode() felhasználásával)
„Naigen, de akkor maga a modul se férne hozzá a saját adataihoz, elvégre a private a modulnak is private! :blink:”
nade a „saját magában” declarált private az neki azért csak elérhetõ, nem? 😉
” Persze megoldás lehetne, ha a modul egy saját statikus belsõ osztályát pakolja be, mert ekkor lehetnek a tagok private-ok, a modul hozzájuk fér, és más nem. „
valahogy így, csak nem kell, hogy statikus legyen, meg az sem, hogy belsõ 🙂
„A modult az gátolja meg abban, hogy ezeket maga hívja meg, hogy az eirc_data-beli metódusoknak szükségük van a modul objectID objektumára, amit maga a modul (azaz a leszármazott osztály) nem lát, mivel annak az õsosztályban private módosítója volt!”
ezt nem láttam, ok
„Egy kémmodul ugyan megadhatja a stringben egy másik modul nevét, de a másik modul objectID objektumát már nem tudja megszerezni!”
errõl jut eszembe a modulok hozzájuthatnak más modulok nevéhez?? ha igen nem lehet ezt elkerülni (esetleg egyszerûbben?) és akkkor máris megoldódott a probléma
„Azaz minden indulásnál minden modul/etc új objectID objektumot kap.”
ahogy egy tanárom mondaná: Akkkkor eez így….. oké!
🙂„Hát kösz, hogy elolvastad eddig…. 🙂 nem gondoltam volna, h lesz olyan, akinek lesz türelme ehhez. Kíváncsi vok, hogy ehhez a posthoz volt-e még türelmed… 😆 „
volt, nope 🙂ja még az eredetihez annyit (elveszett az eredeti hozzászólásom), hogy az események megvalósítása miért nem a „standard” jól bevált módon megy? azaz regisztrálni kellene az eseményekre listener objektumokat és így elkerülhetõek lennének a nem implementált metódusok (és hivogatásuk)
legutóbbi hsz