Java alapok
2015-03-12T18:12:46+01:00
2015-03-18T17:56:13+01:00
2022-07-22T11:06:20+02:00
  • A telefon elsődleges funkciója a játék és élmény nyújtása. Animációkkal stb...

    Tévedsz. Ez utóbbi a játékkonzolokra igaz.
    Mutasd a teljes hozzászólást!
  • A tudatos mérnöki tervezésről meg csak annyit, hogy amikor az Android a java mellett döntött elvileg az is tudatos mérnöki tervezés volt. Csak hát az nem biztos, hogy helyes is.

    Na most. Te vagy a tervezők és döntéshozók egyike. Tudod, hogy most egy telefonos platform létrehozása a cél, ahol boldog-boldogtalan írkálhatja a programjait. Milyen platformot választasz? Kézi memóriakezelést, ahol háromból kettő szoftverben tuti lesz majd memleak, mert mindenféle félamatőr és amatőr emberek fognak fejleszteni, vagy esetleg a gc mellett teszed le a voksod, hogy legalább a memóriakezelési problémákat ne tudják elkövetni a jövőbeli dilettáns fejlesztők? Aztán ha ezt eldöntötted, akkor jön a következő döntési pont. Magas piaci jelenlétet akarva mely nyelvet választod? Egy Java-t, amit egyébként viszonylag primkó (mondjuk a C#-hoz és a Scalahoz képest), ráadásul nem kell oktatási anyagot készítened pluszban, meg nagyon sokan ismerik, vagy elkezdesz inkább kitalálni egy sajátot, hátha a konkurrencia választja azt, amit te nem és ezért majd azt használja a több ember?
    Mutasd a teljes hozzászólást!
  • Ott a pont: az erős grafikájú/cpu igényű játékok meg nem java-ban íródnak.
    Mivel a java alkalmatlan erre a feladatra és PONT :)
    Mutasd a teljes hozzászólást!
  • A telefon elsődleges funkciója a játék és élmény nyújtása. Animációkkal stb...

    A legtöbben facebookozásra, chatelésre használják, és ott bizony sok a holtidő.

    De ha már játék, telefonon nem a legjobb grafikájú játékok a legnépszerűbbek is egyben. Az erős grafikájú játékok meg nem Java-ban íródnak.

    És akkor még nem beszéltünk azokról a háttér folyamatokról (GPS navigáció, telefon készenlét, szinkronizáció stb...stb...) ami szintén állandóan a procit nyaggatja.

    Ezek meg mondjuk jelentenek max. 20% terhelést egy gyengébb telefonnál is, így ezek mellett mehet a GC.
    Mutasd a teljes hozzászólást!
  • Nem tudom honnan találjátok ki ezeket a ..hhhmmm....
    A telefon elsődleges funkciója a játék és élmény nyújtása. Animációkkal stb...
    Innentől kezdve mindig max-ra van hajtva, ha a felhasználó csinál vele valamit, mert egyre magasabb az ingerküszöb. Vagyis nem, hogy holtidő nincs ilyenkor, de örülhetsz, ha nem szaggat az ami éppen az előtérben fut.
    És akkor még nem beszéltünk azokról a háttér folyamatokról (GPS navigáció, telefon készenlét, szinkronizáció stb...stb...) ami szintén állandóan a procit nyaggatja.

    Szóval maradjunk annyiban, hogy az okostelefonok-tableteknél még mindig a 100% is kevés állapotok uralkodnak.
    De ahogy mondtam: Jó a java csak nem kellett volna annyi mindenre ráerőltetni (pl játékok android-ra) el kell fogadni, hogy van amit java-ban nem lehet szépen megcsinálni csak trükkökkel.

    Még jó, hogy az AVR-eket nem Java-ban kell programozni :D
    Mutasd a teljes hozzászólást!
  • Ahol user interface van, ott általában még több a holtidő, így telefonnál, asztali PC-nél is, hiszen a user interakcióban a user a szűk keresztmetszet. Ez alól csak a hardver igényes háttérfolyamatok a kivételek.
    Mutasd a teljes hozzászólást!
  • Csak az a baj, hogy a markolót nem én kértem a kertbe és az ásót meg elvitték.
    (Lásd Android-Java)
    Mutasd a teljes hozzászólást!
  • Igaz!
    Lehet, hogy ez hülyeség, de én úgy gondoltam, hogy megfelelő biztonság mellett.
    Ehhez valóban kevés a tudásom, hogy meg lehet-e oldani, pl úgy, hogy bizonyos osztályoknál engedélyezik másoknál pedig nem.
    Mint pl az osztályoknál a public,private, protected stb...

    Vagyis kis túlzással kikényszeríthetné az ember egy bizonyos metóduson belül, hogy a GC igenis most és azonnal szabadítsa fel ezeket a cuccokat.
    Ha van ilyen és valóban működik akkor viszont minden ezzel kapcsolatos hozzászólásom sztornó :D
    Mutasd a teljes hozzászólást!
  • Nem markolóval kell kertet ásni és nem ásóval toronyházat építeni.

    Pont ezt csinálod...
    Mutasd a teljes hozzászólást!
  • Engem ami kicsit bosszant, hogy ezt szerintem könnyen ki lehetne védeni azzal, ha én is megszüntethetnék objektumokat, de igazad van nem látom át, hogy ezt miért nem lehet megtenni.


    Melyik rész nem volt világos abból a két hozzászólásomból (2015.03.16. 20:55 és 2015.03.16. 22:14), amiben kifejtettem, hogy miért nem lehet a GC mellé rakni kézi memóriakezelést? A másodikra még úgy is reagáltál, mintha értenéd és egyetértenél vele
    Mutasd a teljes hozzászólást!
  • Nem gondolom magamat okosabbnak senkinél hiszen az "okos" csak egy szó.
    Egyszerűen a Java ne hozza azokat az előnyöket amikre olyan marha büszke.
    Mindennek van egy ára és van egy "hozama", ha az ár magasabb, mint a hozam akkor nem éri meg.
    A java is ilyen: van amiben busásan megéri, de van ahol tiszta ráfizetés.

    Hiába tudsz profin átdobálni egy kulcslyukon egy zsák zöldborsót, ha erre éppen nincs szükség (lásd Mátyás király meséi).
    Szóval a GC jó, de nem mindenre és van ahol pedig kifejezetten káros a jelenléte.
    Következésképpen van olyan területe az informatikának amit java-ban lehetetlen megoldani elfogadható szinten.
    Na ez az amit nem akarnak beismerni a java funok és a "mélyen tisztelt" Java készítő mérnökök :D
    Engem ami kicsit bosszant, hogy ezt szerintem könnyen ki lehetne védeni azzal, ha én is megszüntethetnék objektumokat, de igazad van nem látom át, hogy ezt miért nem lehet megtenni.
    Mutasd a teljes hozzászólást!
  • "A több száz mérnök informatikus" ellenére a windows is lefagy :)
    A magas fizetések és a beletett munkaóra nem garancia a sikerre és a minőségi munkára.

    Adott egy termék ami nem látja el a feladatát akkor egyszerűen nem jó és kész. Tök mindegy ki dolgozott vele és mennyit->Kuka.
    A Javának is van helye az informatikában van ahol nem is mernék mással nekiállni.
    Sőt: éppen a napokban készítettem egy kis 5 perces projectet és veregettem vállon a Java-t, hogy megspórolt nekem kb 1-2 órát. 
    Csak a legtöbben nem nagyon akarják beismerni, hogy a java lehetőségei korlátoltak és éppen ezek miatt a GC és társai miatt. És pontosan ezek adják meg azt a pluszt ami miatt más területen meg verhetetlen.
    Mutasd a teljes hozzászólást!
  • Ez a Fortranos példa jó :)

    Pénzből élünk és, mint tudjuk az idő pénz.
    A Java bonyolult és teljesen felesleges dolgok megtanulását várja el arra a feladatra amit jóval egyszerűbben meg lehet oldani.
    Teszi ezt azért, mert nem képesek felfogni, hogy pl játék fejlesztésre nem ez a legjobb, de azért beleerőszakolják oda is.

    Nem markolóval kell kertet ásni és nem ásóval toronyházat építeni.
    Ezt nem képesek sokan felfogni.

    Vagyis az egész vita, ha emlékszel onnan jött, hogy a GC egy jó dolog bizonyos helyzetekben, de nem mindenható.
    A Java filozófiája viszont az, hogy a GC mindenek felett ÉS a Java minden eszközhöz tökéletes.
    Ez utóbbi mondat az ami pl nálam kiveri a biztosítékot és ezt próbáltam valahogy elmagyarázni.
    Mutasd a teljes hozzászólást!
  • Nem hoztam fel, hogy ki honnan szarmazik. Nekem mindegy. Van normalis indiai kollegam es van nem normalis is. mar boven tul vagyok, hogy eloiteletem legyen. 
    Mindamellett vannak tapasztalatok, hogy kikre mi jellemzobb.
    Mutasd a teljes hozzászólást!
  • Az altalad leirt jelensegnek van egy szakszeru megfogalmazasa is.
    Mutasd a teljes hozzászólást!
  • Dolgozz indiaival es megtudod :)

    Igaz, hogy távolról, de kb 4 hónapja indiai főnököm van, eddig az akcentusán kívül nem vettem észre sok extra különlegességet.

    De van 20%, aki nem.

    És aki a magyar mentalitást emlegeti a magyar fórumokon, akkor ő ebbe a 20%-os magyar elitbe tartozik, igaz? (tehát ő "jobb" annál, aki ellen éppen vitázik, mert túllépet a magyarságán, és ezért neki van igaza...)

    Mondok peldat: azok a nemetek, akikkel egyutt dolgoztam, azok precizek, korrektek, de ennyi, nem azon dolgoznak, hogy lehet jobb, hanem megcsinaljak amit kell.

    Akikkel idáig együtt dolgoztam (99%-ban magyarok), azoknak a 80%-a ilyen. Akkor eddig szinte csak kivételekkel dolgoztam együtt? 

    Szerintem egyszerűen primitívség a saját igazunkat igaznak láttatni egy vitában a másik származása alapján, főleg, ha az illető ugyanonnan származik...
    Mutasd a teljes hozzászólást!
  • Egyszerűen megkerültem a GC-t és a sok h*lye beépített osztályt és amit kellett megírtam magamnak.

    Fortran programozó bármilyen nyelven tud Fortran programot írni.

    Értem én, hogy nem vagy képes megtanulni és megérteni egy komplex rendszert, aztán okosabbnak gondolod magad az összes tervezőjénél, mert nem érted a logikát, aztán ahelyett, hogy tanulnál, okosodnál, inkább nekiállsz gányolni és újra feltalálni a meleg vizet...

    ...mennyi ilyen fejlesztővel találkoztam már... de legalább van munkánk, amikor újra kell építeni azt a rombolást, amit ilyenkor véghezviszel.
    Mutasd a teljes hozzászólást!
  • A heti CPU statisztika hmmm...., úgy tudtam programozó vagy, de ezek szerint tévedtem.

    Mondjuk úgy, hogy DevOps architect... :)

    A felhasználót nem érdekli,hogy a GC miatt jó lenne pihentetni a telefont pár percre. Neki 1 óráig szüksége van rá és akkor legyen a toppon.

    Nincs olyan, hogy 1 órán át 100% pörög az összes mag, az esetek nagyon-nagyon részében ezredmásodpercnél kevesebb időkről van szó teljes terhelésen, utána meg tizedmásodperces idle állapotokról.

    Ha elfogy a memória és emiatt akadozik akkor az egész használhatatlan semmire sem jó, kukába való.

    Nem szokott a GC miatt akadozni... nézz hisztogrammot és metrikákat, olvass utána, hogy hány féle GC módszer létezik egy JVM-en belül, mit jelent a full GC, a compaction, a marking, a minor és a major collectiin és a többi... aztán gyere vissza néhány nap múlva és folytassuk a vitát, mert a fogalmak és a folyamatok ismerete nélkül nehéz. :)

    Szinkron módon csak azokat a memória részeket szabadítom fel amire éppen nincs szükségem és ÉN döntöm el, hogy ez mikor következzen be.

    Te döntöd el Java esetén is, hogy éppen mire nincs szükséged, csak a felszabadítás aszinkron folyamat, nem kell megvárnod, nem blokkolja a végrehajtást a felszabadítás (kivéve mondjuk a full GC, de akkor már rég szarrá van terhelve a folyamat és ezer sebből vérzik a sok memleak miatt)...

    ...de a fejlesztő döntése, hogy meddig él az adott objektum.

    Amúgy pedig, ha 1 processzorom van akkor varázsolhatok akármit akkor is a "fő szálam" lesz blokkolva.

    Továbbra se érted meg, hogy GC akkor is lefuthat, ha már vége a kiszolgálásnak és idle idő van... a szinkron felszabadítás viszont a kiszolgálási időből vesz el.

    egyszer csak beindul a GC és leállítja a fontosabb cuccokat

    Nem, ez nem igaz. Tanulj, olvass, értsd meg, aztán gyere vissza.
    Mutasd a teljes hozzászólást!
  • Dolgozz indiaival es megtudod :)
    Vagy egy nemettel, egy franciaval es latod mennyi felek az emberek.

    De akkor hasznaljak, hogy egy nemzet milyen mentalitasu, mikor sokkal dolgoztal egyutt es altalaban igaz (de nem szuksegszeruen mindenkire). Mondok peldat: azok a nemetek, akikkel egyutt dolgoztam, azok precizek, korrektek, de ennyi, nem azon dolgoznak, hogy lehet jobb, hanem megcsinaljak amit kell. De van, amelyik konstruktiv. De ha egy nemettel talalkozom, akkor tudom, hogy valoszinuleg mire szamithatok - aztan lehet nem az lesz. Akarcsak egy magyarral - mondok valamit meg a magyar mentalitasrol. Sok magyarral talalkozom idekint, es 80%-a beszelgetes elso 1 perceben megkerdezi, hogy mennyi a fizud, hol dolgozol es meg ocsarol valamit/valakit. De van 20%, aki nem. De ha meghallom a magyar szot, erre keszulok, sajnos, mert ez a mentalitas jellemzi a tobbseget...
    Mutasd a teljes hozzászólást!
  • - aki mindent meg akar oldalni es hajra es huha
    - a masik, aki mindig a problemat keresi, hogy ne kelljen egy feladatnak nekiallnia


    És milyen, nem magyar mentalitású személy létezik az említetteken kívül?
    Komolyan úgy gondolja valaki, hogy minden magyar egyforma, és ezáltal mindenki beskatulyázható?

    Ha nem, akkor mi értelme állandóan emlegetni a magyar mentalitást a "vitákban", főleg magyarok által?
    Vagy ilyenkor saját maga lustaságára, hozzáállására keres igazolást a kiejelentő személy?
    Mutasd a teljes hozzászólást!
  • Errefele hallottam mar emlegetni a magyar mentalitast, de kb 2 ertelemben (kulfoldi altal):
    - aki mindent meg akar oldalni es hajra es huha
    - a masik, aki mindig a problemat keresi, hogy ne kelljen egy feladatnak nekiallnia
    Mutasd a teljes hozzászólást!
  • De ez a tipikus magyar mentalitás: ha valamire már nem tud indokot mondani akkor jön a "csináld jobban".

    Az igazán magyar mentalitás szerintem az, hogy ha valaki a magyar mentalitást okolja valamiért (hallottatok/láttatok már olyan, nem magyar embert, aki a magyar mentalitásról panaszkodott?), és ha ez igaz, akkor máris végtelen ciklusba kerültél.
    Mutasd a teljes hozzászólást!
  • Egyszerűen megkerültem a GC-t és a sok h*lye beépített osztályt és amit kellett megírtam magamnak.

    Azért fikázni, mert valamit nem értesz/nem használsz, nem azt jelenti, hogy értelmetlen.
    Mintha azt mondanád, hogy a Factory/AbstractFactory pattern rossz, hiszen minden megoldható enélkül is. És igen, van ahol igen, van az a komplexitás.

    És igen. vannak tévedések (pl. java catched ecxecptiont egy idő után nem javasolt patterné tették). De amikor teveznek, akkor nem csak túl akarnak lenni rajta. 
    Bár a googlenál néha az az érzésem, hogy csinálnak valamit aztán majd kiderül jó vagy sem...
    Mutasd a teljes hozzászólást!
  • Részben igayat adok neked.
    De itt a saját szakmádról van szó! Nem egy idegen világról. Itt van esélyed tényleg jobbat csinálni, ha jó vagy. Én. ha egy sütemény nem ízlik, nem eszem meg, de nem próbálok jobbat csinálni. Akárcsak nem próbálok jobb autót építeni. De ha egy program nem tetszik, hibásnak találom, akkor van esélyem jobbat írni, beszélni a fejlesztővel, csatlakozni, forkolni, stb stb.

    Az meg, hogy magyar mentalitás... nem mennék bele személyeskedésbe erről, mert megkapnám, hogy külföldről osztom az észt. Ez részemről OFF.

    Félreértések elkerülése végett, nem a GCt, nem a Javat, akármit védem. Hanem azt, hogy több száz mérnök-informatikus több ezer óráját valaki mélyebb ismeret nélkül ócsárolja. vannak zsenik, akik megtehetnék (nem tudom itt mennyi van), de ők azok, akik ócsárolás inkább helyett csinálnak valamit.
    Mutasd a teljes hozzászólást!
  • Rossz a hozzáállásod.
    A hibák megtalálásához nem kell érteni egy adott dologhoz.
    Ha nem vagy zongoraművész akkor is hallhatod a hamis hangot és a melléütést.
    Ajánlom figyelmedbe a Kelly hősei című film egyik jelenetét amikor leállt a tank és a tank "vezetője" csak ül és mikor kérdőre vonják, hogy miért nem segít a javításban ennyit mond:
    "- Én csak vezetem, hogy mitől megy nem tudom."

    De ez a tipikus magyar mentalitás: ha valamire már nem tud indokot mondani akkor jön a "csináld jobban".
    Ha nem tetszik egy autó akkor nem veszem meg, de attól még nyugodtan kritizálhatom ÉS az aki valóban a vásárlóknak/fogyasztóknak akar JÓ terméket készíteni az meg is hallja és nem azzal jön, hogy "csinálj jobbat".

    Bár felteszem a mérnökök, ha tudták volna előre mire fogják használni a "marketinges" kollégák lehet jobban átgondolják azt a GC-t :D
    Mutasd a teljes hozzászólást!
  • Lsz. olvasd el ezt a leírást: Java 8 GC. Csak 5 különféle GC implementációt tud maga az Oracle JVM, és ezeknek még számtalan opciója van, amivel a működésüket lehet az igényeidnek megfelelően szabályozni.
    Mutasd a teljes hozzászólást!
  • Látom érted miről beszélek.

    A Java jó valamire, de a probléma az, hogy mindenre akarják használni és sokkal több hátránya van, mint előnye.
    Jól bejáratott marketing, elkötelezett funok stb....

    Lassú és nem bír a szűkös erőforrásokkal így gyakorlatilag megbízhatatlan.
    Azzal, hogy csak a GC van lelassult és megbízhatatlanná vált (már ami a sebességet és az erőforrás optimalizálást illeti). Ezzel nincs gond, mert pl a C meg nehezen kezelhető és nem túl biztonságos. 50x jobban oda kell figyelni arra amit csinálsz és egy pici hiba is akkora biztonsági rést eredményez amin befér az összes tizenéves hekkerpalánta egyszerre.
    Az asm-ről ne is beszéljünk, DE: senki nem akar írni (najó önszántából nem) banki alkalmazást asm vagy C-ben. Nem népszerűsítik ilyen célra, hogy úgy mondjam tudja hol a helye.

    A tudatos mérnöki tervezésről meg csak annyit, hogy amikor az Android a java mellett döntött elvileg az is tudatos mérnöki tervezés volt. Csak hát az nem biztos, hogy helyes is.

    Én pl nem ismerem jól a java-t (máig google-el kell kikeresnem pl a tömbök szintaktikáját), de simán meg tudtam benne írni egy normális játékot vagy egy adatbázis kezelő alkalmazást.
    Egyszerűen megkerültem a GC-t és a sok h*lye beépített osztályt és amit kellett megírtam magamnak.
    Amikor viszont DB-t kellett kezelni örültem, hogy pár sorból készen is vagyok és elsőre működik minden gond nélkül stb...
    Mutasd a teljes hozzászólást!
  • Amúgy a háztartások többésében elég egy kalapács és egy fogó. te döntöd el meddig, mit akarsz megcsinálni és mennyi energiát vagy hajlandó befektetni. Én pl sosem fogok jól énekelni, nekem a hangok egyenlőek :) Feleségemnek, aki énekel, neki nem. Kinek mi és meddig.
    Mutasd a teljes hozzászólást!
  • Néha azt érzem, hogy emberek olyan kijelentéseket tesznek, hogy elképesztő... A Java GC-je össze lett csapva. Tessék, adott a lehetőség, lehet jobbat írni. Senki nem tiltja meg.
    Olyan, mintha valaki azt mondaná, rossz ez az űrhajó, mert lassú. Lehet menni és jobbat csinálni.

    Nem hiszem, hogy itt bárkinek meglenne az az informatikai, matematikai, mérnöki tudása, hogy egy ilyen kijelentést ki merjen tenni egy ilyen komplexitású dologról. Nem egy ember este a kerti budin találta ki és csinálta meg.

    Igazad van: ez egy komoly mérnöki döntés eredménye, nem kiscserkészek házi feladata.
    Mutasd a teljes hozzászólást!
  • Félreértetted: Az, hogy csak GC van az a probléma, ezért mondtam, hogy össze van csapva.


    Az a gond, hogy te úgy mondod ezt, mintha a GC mellé odatenni a kézi memóriakezelést olyan kézenfekvő lenne, csak annak idején ezek a buta sunos mérnököknek nem jutott eszükbe. Igazából viszont az a helyzet, hogy a GC ad egy nagyon hasznos garanciát, mégpedig azt, hogy egy referencia vagy érvényes (és garantáltan egy olyan típusú objektumot érsz el vele, amit a deklarált típusa megad), vagy pedig null (és garantáltan NullPointerException-t dob, ha megpróbálod dereferálni). Ez, összerakva pár egyéb futásidejű ellenőrzéssel, úgy mint a kötelező tömbindex-ellenőrzés és a típuskényszerítések kötelező ellenőrzése, garantálja, hogy Javában nem lesz olyan, hogy korruptált heap, egymást véletlenül felülfirkáló objektumok, vagy puffertúlcsordulás.

    Elvben ezeket a garanciákat meg lehetne adni GC nélkül is (mint ahogy a QT megoldja az ide beidézett QPointerrel), de annak a költségét meg nem fogod akarni bevállalni az összes pointeredre, főleg a Javában, ahol minden nem triviális adatszerkezetet pointereken keresztül kell elérned. Szóval nem olyan könnyű félútra belőni a nyelvet a maximális biztonság és a maximális sebesség közé.

    Nem mondom, hogy a Java mindenhová való, Androidra pedig még soha nem fejlesztettem, ezért nem akarok beleokoskodni. Az viszont, hogy a GC-nek nincs alternatívája a nyelvben, az egyáltalán nem gányolás, hanem tudatos tervezés és mérnöki döntés következménye. Lehetett volna másképp tervezni, de akkor meg más hátrányoktól szenvedne a nyelv.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd