Proč je Java špatná na server?

[zzxzxzx]

majme linux server, vsetky systemove utility su pisane v C a vsetko je to zlepene s bashom (sh ... proste skripty). Pozorujem pravidlo, ze co je tazke implementovat v C (casovo narocne a zbytocne), dobastli sa to nejako v shelli.

Preco sa na systemove nastoje nepouziva viac napr. Java alebo Groovy? Vsade vidim python, perl, bash, ruby ... mozno lua. Co je take strasne na napisani niecoho systemoveho v Jave? Argument "moc to zere pamate" neobstoji. JVM sa da nastavit k spokojnosti kazdeho, (Xmx, Xms)

V sucasnej dobe gigabajtovej pamati a IDE ktore pomaly pise za vas sa stieraju rozdiely medzi klasickymi interpretovanymi jazykmi a kompilovanymi, najma nad JVM.

Preco by som sa mal Java na serveri vyhnut?

[Reklama]

[Lol Phirae]

A preco na serveri? Java je zlo zcela obecne.   

[eMko]

Já bych se třeba Javě na serveru nevyhýbal. Nicméně všimni si, že "cold start" groovy programů je mnohem pomalejší, než u srovnatelných pythonových skriptů. To, že po spuštění příkazu musím čekat i 3s než se začne něco dít, je na takovýto typ úlohy obrovská nevýhoda.

Volby Xmx a Xms taky nejsou samospasitelné - stále přetrvává, že JVM nevrací aktuálně nevyužitou paměť systému a tím pádem často mívá alokováno víc, než je potřeba (a než je zrávo). To je dvousečná zbraň - v případě systémových utilit, které se spustí a rychle ukončí, je to jedno. Ale zkus si mít puštěné např. SoapUI kvůli testování webových služeb a už to poznáš.

A k IDE - jo, je fajn, že to píše za mě, ale až na výjimky (např. ActionListener v IntelliJ IDEA, který se standardně zobrazí jako lamda výraz i v Javě 7) to za mě ten kód nečte. A to je neméně důležité.

[qw]

musis sa spytat sameho seba, ze kde by bola ta vyhoda pisania systemovych utilit v jave? vyvijat a spustat skript napisany v pythone je brnkacka. a pokial sa jedna o nejaku utilitku, tak naco si veci komplikovat bajtkodom javy a celym jvm. aj tak by si musel pisat nejaky wrapper skript, ktory nastavy jave classpath a cely environment... nestoji to za to. aspon ja osobne nevidim ani jednu vyhodu javy pre takyto typ uloh. len same nevyhody.

[qw]

wrapper skript, ktory nastavy

oops, malo byt samozrejme "nastavi"

a este dodam, ze java je skratka na take male utilitky moc ukecana...

[Reklama]

[majo33]

Java mi pride o dost zlozitejsia na nasadenie oproti Python-u. Python nepotrebuje build script, Java ano. Python skripty su v podstate zdrojaky. Skript v Java by bolo asi jar-ko, ku ktoremu by si musel dodavat zdrojaky aj build script aby si ho mohol obcas upravit.

[zzxzxzx]

Musim uznat ze na systemove utility typu "ls" alebo "cat" ci "grep" to je fakt bezpredmetne lenze ked si zoberiete systemovych demonov, tak uz to je ina kava. JVM sa spusti len raz ...

Ja si viem prestavit Javu aj ako nedemonovu aplikaciu. Viem si celkom dobre predstavit pouzitie napr. CDI v Jave SE (napr. ako Weld container). Jednoducho, pouzitim Javy sa mi otvaraju take moznosti v oblasti administracie a konfiguracie ktore v Cecku alebo v skriptoch velmi tazko zrealizujem. Dokazem pouzit ako som uz spomenul CDI=, JPA napriklad, to sa tiez da pouzit v Java SE.

A ked si napr. zoberiem nejaky aplikacny server ako napriklad WildFly od JBoss-u, tak obetujem nejake megabajty na brutalnu platformu kde mam pristup k messagingu a fure inych veci, velmi vela veci sa da nakodit ako tenky klient cez skripty ktore len volaju nejake REST api na serveri ...

[wq]

A ked si napr. zoberiem nejaky aplikacny server ako napriklad WildFly od JBoss-u, tak obetujem nejake megabajty na brutalnu platformu kde mam pristup k messagingu a fure inych veci, velmi vela veci sa da nakodit ako tenky klient cez skripty ktore len volaju nejake REST api na serveri ...

WildFly od JBoss-u - tak ten bol dobry myslim, ze proti aplikacnemu serveru v jave nikto nic nema. tak schvalne: ktory daemon, ktory ti momentalne bezi na masine by si prepisal do javy a preco?

[zzxzxzx]

WildFly od JBoss-u - tak ten bol dobry myslim, ze proti aplikacnemu serveru v jave nikto nic nema. tak schvalne: ktory daemon, ktory ti momentalne bezi na masine by si prepisal do javy a preco?

Skusal si ten WildFly? Ten server startuje za 2.5 sekundy a ma zapnute len core pluginy, vsetko sa potom zapina az ked to je treba. Co by si este chcel? Tu uz rychlost nehra rolu. Dve sekundy na start je uplne nic. A potom uz len profit. Lenze raz sa povedalo, ze Java je velka zla a pomala a server = bash a C tak to tak musi byt na veky vekov ... nechapem dovod preco by sa to nemalo pouzivat.

