Új hozzászólás Aktív témák
-
floatr
veterán
Azért elég meredek, ha egy szakember ilyen kijelentést tesz. Nem a java nyelvről van szó, hanem a böngésző pluginről. Még kollégáktól is hallok néha olyan cifrákat, hogy szerver runtime-ot kéne frissíteni a biztonsági hibák miatt...
-
modeller
aktív tag
Messze nem csak a böngésző pluginról van szó. Keress rá a java-s CVE-kre, csak a JRE-t több mint 130 hiba érintette tavaly. Ezek a hibák nem csak a böngészőből használhatók ki, hanem desktopos alkalmazásokból és persze szerver oldalon is, ami JRE-t használ.
"Nem a java nyelvről van szó, hanem a böngésző pluginről."
Igen, a .net hibák, meg nem a .net nyelvet érintik, hanem csak egy adott .net framework-öt.
A helyzet az, hogy valóban iszonyat lyukas a java. Nálunk az összes gépről tiltva van, kivéve aki ányk-zik, mert ott sajnos muszáj ezt a hulladékot használni. Egyébként érdemes rákeresni, épp nemrég lett használhatatlan több bank java-s ebankja, az ügyfélkapus filefeltöltés és még sok más egy új java frissitéstől. Vissza kellett rakni egy még lyukasabb verziót az archiv letöltésekből. Vicc az egész.
-
halkow
őstag
más alternatíva után kellene nézniük
Alcatel onetouch idol2s the king
-
alevan
őstag
Előkaptam random álláshírdetés oldalt a megyében ahol lakom.
A leggyakoribb állásajánlatok informatikusoknak a PHP és a Java fejlesztők felé van.
"Ezért lovagol a pokolba a konzumer IT piac. A hülye igények... . Azt sem tudod, hogy mit akarsz de az jöjjon havonta frissités formájában."
-
tehát ha én rezolváltatok egy dinamikus dns nevet, akkor terrorista vagyok és nem a lakásom webkameráját akarom megnézni vagy valami hasonló prosztó kispolgári marhaságot akarok csinálni...
végülis ez egy jó vásárlásösztönző, ha minden piszlicsáré dolgot beleszámolok, hogy a veszély nagyobbnak tűnjön. de ugye megint el kell bocsátani a ciscotól embereket, ennyire jól megy nekik.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Gregorius
őstag
Itt van egy kis kavarodás. A programozási nyelv különösebben nem tud sebezhetőséget tartalmazni. Az egy darab specifikáció esetleg formális nyelvtannal. Fejlesztőeszköz/compiler persze tartalmazhat sebezhetőséget, de ezzel mezei user nem találkozik. A Java platform illetve runtime természetesen egészen más lapra tartozik.
A leggyakoribb állásajánlatok informatikusoknak a PHP és a Java fejlesztők felé van.
Nem feltétlenül ezzel van a baj, hanem a mellékelt ábrán a jobb alsó sarokban:
[link] -
modeller
aktív tag
Ez egy nagyon durva java hiba, mind kliens mind szerver oldalon működött, simán ki lehet lépni vele a sandbox-ból és bármit művelni a gépen. Ha a szerver oldali kódod használta az MBeanInstantiator-t és a runtime-od a lyukas szériából volt (mivel 0day exploit, ezért mindenkinek az volt) akkor lyukas is lett tőle az alkalmazásod.
Szerintem amiket te kliens oldali hibáknak gondolsz annak nagyon nagy százaléka pont ugyanúgy érint szerveroldalon is és ilyenből végtelen mennyiségű van. Más kérdés, hogy szerveren általában jobban felügyelve van a környezet, a futatott dolgok, de ettől még a java hibák ott is nagyon súlyosak. Aki nem patcheli folyamatosan a java-t szerveren, mert elhiszi, hogy az a kliens oldalt meg a böngészőket érinti az konkrétan hülye.
-
floatr
veterán
Amire én gondolok, az a java szerver pozicionálása. Általában úgy használják, hogy egy frontend szerver mögött van eldugva az alkalmazásszerver - kívülről védett. Belülről értelemszerűen megbízható rendszerek érhetik el - hacsak a belső rendszer nem átjáróház, megint csak elég sovány a dolog. Ha létezik OS szintű privilégiumszint eszkaláció, akkor egy helyi felhasználó támadhatja a rendszert - eltekintve a java hosting szerverektől szintén ritka, hogy problémás júzerek támadnának. Meg ha támadnának is, akkor erre adódhat jóval több lehetőségük, mint a JRE. De még várom azt az OS szintű PE exploitot, amivel ezt meg lehet(ett) tenni.
Amit a cikkben elemezgetnek, az a sandboxról szól. Elég gáz ez is, de JRE/plugin probléma, nem a "nyelvé".
-
modeller
aktív tag
Ne vicceljünk már ezzel. Ennyi erővel minden szerver tűzfal mögött van, meg DMZ-ben és csak másik szerver hivja és hasonlók. Tökmindegy. Ilyenkor szokták még előhozni, hogy "ó csak local exploit, távolról nem lehet kihasználni". Aztán nagy szemekkel néznek, amikor egy önmagában bagatel remote exploit-al kombinálva szanaszét törnek mindent.
Ezen nincs mit szépiteni, a java hibák a szerveren használt java-s dolgokat is érintik.
"szintén ritka, hogy problémás júzerek támadnának."
Ezt egy biztonsági szakértő meghallja, sirva futna el. Nem önmagában kell vizsgálni a hibákat, hanem rendszerszinten, ahol az apróbb hibák hatványozódnak és a végén átjáróház az egész rendszer.
" Elég gáz ez is, de JRE/plugin probléma, nem a "nyelvé"."
De hát ugyanazt a JRE-t használják szerveren is ami ezer sebből vérzik. A "nyelv" szón meg felesleges pörögni, mindenki tudja, hogy miről van szó, mint irtam .net hiba esetén sem a nyelv a hibás és php hiba esetén sem a nyelv a hibás, hanem a framework.
-
Kékes525
félisten
Sorozatosan jönnek a felismert hibák. Gondolom alapjaiban rossz. Teljesen át kellene írni, vagy váltani kellene, persze tudom, hogy nagyon nehéz.
Minden számítógép füsttel működik, ha kimegy belőle, akkor nem működik.
-
modeller
aktív tag
válasz Gregorius #12 üzenetére
Láttam már olyat, hogy ritka csillagegyüttállás esetén 10 byte-ot tudott kiirni egy tempfile-ba, amit időnként amúgy is törölt egy job. Önmagában ez bagatel, mert ezzel nem törsz be sehova, sőt még dos-olni se tudsz, mert nem fog betelni a temp drive, de kombinálva más hibákkal már csúnya dolog is lehet belőle.
-
modeller
aktív tag
Nem kell bevninni bytecode-ot, rosszindulatú user input (vagy, ha api-t/service-t publikálsz, akkor egy service hivás is) triggelrelheti a lyukat.
(a lyuk már eleve ott van, hogy pl. egy hibás fgv-t hivsz, ami a frameworkben hibás. Tehát nem a lyukat kell kintről beletenni a kódba, hanem csak triggerelni, a framework hibáját)[ Szerkesztve ]
-
dtracer
tag
Aha, szóval a kedves programozó volt szíves neked beleírni a kódba egy "hibás fgv-t", (persze az általad linkelt cikk az egy osztály engedélyeinek kijátszásáról szól, nem pedig programozási hibáról). Valamint azt is meg fogja neked nézni, hogy a kedvedért meghívhatja-e. Csak neked. Értem. Teljesen mindennapi probléma.
[ Szerkesztve ]
-
modeller
aktív tag
Szerintem te nem egészen érted miről van szó, de talán mindegy is.
Még jó, hogy gyorsan leszedted a hogyan triggerelhet user input egy lyukat kérdésedet, mert már éppen irtam volna egy LMGIFY-et, hogy tovább növeljem a szinvonalat...
"persze az általad linkelt cikk az egy osztály engedélyeinek kijátszásáról szól, nem pedig programozási hibáról"
Értem, tehát, ha az osztály engedélyei kijátszhatóak és ezáltal az egész java sandboxból ki lehet törrni és bármit csinálni az nem programozási hiba. Nyilván feature. Nem tudom miért kaphatta a legmagsabb veszélyességi besorolást az oracle-től, de tudod mit: nem is akarom tudni!
[ Szerkesztve ]
-
rt06
veterán
ezek a programozok mar csak ilyenek
az elobbi post-ombol kiszedtem a linket (most visszatettem, mert hirtelen nem talalok jre-set, es jobban utananezni lusta vagyok), mert nem jre, hanem commons-fileupload, de azt sem pistike irja (apache cucca) es megis, volt benne egy olyan hiba, ami megfelelo user input hatasara vegtelen ciklusba kergette a kodotPolitikailag korrekt, valamint munkahely- és gyermekbarát aláírás, amiben egyáltalán nincsen p*na.
-
modeller
aktív tag
De lehet mindjárt kiderül, hogy a szerver oldali java sebezhetetlen, ott nem kell patchelni soha, mert nem lehet exploit-olni a hibákat, vagy nincsenek is hibák a frameworkben. Méltó társa lehet az unbreakable linuxnak...
Vagy inkább /o\ mert mégiscsak szakmai fórum...
-
dtracer
tag
Segítek keresni, mert látom, hogy nem tudod hogyan kell. Szóval a Java az a programozási nyelv. A virtuális gép, amiben a bytecode fut, az a HotSpot. A JRE az csak a csomag neve. Szóval a HotSpot sebezhetőségre kellene keresned. Gondolom sok lesz, mert a cikkből is kiderült, hogy a Java a legsebezhetőbb nyelv. Ja nem az nyelv. Nem baj, akkor is a legsebezhetőbb. De lehet hogy csak a BASIC után.
És neked is köszönet a JBoss/Tomcat kódban levő sebezhetőségért, aminek semmi köze a témához.
[ Szerkesztve ]
-
pakriksz
őstag
szokásos havi FUD az m$ tájáról...
[ Szerkesztve ]
Troll (nemhivatalos definíció): az akinek véleménye nem tetszik nekünk/nem értünk vele egyet. (10-ből 9 fanboy ezt ajánlja) || Fanboy 8 in 1 (Intel, AMD, Nvidia, konzol, PC,+minden politikai oldal) hiszen "ahol nem mi vagyunk, ott az ellenség"
-
fordfairlane
veterán
Szerintem ha a JRE hibáiról van szó, akkor nem igazán jó kifejezés az, hogy a Java nyelv a sebezhető. A JRE-re más nyelvekről is lehet fordítani futtatható kódot, pl. Scala.
x gon' give it to ya
-
dabadab
titán
válasz fordfairlane #24 üzenetére
Raadasul Java JRE-bol azert nem csak egy van, a cikk meg gondolom csak az Oracle-fele darabrol szol.
DRM is theft
-
floatr
veterán
Ezek szerint a "ha" kimaradt. Csak azért kötöm az ebet a karóhoz, mert nem konkrétumokról beszélsz, hanem csak általában lehetőségről. A file upload már valami, de még mindig nem az, amitől a java-nak önmagában pusztulni kéne (hibás az apache, pusztuljon c/c++). Ettől sokkal komolyabb exploitok voltak az utóbbi időkben openssl-re, x11-re, apache httpd-re meg kitudja még mi a rákra - local meg remote is. Ráadásul egy rakat ilyen sokáig még akkor is foltozatlan maradt, amikor kiderült a hiba, ezek szerint akkor mindezeknek pusztulni a kéne
A plugines dolgokkal én sem vagyok kibékülve, de a jws alkalmazásokkal (pl. abev) már hadd ne legyen probléma, ha a user dönti el, hogy akarja-e használni. A szerver dolgait illetően meg még mindig nem értünk egyet. A runtime hibák nagy része a sandbox-szal kapcsolatos. Amit linkeltél, az is. Ettől függetlenül nekem sem tetszik, ahogy az oracle kezeli a dolgokat.
De akkor meg rettegjetek, mert a bankok vakmerően használják
-
válasz VaniliásRönk #27 üzenetére
a legtöbb gépen dalvik fut, nem oracle hotspot kliens.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
dabadab
titán
válasz VaniliásRönk #27 üzenetére
"Ez csak elvi kérdés"
Szerintem az, hogy sebezheto-e a szerver, az nem elvi kerdes.
"a legtöbb gépen Windows, azon pedig Oracle JRE fut, szóval az a meghatározó."
A legtobb Windows?... Haho, szerverekrol is szo van!
[ Szerkesztve ]
DRM is theft
-
VaniliásRönk
nagyúr
Amennyire a cikkből ki tudom venni, böngészőben futó Java alkalmazások sebezhetőségeiről van szó, azoknak meg sok köze nincs a Dalvikhoz. Rosszul gondolom?
#30 dabadab: Hol írták azt, hogy a szervereket támadták?
[ Szerkesztve ]
"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)
-
floatr
veterán
Egy kicsit félreértesz "minket". Alapvetően én is frissítéspárti vagyok, csak láthatóan nem érted, vagy nem akarod érteni a problémát. Vagy egyszerűen nem ismered.
Java esetében hatványozottan igaz az, hogy ami nem romlott el, azt nem akard megjavítani. Az utóbbi években ez a kevésbé figyelmes rendszergazdáknál is lejöhetett, hogy a Java update nem patch-elés. Sok dolog változik egy új release-ben, és odavághat olyan technológiáknak, amik egy nappal korábban még tökéletesen működtek. A JRE 1.7.0 apache komponenseket vágott gallyra. A tavaszi biztonsági frissítések miatt az appletek és a JWS alkalmazások voltak szopóágon. A legutóbbi frissítés (j8u11, j7u65) a JRebel-t és a Groovy-t nyírta ki, szintén desktop oldali biztonsági kötélhúzás okán.
Szóval hacsak nincsen valami konkrét és komoly exploit a szerver oldalon, egy épelméjű support nem fogja kockáztatni a vállalat rendszerének teljesen ufó lerohadását egy nagyon korlátozott elérhetőségű alkalmazásszerver vélt sérülékenységének feltételezett javítása érdekében.
(#31) VaniliásRönk véletlenül azt hitte, hogy a dalvik is java runtime A szerver sérülékenységét, meg most próbálják igazolni helyi levezetéssel. A szerver-oldali dolgokról még a komolyabb szagemberek is annyit mondanak csak, hogy untrusted 3rd party komponensek, amiben nyilván bele lehet futni, ha az ember azt sem tudja, mit épít az alkalmazásba. Volt már erre példa (mármint JAR-okat feleslegesen halmozó emberek) de nem voltak hosszú életűek komolyabb projektekben. Szóval megint egy olyan dolgot erőltetnek itt páran, amiről láthatóan nem tudnak többet mondani, mint az általános szövegek.
[ Szerkesztve ]
-
nem, nem hitt semmit, tudja, mi az a dalvik.
az az állítás, hogy a gépek többségén windows fut, nem igaz. a desktopok többségén fut windows, a desktopokra leszűkíteni a poszt állításait abból a téves feltételezésből indul ki, hogy a jelentés csak a desktopokon futó böngészők sebezhetőségeiről szól, pedig nem, rá kell klikkelni.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
floatr
veterán
Akkor gondolom az kimaradt, hogy nem a teljes jelentés volt a beszélgetés tárgya, hanem a "java nyelv" sebezhetősége, amiről végül kiderült, hogy inkább a hotspot runtimera és a pluginre gondoltak a szakemberek, csak véletlenül eltévesztették.
A másik része meg megint csak más tészta -- kinek mi a vesszőparipája -- hogy a sebezhetőségek tekintetében a szerverek elég kis hangsúlyt kaptak "valamiért". Így akkor maradtak a mobilok, meg a desktop, amiből még egyelőre az utóbbi van többségben.
-
ddekany
veterán
Ehhh... Simán trollkodnak az ITCafe szerkesztők, hogy ezt ezzel a címmel így lenyomták.
Eközben a valóságban... a Java nyelv (meg a managed code) sikere szerver oldalon jelentős részben annak köszönhető, hogy kvára biztonságosabb mint ha mondjuk C++-ban fejlesztesz. Meg még annál is egyébként, mintha vmi dinamikus nyelven (PHP, Pyrhon, Ruby). Szóval kb a legbiztonságosabb nyelvek közt van valójában, amennyire egy nyelvnek erre kihatása lehet... de nem baj... akkor is a legsebezhetőbb... Sajtó.
Meg látom közben beindult a küzdelem is azok közt, akik ténylegesen szerver oldalon fejlesztenek, és azok közt akik nem, és ettől jobban tudják. Ez már csak ilyen. De szóval, hátha vki mégis megérti... egy szerver alkalmazás, attól függetlenül hogy miben írták (Java, PHP, stb.), ált. úgy néz ki, hogy fogad külső világtól vmi HTTP kérelmeket, vagy mi a feladata, és azon kívül te ott nem fogsz turkálni, meg felcsatlakozni, hacsak nem töröd fel a szervert amin belül fut a Java bizbasz, szóval kb. "a Linux-ot", SSH-t, stb. A Java lukas sandbox-ának szerepe szerveren ritkán van, mert egy szerver alkalmazás az nagyon is akar írni a merevlemezre, meg minden szörnyűséget csinál, amit az OS user ami alatt fut megtehet.
Az hogy a Java plugin mekkora egy trágya, és hogy lerúgom én is ha lehet, az tök más kérdés. Sőt nszvsz az egész desktop Java eléggé... khm. Nem akarnám azzal szívatni "gizit", hogy Java-ban írok neki desktop alkalmazást. Szerver tök más táma.
[ Szerkesztve ]
-
ddekany
veterán
válasz julius666 #37 üzenetére
Egyébként amennyire emlékszem anno pont az Interneten kliens oldalon futtatás miatt fűztek nagy reményeket a Java-hoz a készítők. Aztán végül kezdeti emelkedés után pont ott esett pofára, míg szerveren hatalmas siker lett. Bár a bukás oka aligha sandbox lyukassága volt (miközben mások natív kódot tudnak sandboxban futtatni... nekik is azt a fajtát kellett volna), hanem azt gondolom az, hogy béna volt grafikai tudásában egy Flash-hoz képest... ami persze ugyan csak állandó biztonság gondok forrása. Még mondhatnám hogy Java és Java plugin telepítő és update mekkora trágya, de a Flashé kb. egy kategória vele, szóval ez tán nem számított.
A böngészőn kívüli desktop Java-t meg sajnálom, és egyébként az a tradicionális (C++ stb) alkalmazásoknál igenis jóval biztonságosabb. Pont a nyelv és az eredetileg azt "utánzó" JMV filozófiája miatt. De az a töketlenkedés és most már talán beleszarás is ami azon a fronton folyik... Én agresszív dekstop Java irtóvá kb. akkor váltottam át, mikor Oracle úgy döntött, hogy a Java update-el felteteti "gizikiével" as Ask toolbart. Persze Oracle, azoktól az állatoktól én bármit kinézek...
-
-
julius666
addikt
Bárhogy is volt, a kliens oldali Javaért nem fogunk könnyeket hullajtani. A potenciál simán benne volt, érdemes megnézni, .NET alapokon mit tudott a másik oldal összehozni (WPF, Silverlight), vagy mit tudott vele a Google kezdeni mobilon (az Androidos UI fejlesztői szempontból pl. kifejezetten rendben van, ott igazából a platform töredezettsége az, ami miatt szopás tud lenni).
Ezekhez képest desktop kliens Java oldalon ami van, az már 10 éve is kevéske volt, a runtime ősrégi kókány megoldásainak köszönhető rejtett csontvázakról nem is beszélve. Méltán kiérdemelte a Java, hogy desktop alkalmazást nagyon rég óta csak ilyen ÁNYK szintű szemeteket készítenek benne, inkompetens cégek, inkompetens megrendelőknek. Őszintén szólva nem vagyok képes felfogni agyilag, hogy pl. egy bank hogyan képes a fizető ügyfeleit appletes vackokkal szopatni. Képtelen vagyok felhozni racionális érvet ezek mellett.
Szvsz egyébként a Java szerveroldalra sem olyan hűhadejó, de mint te is írtad, ott a rejtőző csontvázak nagy része nem, vagy kevésbé játszik, illetve ha egy egyszerű, webes UI-nál összetettebb kell (mondjuk több külső servicehez csatlakozva, összetett üzleti logikával), multiplatform/*nix alapra, akkor nem, hogy nincs jobb, úgy egyáltalán nem is nagyon van alternatíva. Persze mindent meg lehet oldani Pythonból, Rubyból, vagy éppen NodeJS alól is, csak hát ugye nem mindegy, hogy milyen már meglévő segédeszközök léteznek ezen feladatokhoz, a sok tízezer sornyi üzleti logikánál a statikus típusosság előnyeiről nem is beszélve.
-
attila9988
őstag
Egy programozási nyelv nem lehet sebezhető. Egy software viszont igen, pl a java -hoz tartozó futtatókörnyezet/platform, a jvm.....
Szóval a cikk címe csalóka.Mondjuk nem is értem miért olyan nagy szám a java manapság. Lassú, működéséből adódóan nagyon eszi a memóriát, applet -ként már csak az idióták használják, kliens oldalon a rettentő béna gui tool -ok miatt használhatatlan hulladék, az oracle pedig megtesz mindent, hogy minél kevesebben használják ezt a platformot...
Oké hogy szerver fronton backend -ként jó lehet, de nagyjából ennyi. Most meg, hogy az oroszokkal is kötözködik az oracle, egyre kevesebben fognak majd bízni a java -ban.Szóval nem is a sebezhetőségek mennyisége fogja megölni, hiszen ha ez lenne a döntő, akkor pl senki nem használna windows -t, hiszen abban is minden hónapban találnak pár meglepetés sebezhetőséget....
Ami meg fogja ölni, azok az alapvető hiányosságok, és problémák.„Csak az apró titkokat kell védeni. A nagy felfedezéseket a nyilvánosság hitetlensége védi.” (Marshall McLuhan)
-
attila9988
őstag
A virtuális gép, amiben a bytecode fut, az a HotSpot.
Nem egészen... a virtuális gép, az a jvm. A hotspot meg ennek egy része, ami a jit működési mechanizmusát szabályozza.
„Csak az apró titkokat kell védeni. A nagy felfedezéseket a nyilvánosság hitetlensége védi.” (Marshall McLuhan)
-
attila9988
őstag
Ráadásul egy rakat ilyen sokáig még akkor is foltozatlan maradt, amikor kiderült a hiba, ezek szerint akkor mindezeknek pusztulni a kéne
Hát ez az... ezért írtam hogy ha ez lenne a mérce, akkor már windows -t sem használna senki ezer éve... sőt, ki kellene kukázni az összes számítógépet, és akkor lenne tuti biztonságos papír alapú ügyintézés.... működött az is régen...
„Csak az apró titkokat kell védeni. A nagy felfedezéseket a nyilvánosság hitetlensége védi.” (Marshall McLuhan)
-
ddekany
veterán
válasz attila9988 #42 üzenetére
"Mondjuk nem is értem miért olyan nagy szám a java manapság."
Én szervereken azt mondom, hogy nincs is nagyon más, ha hosszú ideig futó "entőpráÁájz" rendszereket akarsz készíteni. Ok, de van, a C# világ, ami technikailag azonos műfaj, csak az az MS-es világ része. (Meg még lehet vallás háborúzni a dinamikus nyelves táborral, de... azt hagyjuk is.)
"Lassú,"
Hosszú ideig élő folyamatokra való. Olyankor mi gyorsabbnak nála? Most eltekintve C++/ASM és többi tradicionális cucctól, amik viszont rengeteg területen szóba sem jöhetnek karbantarthatóság, fejlesztőeszközök, üzembiztosság és sebezhetőség miatt. Mellékesen azok is csak akkor gyorsabbak általában ha tényleg arra mész rá és értesz hozzá.
"működéséből adódóan nagyon eszi a memóriát"
Attól függ hogyan nézzük... Ez egy GC-s környezet, azoknak megvannak a maga gondjai. De eltekintve beágyazott meg (soft-)realtime dolgoktól (pl. játék engine) már mindenki csak röhögni tud azon, hogy GC nélkül programozzon. És ha már GC, minek van fejlettebb GC megvalósítása, mint a Sun/Oracle féle JVM-nek? Ami hiányzik, az a mélyebb OS integráció, mert anélkül sajnos a JVM-től nem nagyon kapja vissza az OS a valójában már nem használt memóriacafatokat amire egyszer ráült a JVM. CLR-nél gondolom MS valamit tud ez ellen tenni, elvégre ott az OS is az övék.
-
ddekany
veterán
válasz attila9988 #43 üzenetére
Nem, tudtommal a Sun/Oracle JVM megvalósításnak adták a HotSpot a termék nevet.
[ Szerkesztve ]
-
julius666
addikt
válasz attila9988 #42 üzenetére
Lassú, működéséből adódóan nagyon eszi a memóriát
Ezeket kliens oldali kódhoz számítod mint hátrányokat, ugye? Csak mert szerveroldalon a memóriaigény kis túlzással a kutyát nem érdekli (mindaddig amíg korlátos marad, tehát nem leakel az alkalmazás).
Mondjuk a sebességgel kliens oldalon sem értem mi lenne a gond. Oké, hogy az indulás lassú, de a másik oldal nagy üdvöskéi, a .NET-es alkalmazások sem éppen túl fürgék ilyen szempontból. Win only fejlesztésnél pedig más alternatíva jóformán fel sem merül.
Betöltés után, runtime meg teljesen oké a Java, simán köröket ver egy Pythonra vagy JavaScriptre, amiben mostanság bőszen fejlesztenek desktop alkalmazásokat *nix vonalon is.
-
ddekany
veterán
válasz julius666 #47 üzenetére
"Csak mert szerveroldalon a memóriaigény kis túlzással a kutyát nem érdekli"
Akkor azért tegyük hozzá, hogy "nagyvállalati" alkalmazásokról van szó. Mert van aki havi párezres PHP-s sharing hostingból indul ki, ahol egy alkalmazás átlagos memória igénye lepkefing... főleg mert általában nincs is, csak arra a pár pillanatra amikor épp beesett egy látogató.
-
attila9988
őstag
-
attila9988
őstag
válasz julius666 #47 üzenetére
Ezeket kliens oldali kódhoz számítod mint hátrányokat, ugye?
Igen... úgy gondoltam. Hogy egy nagyvállalatnak mi a pro, és a kontra, azt majd ők eldöntik. Ha nekik van elég ram, de kell valami java -s bigyó, vagy éppen heterogén a szerverpark, akkor nyilván a java más tulajdonságai bőven előnyösebbek, mint ha rammal spórolna. Kliensen viszont kurva nagy pazarlás. Nekem pl van egy letöltögetős programom, amit csak pár oldalhoz használok, de már indulása után bezabál 160mb ramot, 64bit -es vm -en úgy, hogy még nem is csinál épp semmit.
Mondjuk a sebességgel kliens oldalon sem értem mi lenne a gond. Oké, hogy az indulás lassú, de a másik oldal nagy üdvöskéi, a .NET-es alkalmazások sem éppen túl fürgék ilyen szempontból. Win only fejlesztésnél pedig más alternatíva jóformán fel sem merül.
Persze... a .net is egy rakás szar ebből a szempontból, eszem ágában nem volt azt védeni. SŐT, mivel az még csak nem is multiplatform, és saját magával sem kompatibilis szinte soha, ráadásul 86 féle változat kell a gépre ha minden .net programot használni akarsz.... hát..... szóval szar az is...
Betöltés után, runtime meg teljesen oké a Java, simán köröket ver egy Pythonra vagy JavaScriptre, amiben mostanság bőszen fejlesztenek desktop alkalmazásokat *nix vonalon is.
Ebben tökéletesen igazad van.... még egy olyan fost mint a python, ritkán látni. Komolyan.... és az sem kompatibilis magával, még annyira sem mint a .net. Simán van olyan python program, ami csak és kizárólag bizonyos alverzióval hajlandó menni, és mással nem..... mekkora egy szar.
Na de attól hogy van valami ami szarabb mint a java, még nem lesz automatikusan jó a java.
Nem mellesleg a gui tool -ok valami rettentően rosszak hozzá.... A reakcióidejük ugyanúgy, mint a kinézetük. Rövid úton aztán szépen meg is halt kliens oldalon. A teljesítmény gondokat meg mi sem bizonyítja jobban, hogy még egy irodai programot sem tudtak megírni benne, vagy egy browser -t, mert azokhoz is kevés volt. A legkomolyabb kliens oldali java programok meg leginkább az eclipse, és a netbeans, amikre meg szintén állandó teljesítménnyel kapcsolatos panaszok vannak..... de mindig hozzáteszik hogy nem azért mert java... pedig dehogyis nem azért.....
„Csak az apró titkokat kell védeni. A nagy felfedezéseket a nyilvánosság hitetlensége védi.” (Marshall McLuhan)
Új hozzászólás Aktív témák
- Kerékpárosok, bringások ide!
- Mobil flották
- Háztartási gépek
- Házimozi belépő szinten
- Politika
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Videós, mozgóképes topik
- Samsung Galaxy A55 - új év, régi stratégia
- Sony MILC fényképezőgépcsalád
- A Xiaomié lehet a Snapdragon 8 Gen 4-es elsőség
- További aktív témák...