Mam nejake napady co by sa dali spravit, ani nie prepisat, ale skor napisat odznova. Viem si napr. predstavit nejakeho monitorovacieho / logovacieho / reportovacieho demona. Taktiez si viem predstavit sluzby typu klient - server, v EJB mas stare zname @Schedule cez ktory sa da napisat nieco lepsie ako cron ... atd atd ...

Ked si na ten server / soft napises dobre API / SPI tak to uz odzakladu spravis customizovatelne cez pluginy ktore staci dat len na class path.

[wq]

Skusal si ten WildFly? Ten server startuje za 2.5 sekundy a ma zapnute len core pluginy, vsetko sa potom zapina az ked to je treba. Co by si este chcel? Tu uz rychlost nehra rolu. Dve sekundy na start je uplne nic. A potom uz len profit. Lenze raz sa povedalo, ze Java je velka zla a pomala a server = bash a C tak to tak musi byt na veky vekov ... nechapem dovod preco by sa to nemalo pouzivat.

ano, skusal. skor som narazal na to, ze WildFly nie je od JBoss-u, ale je to community verzia JBoss-u od Red Hatu. Myslim, ze som jasne napisal, ze proti aplikacnemu serveru v jave nikto nic nema. nikto sa to nepokusa reimplementovat v C ani v bashi.

Mam nejake napady co by sa dali spravit, ani nie prepisat, ale skor napisat odznova. Viem si napr. predstavit nejakeho monitorovacieho / logovacieho / reportovacieho demona. Taktiez si viem predstavit sluzby typu klient - server, v EJB mas stare zname @Schedule cez ktory sa da napisat nieco lepsie ako cron ... atd atd ...

Ked si na ten server / soft napises dobre API / SPI tak to uz odzakladu spravis customizovatelne cez pluginy ktore staci dat len na class path.

lenze tu sme zasa u toho, ze co by si tym ziskal? implementovat cron v EJB? to je trosku overkill nemyslis? dobre API a pluginy mozes mat a mas aj v C. jedina vyhoda by mohla byt trosku rychlejsi vyvoj, ale otazne je ci to za to stoji, kedze teraz uz mame davno overene/otestovane riesenia a nepotrebovali sme XY urovni abstrakcie.

[eMko]

"Yes, napíšeme ls v Javě s využítím EJB. A aby to běželo spolehlivě, tak to ještě narveme do OSGi kontejneru. Protože Java je bezpečná a i kdyby ten projekt nakonec padl, tak mě jak projekťáka nevyrazí, protože za zvolení Javy (Oracle, Microsoft, .Net ...) ještě nikoho nevyrazili."

Tohle mi trochu připomíná korporátní prostředí :-) .

[Kolemjdoucí]

Preco by som sa mal Java na serveri vyhnut?

Pochopíš přesně v momentě, kdy zákazník volá že "mu to nefunguje" a ty zjistíš že malá nevinná utilitka v Javě na tři obrazovky vyžrala 8 GB RAM, server swapuje a z procesoru se kouří. Po předělání do tradičního C++ spokojenost maximální.

pouzitim Javy sa mi otvaraju take moznosti v oblasti administracie a konfiguracie ktore v Cecku alebo v skriptoch velmi tazko zrealizujem.

A to třeba jaké například ?

[none_]

Pochopíš přesně v momentě, kdy zákazník volá že "mu to nefunguje" a ty zjistíš že malá nevinná utilitka v Javě na tři obrazovky vyžrala 8 GB RAM, server swapuje a z procesoru se kouří. Po předělání do tradičního C++ spokojenost maximální.

To že někdo naprogramuje aplikaci prasácky nezávisí na programovacím jazyku. A memmory leak jde jednoduše naprogramovat i v C++.

[j]

Preco by som sa mal Java na serveri vyhnut?

Zeby predevsim proto, ze na serveru se kazdej normalni clovek snazi o to, aby to bylo "as simple as possible". Navic bash je proste "vsude" a nemusis kvuli spusteni nejaky blbosti resit, jak tam dostat javu, uz vubec nemluve o tom, jak tohodle mohlocha dostanes do nejakyho embedded zarizeni ... A o bezpecnosti javy ... se ani neda mluvit, protoze zadna neexistuje. Ne kazdyho admina bavi si 5x tydne cist o tom, kde zase a nejakou diru a jak ji zalepit.

[omg]

protoze swap. pokud jsi v podnikove sfere, tak se optimalizuje cena/vykon a obvykle plati, ze se jednou za cas najde spicka, ktera bude za hranici kapacity. tohle neplati snad jenom ve statnim(odposlechy) nebo nebo u kritickych systemu, kde je zodpovednost za zivoty(teleco - nouzove volani). ostatni obory kde by jeste byl nejaky ten client-server model mozna doplni dalsi. no a kdyz prijde - otazka je kdy a jak dlouho potrva a ne jestli vubec prijde, tak server na kterym bezi cokoliv s garbage kolekci jde do kopru daleko snaz, protoze pri prekroceni navrhove kapacity zacne swapovat naprosto zbytecne pamet, kterou by mohl zahodit.