Fórum Root.cz
Hlavní témata => Server => Téma založeno: zzxzxzx 20. 11. 2013, 22:52:45
-
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?
-
A preco na serveri? Java je zlo zcela obecne. ;D :P
-
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é.
-
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.
-
wrapper skript, ktory nastavy
oops, malo byt samozrejme "nastavi" :)
a este dodam, ze java je skratka na take male utilitky moc ukecana...
-
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.
-
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 ...
-
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?
-
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.
-
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? :D 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.
-
"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í :-) .
-
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 ?
-
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++.
-
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.
-
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.
-
To že někdo naprogramuje aplikaci prasácky nezávisí na programovacím jazyku. A memmory leak jde jednoduše naprogramovat i v C++.
Nejednalo se o memory leak ani o prasáckou aplikaci.
-
Systémové utility jsou psané v C nejčastěji z toho důvodu, že jsou mnohem starší, než Java. V případě těch mladších se pak C, shell, Python apod. používají z tradice. Java by v případě malých utilit nebyla příliš vhodná, protože JVM je optimalizovaná pro větší aplikace, takže samotný start JVM by v případě malých utilit trval déle a spotřeboval více paměti, než pak vlastní aplikace. Python má asi jinak uspořádanou VM, takže nemá tak velkou režii při startu (ale pak asi zase nebude tak výkonný u déle běžících aplikací).
Jinak ale pro serverové aplikace (které běží dlouho a poskytují služby po síti) se Java používá velmi často -- záleží na přesném způsobu měření, ale C, C++, C# a Java budou v čele, pak bude odstup a pak teprve další technologie.
-
Zatimco v Ccku se da programovat ve Vim-u anebo Emacsu, tak Java je zavisla na Eclipse (anebo Netbeans). Samozrejme, ze se teoreticky da delat v Jave i bez tehle enterprise IDE, ale nikdo to nedela. Navic je Java platformove nezavisla, to muze byt vyhoda, ale pro psani systemovych utilit je to velka nevyhoda. (Zapomen na xattr, ipc, mmap, poll, pid procesu, signaly, ...)
-
No a pro kterou Javu to vlastne psát? Oracle, Icetea, ...., kazdá se chová trochu jinak. To se u přeložené binárky nebo bash, perl, python skriptu neděje.
-
Jak již tu bylo zmíněno, ale zaslouží si zdůraznit: startup time - příliš pomalý start JVM.
Pokud by dokázal nastartovat rychle (jako python) nebo nějakým způsobem zůstával "rezidentní" (něco jako má .NET na windows), tak by bylo groovy skvělý scriptovací jazyk (minimálně na úrovni pythonu nebo perlu). Samozřejmě Java jako jazyk je docela mimo mísu a psaní low-level utilitek je asi jen námět na flamewar.
-
startup pujde asi zkratit.
1. predkompilovat.
2. hodit to do strace a podivat se do jakych cest se diva zbytecne a ty pak odstranit.
-
Scripty v groovy normalne pouzivame. Rychlost startu neni podstatna nespousti se zase tak casto aby tech par sekund vadilo.
Groovy umi vynikajicim zpusobem http://groovy.codehaus.org/api/groovy/lang/Grab.html nahravat potrebne knihovny, neni potreba udelat jar - vse v jednom.
-
No a pro kterou Javu to vlastne psát? Oracle, Icetea, ...., kazdá se chová trochu jinak. To se u přeložené binárky nebo bash, perl, python skriptu neděje.
Zrovna v případě jednoúčelových skriptů byste na rozdíly v implementaci Javy asi nenarazil. Zato na rozdíly v sh, bash, zsh, ksh, csh, tcsh narazíte každou chvíli, to samé Python 2 vs Python 3. To nebyl moc dobrý argument.
-
No a pro kterou Javu to vlastne psát? Oracle, Icetea, ...., kazdá se chová trochu jinak. To se u přeložené binárky nebo bash, perl, python skriptu neděje.
Mam to chapat tak, ze aplikace napsana podle specifikace se chova jinak kvuli chybam v Oracle/OpenJDK/IBM JDK atd.? To uz je podle toho co vim, hodne minimalizovano...
-
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.
Tady je ale rec o jave na serveru, ne na klientovi. Drtiva vetsina tech problemu se tyka jen klientskych aplikaci(hlavne applety).
Nejednalo se o memory leak ani o prasáckou aplikaci.
A o co se teda jednalo?
-
Mam to chapat tak, ze aplikace napsana podle specifikace se chova jinak kvuli chybam v Oracle/OpenJDK/IBM JDK atd.? To uz je podle toho co vim, hodne minimalizovano...
Obecně to platí, ale dá se na to narazit. Proto všude rvu Javu od Oraclu, byť to neřeší problém, že na linuxu jsou jiné chyby než na windows.
-
Nejednalo se o memory leak ani o prasáckou aplikaci.
A o co se teda jednalo?
V tomto případě démon na procházení výsledků jisté aplikace a hledání souvisejících klíčových slov na po sobě jdoucích řádcích, ve zdrojáku to bylo průzračně triviální.
Nepochybuji že Java guru by to dal do kupy, jde o to že se tohle s Javou občas děje a na serveru to má horší následky než typická chyba C/C++: segmentation fault.
-
Nejednalo se o memory leak ani o prasáckou aplikaci.
A o co se teda jednalo?
V tomto případě démon na procházení výsledků jisté aplikace a hledání souvisejících klíčových slov na po sobě jdoucích řádcích, ve zdrojáku to bylo průzračně triviální.
Nepochybuji že Java guru by to dal do kupy, jde o to že se tohle s Javou občas děje a na serveru to má horší následky než typická chyba C/C++: segmentation fault.
Ja tomu nerozumim. Takze se jednalo o prasackou aplikaci?
-
Ja tomu nerozumim. Takze se jednalo o prasackou aplikaci?
Už jsem psal 2x že nejednalo. Nejde tak ani o řešení chyby, jako že se to občas děje a to více lidem.
-
Ja tomu nerozumim. Takze se jednalo o prasackou aplikaci?
Už jsem psal 2x že nejednalo. Nejde tak ani o řešení chyby, jako že se to občas děje a to více lidem.
Napsal, ale nevysvetlil. Nechapu, co bylo pruzracne trivialni. Objeveni memory leaku? Program sam o sobe? Delal jsi profiling, nebo analyzu heapu? Ja uz jsem par memory leaku v jave resil a pokazde se jednalo o chybu programatora.
-
Mam to chapat tak, ze aplikace napsana podle specifikace se chova jinak kvuli chybam v Oracle/OpenJDK/IBM JDK atd.? To uz je podle toho co vim, hodne minimalizovano...
Sotva, specifikaci javy nedodrzuje ani javac z JDK 7. Reporty tam mame roky a nikdo to neresi a resit v jdk 7 nebude. To je stejny jako v Oracle DB, tak vam klidne potvrdi ze JDBC driveru je chyba ale MOZNA to budou resit v dalsi major verzi.
-
Dakujem za postrehy, rad by som si to teda zhrnul alebo zopakoval to co bolo povedane aby som si z toho odniesol nieco do praktickeho zivota a neimplementoval blbosti
Klady:
1) Relativne rychly vyvoj a refaktorizacia v modernych IDE typu Idea alebo Eclipse ci Netbeans
2) "write once run everywhere" (ked sa chce, da sa toho rozumne dosiahnut)
3) Java je viac vhodna na serverove aplikacie alebo demony
4) Toto tu nepadlo ale podla mna velmi vyspely ekosystem nastrojov ako Maven Ant, neskutocne mnozstvo kniznic na vsetko mozne ... Java je myslim v tomto ekosysteme a previazanosti asi najdalej, nech to slovo uz znamena cokolvek ... Mne sa pacia iniciativy ako JCP a podobne ...
Zapory:
1) Na systemove utility / programy je nevhodna pretoze samotny start JVM a inicializacia by trvala dlhsie ako samostatne vykonanie programu.
ano s tymto suhlasim, aj ked ... neviem, ide o to, co sa programuje, napr. ked nakodim nejaky konzolu, tak sa to spusti len raz a je tam potom nejaky REPL ...
2) JVM nevracia aktualne nevyuzitu pamat systemu a tym padom casto mava alokovane viac, nez je treba
3) Musel by som pisat pripadne nejaky wrapper skript, ktory obali java -jar xyz.jar a podobne do jednoducheho CLI prikazu a nastavi classpath a environment
nevidim zasadny problem
4) Java je na malu utilitu velmi "ukecana"
5) Java je zlozitejsia na nasadenie oproti jazykom ako Python / Ruby kde staci len interpreter a skript = jeden subor
myslim ze to je len otazka dalsej hodiny na napisanie toho skriptu teda velmi tento argument neprijimam
6) Je nenazrana na pamat
imho tu myslim ze to je prasacky naprogramovane ale ano, Java je proste uz z povahy veci viac narocna na pamat, to je proste fakt
7) Bezpecnost Javy je biedna az nulova
to je trochu demagogicke, jeden diskutujuci povedal, ze tento problem sa tyka vacsinou klientov
8) Treba to nakodit v IDE a simple editor casto nestaci
co je otazka preferencii, osobne to vidim ako vyhodu)
Inak na napadlo, ze co sa tyka velkosti JVM a pomaleho startu, ved na nejaky subset vlastnosti mi staci aj nejaka osekana verzia ako napriklad Java SE Embedded
http://www.oracle.com/technetwork/java/embedded/downloads/javase/index.html
"Java SE embedded is based on desktop Java Platform, Standard Edition.[1] It is designed to be used on systems with at least 32 MB of RAM, and can work on Linux ARM, x86, or Power Architecture, and Windows XP and Windows XP Embedded architectures."
Takze velmi nechapem argument velkosti instalacie a pamatovej nenazranosti ked to dokaze bezat na embedded zariadeniach. A nad Java SE embedded si uz pridam akekolvek jarka chcem a som tam kde som s Java SE ale mam "stripped down" instalaciu. Alebo sa mylim?
http://www.oracle.com/technetwork/java/embedded/resources/se-embeddocs/index.html#sysreqs
Dam ruku do ohna ze to umoznuje networking a podobne ...
-
Bezpečnost aplikací je dneska naprosto otřesná, protože kdysi se často nechala přetéct proměnná a kód se nalepil za to (dost složité a navíc nespolehlivé). V mých binárkách třeba mnoho exploitů vůbec nejelo... i když chyba tam byla.
Dneska už se používá idiotský návrh aplikací, kdy programátor naprosto nechápe co dělá a bohužel nejčastěji jsou to progamátoři vyšších jazyků (Java například). Jazyk samotný s tím, ale nemá co dělat.
Další zádrhel je používání frameworků - dost často patlá taky někdo kdo může nadělat strašný chyby a vaše aplikace za to chudák ani nemůže.
JAVA je skvělá tam, kde je nutná multiplatformnost. Na core aplikace se spíš nehodí (ty mají být minimalistické a rychlé). Na mnoho dalších věcí jako analytika apod je fajn (tam kde nejde o rychlost náběhu a spotřebu paměti).
Ovšem důležitá věc je, že žádný programovací jazyk není špatný - ty striktnější jsou vhodnější pro patlaly (aby je to trošku skříplo).
Nejlepší je zajistit maximální granularitu a tvořit vyloženě servisně (všechno prostě dekomponovat na mini díly a ty můžou používat jaký jazyk je zrovna na danou komponentu nejvhodnější).
-
Klady:
1) Relativne rychly vyvoj a refaktorizacia v modernych IDE typu Idea alebo Eclipse ci Netbeans
Tak to je ale duvod, proc jsou na serveru shell skripty a ne Java. IDE na serveru nemas a pri kazde uprave stahovat a editovat jinde, a posilat zpet, se rychle zaji.
2) "write once run everywhere" (ked sa chce, da sa toho rozumne dosiahnut)
To je duvod, proc jsou systemove veci v C. Aby si mohl napsat neco jednou a poustet to vsude, musi byt nejprve v jazyce nizsim napsan system-specific kod a nad tim nejake jednotne API pro vyssi jazyk. Systemove veci v C jednoduse budou drive, nez je budes moci zbytecne obalit Javou a mimochodem zdedit vsechny jejich pripadne nedostatky.
-
Napr. Scala (http://cs.wikipedia.org/wiki/Scala_%28programovac%C3%AD_jazyk%29) (jazyk na JVM) podporuje skripty (i cachovani zkompilovanych trid), takze neni potreba balit do jaru. Proste jeden soubor se zdrojovym kodem a ten se normalne pusti.
Co ctu, tak se tu dost kritizuje doba startu JVM. Osobne jsem nezkusil, ale projekt Nailgun (http://martiansoftware.com/nailgun/index.html) vypada hodne nadejne:
$ time java com.martiansoftware.nailgun.examples.HelloWorld Hello, world!
real 0m0.132s
user 0m0.080s
sys 0m0.010s
$ time ./ng com.martiansoftware.nailgun.examples.HelloWorld Hello, world!
real 0m0.004s
user 0m0.000s
sys 0m0.000s
Tak to je ale duvod, proc jsou na serveru shell skripty a ne Java. IDE na serveru nemas a pri kazde uprave stahovat a editovat jinde, a posilat zpet, se rychle zaji.
Neznam podrobnosti, ale cetl jsem, ze napr. pomoci Eclim-u lze udelat z Vimu celkem schopne IDE pro Javu (nejaka ukazka je i na youtube - tu (http://youtu.be/cYBIduIHrTY?t=45s)).
Osobne si myslim, ze shell skripty jsou hlavne zazite, nez ze by byly opravdu o tolik rychlejsi (eh, takovy Bash pri operacich na polich si myslim nebude zadny rychlik) nebo vhodnejsi nez treba prave ta Scala ci Python.
-
Pokud zabíháme až do takovýchto věcí, tak v Emacsu se dá editovat Clojure a Java celkem slušně. Neznám sice moc lidí, kteří by měli emacs na serveru, ale zcela určitě to není takový problém jako tam mít třeba IntelliJ Ideu.
Nailgun má nevýhodu, že má stále spuštěný proces a okupuje paměť. Své využití to má (např. kompilace na pozadí), ale podle mě se nehodí na systémové utilitky.
-
Opravdu je nutne mit IDE na servru, nestaci si jen nasdilet adresar se skriptem a pouzivat IDE z lokalniho stroje?
-
Napr. Scala (http://cs.wikipedia.org/wiki/Scala_%28programovac%C3%AD_jazyk%29) (jazyk na JVM) podporuje skripty (i cachovani zkompilovanych trid), takze neni potreba balit do jaru. Proste jeden soubor se zdrojovym kodem a ten se normalne pusti.
Už jsem tady zmiňoval Groovy, které platí totéž a je pro scriptováni IMHO i vhodnější (jednak kvůli Grab, jak zmiňoval Lenin, jednak kvůli tomu že je to hodně inspirováno Ruby). Ale to už je fakt otázka osobní preference...
Ten projekt Nailgun není první takový, zatím se ale žádný bohužel neuchytil.
Nezapomínejme ale na jeden důležitý faktor - mezi správci serverů je velmi rozšířená antipatie k Javě (nechci začínat flame o tom zda oprávněně nebo neoprávněně, i když si nedělám iluze že by nevznikl). Horší je, že často dochází k náboženským sporům o boční témata, typicky XML.
-
Co ctu, tak se tu dost kritizuje doba startu JVM. Osobne jsem nezkusil, ale projekt Nailgun (http://martiansoftware.com/nailgun/index.html) vypada hodne nadejne:
$ time java com.martiansoftware.nailgun.examples.HelloWorld Hello, world!
real 0m0.132s
user 0m0.080s
sys 0m0.010s
$ time ./ng com.martiansoftware.nailgun.examples.HelloWorld Hello, world!
real 0m0.004s
user 0m0.000s
sys 0m0.000s
Tak to je ale duvod, proc jsou na serveru shell skripty a ne Java. IDE na serveru nemas a pri kazde uprave stahovat a editovat jinde, a posilat zpet, se rychle zaji.
Neznam podrobnosti, ale cetl jsem, ze napr. pomoci Eclim-u lze udelat z Vimu celkem schopne IDE pro Javu (nejaka ukazka je i na youtube - tu (http://youtu.be/cYBIduIHrTY?t=45s)).
Diky za toto, je to hezky vyprasene svinsto, mrknu na to, good tip!
Zaznely tu nejake nazory typu to je strasne, kdyz pamet leze nahoru, z procesoru se kouri apod. S tim jsem se se taky setkal. Osobne musim rict, ze na svoji vyvojovy masine mi 8GB taky nestaci no(2 instance weblogicu admin a managed server Oracle SOA, oracle xe, sql developer, firefox(ten zere taky jak svin), jdeveloper, soapui, pripadne loadui, par word, excel dokumentu a je to v pici...ale 16GB mi v teto dobe dostacuje a vse mam svizne, muzu rict, ze proste na gentoo je start vseho rychlejsi, ale nesrovnavame tady L vs W.
Zpatky ale k puvodnimu nametu, proc nepsat systemove aplikace pro linux v jave? Netusim, vlastne je to docela dobry napad ;-). Chapu, ze nejhorsi je tady zrejme problem se startem prikazu, v tom pripade jsou tady stale nativni kompilatory pro javu.
GCJ http://gcc.gnu.org/java/ (http://gcc.gnu.org/java/) uz se asi nerozjede, ale stale podpodporuje verzi javy, ve ktere lze drtivou vetsinu stavajiciho setu unix tools prepsat(doufam, ze se nepletu haha).
Nasledne existuji i komercni nativni kompilatory, na kterych se aktivne pracuje:
Excelsior JET http://www.excelsior-usa.com/jet.html (http://www.excelsior-usa.com/jet.html)
Dalsi treba JNC ale ten je taky uz v kelu http://jnc.mtsystems.ch/download.html (http://jnc.mtsystems.ch/download.html)
Nicmene tim bychom dostali tooly napsane v Jave a zkompilovane do nativniho kodu, coz je samo o sobe prece hezke, napsal jsem si kod a muzu se rozhodnout, jestli ho necham spoustet ve virtualnim prostredi nebo v nativnim rezimu.
Pred chvili zde zmineny nailgun se mi opravdu libi nicmene muze trpet tim, ze ta masina se casem opravdu zasvini a command LS se pres implementaci C posle na server(ten bezi lokalne haha, ale bude zajebany, takze to skonci exception, nebo timeout). To jen tak ciste hypoteticky. Tento neduh se snazi resit dalsi projekt vedle nailgun jmenem DIRT https://github.com/flatland/drip (https://github.com/flatland/drip)
Prave DIRTu bych sveril systemove commandy pokud bych chtel start "podobny" nativnimu bloku.
No a kdyz uz se bavime primarne o nixove tooly, pak to take neni nova myslenka a zakladni set hlavne textovych util je implementovan v projektu unix4j at http://code.google.com/p/unix4j/ (http://code.google.com/p/unix4j/)
Ladik
-
Dneska už se používá idiotský návrh aplikací, kdy programátor naprosto nechápe co dělá a bohužel nejčastěji jsou to progamátoři vyšších jazyků (Java například).
souhlas. Stejne je zajimave, ze vznikne neco plne funkcniho, ackoli stvoritel naprosto nechapal, co dela :-) Treba to takhle bylo i s nasim svetem a bohem, ale to je asi do diskuze na cirkev.cz haha
Jazyk samotný s tím, ale nemá co dělat.
nesouhlas. vsechno souvisi se vsim.
Další zádrhel je používání frameworků - dost často patlá taky někdo kdo může nadělat strašný chyby a vaše aplikace za to chudák ani nemůže.
tak tohle je pro me nejvetsi problem! Vybavil jsi mi dobu, kdyz jsem jeste vyvijel ve Skodovce linku montaze na plc gefanucu. Linka trpela velkym mnozstvim jednoduse opravitelnych zavad, ktere postupnymi opravami mizely, nicmene se zacaly rodit potomci binarniho sexu okurence starych chyb a jejich osetreni. Byly to chyby, ktere nastavaly daleko mene casteji, ale bylo potreba daleko vice casu pro jejich napravu. Tento stav se stale prohluboval se stabilizaci (subjektivni) systemu v case. No jestlize tento efekt spojim jeste s vrstvenim, tak je to rodiste opravdu zajimavych stavu ;D :P
-
Opravdu je nutne mit IDE na servru, nestaci si jen nasdilet adresar se skriptem a pouzivat IDE z lokalniho stroje?
vynikajuci napad
-
Kazdopadne,
skusil som si startup casy Javy a Java SE embedded a aj to je celkom zaujimave:
root@arq:~/test # cat Hello.java
public class Hello {
public static void main(String[] args) {
System.out.println("hello world");
}
}
skompilujem s javac a potom
root@arq:~/test # time java Hello
hello world
0.010u 0.031s 0:00.12 33.3% 18+638k 0+0io 0pf+0w
a s Java SE Embedded:
root@arq:~/test # time ../ejre1.7.0_45/bin/java Hello
hello world
0.000u 0.010s 0:00.09 11.1% 4+132k 0+0io 0pf+0w
Tu uz jednoducho argument "startuje to pomaly" absolutne neobstoji ...
Instalacia Java SE embedded ma velkost:
root@arq:~ # du -shc ejre1.7.0_45/
43M ejre1.7.0_45/
43M total
V dobe terabajtovych diskovych poli je vam luto za 43 mega? :) Kolko zaberie taka instalacia Ruby alebo Pythonu?
Verzie Javy:
root@arq:~/test # java -version
java version "1.7.0_45"
Java(TM) SE Embedded Runtime Environment (build 1.7.0_45-b15, headless)
Java HotSpot(TM) Embedded Client VM (build 24.45-b08, mixed mode)
root@arq:~/test # ../ejre1.7.0_45/bin/java -version
java version "1.7.0_45"
Java(TM) SE Embedded Runtime Environment (build 1.7.0_45-b15, headless)
Java HotSpot(TM) Embedded Client VM (build 24.45-b08, mixed mode)
Skusal som to na FreeBSD 9-STABLE vo virtualboxe
-
Ale no :D
pomylil som sa ...
kto je pozorny vidi, ze som mal zle nastaveny alias takze som sice spustil "java" ale $JAVA_HOME som mal nastavene na tu Java SE Embedded takze mi meralo dva krat to iste ... v tom druhom pripade sa to asi niekde nacachovalo
Takze repete a teraz spravne :)
Normalna Java
root@arq:~/test # java -version
java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) Server VM (build 23.21-b01, mixed mode)
Java SE embedded
root@arq:~/test # ../ejre1.7.0_45/bin/java -version
java version "1.7.0_45"
Java(TM) SE Embedded Runtime Environment (build 1.7.0_45-b15, headless)
Java HotSpot(TM) Embedded Client VM (build 24.45-b08, mixed mode)
root@arq:~/test # time java Hello
hello world
0.069u 0.084s 0:00.26 53.8% 372+1799k 0+0io 0pf+0w
root@arq:~/test # time ../ejre1.7.0_45/bin/java Hello
hello world
0.000u 0.012s 0:00.09 11.1% 4+264k 0+0io 0pf+0w
Wau :D To je celkom sila :D
este jedno porovnanie
root@arq:~/test # time java Hello
hello world
0.072u 0.056s 0:00.23 52.1% 326+1617k 0+0io 0pf+0w
root@arq:~/test # time ../ejre1.7.0_45/bin/java Hello
hello world
0.000u 0.012s 0:00.10 10.0% 4+264k 0+0io 0pf+0w
root@arq:~/test #
-
A super, java embedded, na tu jsem uplne zapomnel, very good point!!!
No ja jsem si udelal nejaka srovnani ohledne volani napr nejakeho unix commandu, jeho reimplementace v jave volanim jak z on demand JVM, tak nacachovane JVM s temito vysledky:
Soubor 280MB
Java implementace pouziti unix4j:
/*
* To change this license header, choose License Headers in Project Properties.
* To change this template file, choose Tools | Templates
* and open the template in the editor.
*/
package testingunixutilsjava;
import java.io.File;
import org.unix4j.Unix4j;
/**
*
* @author zANGETSu
*/
public class TestingUnixUtilsJava {
/**
* @param args the command line arguments
*/
public static void main(String[] args) {
Unix4j.cat("/home/zangetsu/test.txt").grep("TecMint.com").sort().toStdOut();
}
}
Linux util
root@acheron:/media/sf_Dev/rep/trunk/wat/TestingUnixUtilsJava/dist#time cat test.txt | grep "TecMint.com" | sort
real 0m11.798s
user 0m0.128s
sys 0m1.084s
Standard JVM
root@acheron:/media/sf_Dev/rep/trunk/wat/TestingUnixUtilsJava/dist#time java -jar TestingUnixUtilsJava/dist/TestingUnixUtilsJava.jar
real 0m18.507s
user 0m8.161s
sys 0m0.208s
Drip
root@acheron:/media/sf_Dev/rep/trunk/wat/TestingUnixUtilsJava/dist#/root/bin/drip -cp TestingUnixUtilsJava.jar testingunixutilsjava.TestingUnixUtilsJava
real 0m18.395s
user 0m0.016s
sys 0m0.044s
Jak vidno, tak to spise vypada, ze bude problem ve vlastni implementaci utilit. Jednoduse javova implementace cat, grep a sort dohromady v tomto pripade v jave neni tak vykonna jako original, coz jsem cekal. No zmensim proto soubor na nula cela nula nic, takze uvidim vysledek vlastniho startu:
Linux util
real 0m0.051s
user 0m0.000s
sys 0m0.004s
opakovane:
real 0m0.003s
user 0m0.000s
sys 0m0.000s
Standard JVM:
real 0m0.371s
user 0m0.244s
sys 0m0.088s
opakovane:
real 0m0.382s
user 0m0.272s
sys 0m0.072s
Drip
Zde provedu test na bezici procesy, jelikoz se drip pri prvnich testech urcite demonizoval:
ps -ef |grep drip
root 9031 1 0 18:42 pts/1 00:00:00 /root/drip/bin/drip_daemon /usr/bin/java -Djava.awt.headless=true -classpath /root/drip/bin/../drip.jar:TestingUnixUtilsJava.jar org.flatland.drip.Main testingunixutilsjava.TestingUnixUtilsJava /root/.drip/0.2.3/ebd029dbc177dca5f783f1de6842f7d8edfadfa4/9011-1
root 9034 9031 0 18:42 ? 00:00:00 /usr/bin/java -Djava.awt.headless=true -classpath /root/drip/bin/../drip.jar:TestingUnixUtilsJava.jar org.flatland.drip.Main testingunixutilsjava.TestingUnixUtilsJava /root/.drip/0.2.3/ebd029dbc177dca5f783f1de6842f7d8edfadfa4/9011-1
root 9175 3732 0 18:45 pts/1 00:00:00 grep drip
# kill -n 9 9031 9034
Nyni predpokladam, ze start pres drip bude dokonce mozna o trochu horsi nez standardni JVM, jelikoz je tam nejaky svinstvo okolo, musi se vytvorit znovu deamon apod. Uvidim:
real 0m0.475s
user 0m0.260s
sys 0m0.080s
a opakovane:
real 0m0.463s
user 0m0.008s
sys 0m0.008s
real 0m0.470s
user 0m0.004s
sys 0m0.012s
No je videt, ze exekuce na urovni kernelu i mimo-kernel trvala opravdu velmi male casove okamziky. Co uz tu neni videt a proto cislo real zustava stale vysoke, je exekuce na urovni jineho procesu, kde je rozjeta JVM z minuleho runu. Rekl bych, ze jsem nezvolil nejlepsi priklad. Umim si predstavit, ze zde k vyraznemu narustu vykonu dojde az napr. pokud pouzivame velky set classpath. Takhle se to rozhodne nevyplati.
Jinak exekuce probihala na virtualnim debianu.
-
skusal som este kombinaciu drip + embedded java se a prekvapivo sa to este nezrychli ale spomali tj. samotne spustenie javy se embedded je rychlesie ako jej spustenie pomocou drip-u. zda sa ale ze u drip + java se normalna sa to zrychli celkom dost
-
Zkusim to dnes jeste s hutnejsi aplikaci z pohledu velikosti classpath, tam ocekavam realny "brutalni" narust.
-
Ta Java SE Embedded je zajímavá, věděl jsem, že existuje pro ARM platformy, ale nenapadlo mne, že je i pro x86. Ale koukám, že pro amd64 není... Jinak myslím, že je to novinka, v době Javy 6 nic takového nebylo.
K tomu porovnání by ještě bylo dobré porovnat třeba -client a -server mód.
Bůhví, jak ta implementace unixových utilit v Javě vypadá, předpokládám, že se tam používají streamy nebo dokonce převod na text a žádné NIO.
-
No zavisi..napr. mna zarazilo, ze eclipse prehlada vsetky subory projektu o dost rychlejsie ako totalcommander v c++ (neviem o tom, ze by som mal index..v tom pripade by to snad bolo ihned).
Ohladom otazky - aku by malo vyhodu? Navyse GC jazyky su dost nepriatelske voci tradicnemu modelu virtualnej pamate. Ono je to skor optimalizovane na to, ze sa to rozboptna na nejakom vyhradenom serveri a tam si to zije. Predstav si, ze ti tam bezi nejaky demon ktory raz za hodinu nieco spravi a zabera si 100M pamate a kedze GC bezi dost casto (inak by ti dosiel dost rychlo heap), tak sa ten proces neda ani odswapovat.
-
C třeba proto, že
1. Protože C je v ekosystému Linuxu doma
2. Protože ty programy v C byly napsané v době, kdy Java neexistovala, nešla použít vůbec nebo byla z jiných důvodů nevhodná
3. Protože spousta lidí (v této oblasti zvlášť) Javu nemusí
Python třeba proto, že
1. Na napsání Hello world stačí jeden řádek (zjednodušeně řečeno)
2. Má přímo v základu prakticky všechno potřebné pro systémové programování (a co nemá, dá se snadno dohonit třeba pomocí ctypes)
3. Má příčetnou práci s celými čísly (nepotřebuje několik různých typů a nemusí pro ty rozsáhlejší obcházet nedostatek návrhu pro obskurními metodami)
Takže Javu pro nové rozsáhlé systémy klidně, ale pro rychlé vyřešení administrativních úkolů moc smyslu nedává. Pro programy v rozsahu v řádu max. (deseti)tisíců řádků má oproti "skriptovacím" jazykům typu Perl, Python či Ruby prakticky samé nevýhody.
-
co mate furt s tou pamatou? preco by to malo zrat 100 mega? ved si to nastavim, kolko to ma zrat maximalne a dovi dopo.
A aj ked by to malo zrat 100 mega, a co? ved mam server (nemam ho, ale to len pre priklad) ktory ma 8 giga ramky, nastavim si ze nejaky demon nech zaberie maximalne nejakych 100 mega. Kde je akoze problem?
Zoberme si ten JBoss AS / Wildfly, jeho defaultne nastavenie ohladom pamati je:
-server -XX:+UseCompressedOops -XX:+TieredCompilation -Xms64m -Xmx512m -XX:MaxPermSize=256m
Co znamena ze
Xms - nastartuje to server so 64 mega a maximalne to moze zrat 512 mega. Podotykam ze toto je "tovarenske" nastavenie.
nastavim to na
-Xms32m -Xmx128m -XX:MaxPermSize=64m
Spustim to a ide to, ziadny problem. Bude to zrat max 128 mega. to je tiez stale take strasne? Na Java EE aplikacny server so vsetkymi ficurami?
Ja nehovorim, ze to bude zvladat nejaku extra zataz. Nie, nebude. Lenze ja ani nepotrebujem, aby to nejaku extra zataz zvladalo. Schvalne som skusil este to nove nastavenie osekat na polovicu:
-Xms16m -Xmx64m -XX:MaxPermSize=32m
pozriem do jvisualvm, drzi sa to celkom v pohode, cuduj sa svete, stale to ide. vypol som subsystemy, ktore nebolo treba, len aby to zralo "menej". Je to len pre osobne potreby, nejaky demon si tam moze bublat kolko chce ...
Inak,
skusal som dnes Weld kontajner skrz weld-se s Java SE takym sposobom, ze som si spravil simple maven projekt s weld-se ako dependency a spravil som si uplne trivialnu hello world aplikaciu. Zabalil som to do jedneho jarka s maven-assembly-plugin so vsetkymi dependecies (tzv. uber jar) a zozralo to neuveritelne tri mega. To asi neprezijem.
Taktiez som skusal, kolko bude trvat, kym to spustim ako command zo shellu. Startuje sa cely CDI container pri kazdom spusteni jaru takze to trvalo nejake 3-4 sekundy. Zobral som na to ten nailgun co sa tu spominal vyssie. Nastartoval som ten nailgun server, spustil som cez nailgun klienta main triedu toho jarka, start trval (tj. start CDI kontajneru + vykonanie hello world) ... a teraz sa podrzme ... 0.3 sekundy! nula cela tri sekundy. To je pomale?
Mam za to dependency injection podla JSR-299 v konzolovych aplikaciach
When executing Weld in the SE environment the following features of Weld are available:
POJOs (no EJBs)
Typesafe Dependency Injection
Application and Dependent Contexts
Qualifiers
Stereotypes
Typesafe Event Model
potom tam mam sa mi zda este interceptory a dekoratory, taktiez na to mozem pouzit JPA, to sa mi zda tiez funguje standalone, ale nebudem tam moc pouzivat transakcie, to fakt ozeliem ...
Vsetko to je len zalezitost nastavenia a konfiguracie, ja v tom nevidim ziadny problem fakt ...
Absolutne nic nebrani tomu pouzivat javu na servery aj v konzolovych aplikaciach. Aj ked by sa nepouzil Weld, stale to je nailgun a ine DI frameworky ako Guice a podobne ...
-
Ja ti to nevyhovaram, len ti pisem preco by som nerobil taketo utility v jave. Navyse ty na to hladis, ze mas 8G pre seba, ale dnes sa to prerozdeli medzi virtualky, najlepsie ani bajt navyse... Sice hw je lacny, ale zjavne si este nemal docinenia s managmentom..
-
no, ja si zkusim ve virtualu ten Jnode schvalne a zkusim load java aplikaci v nem.
-
Argument, že je paměti hodně používají hlavně lidé kteří neřeší nic zásadního. Je to stejný případ, kdy mi známý říkal (proč řešíš kolik virtuální stroj zabírá - vždyť máme terabajtový disky). Dokud se mu to nezhroutilo! Pak jsem slyšel jen mumlání o tom, jak dlouho bude trvat těch pár terabajtů dostat z jednoho místa (ze zálohy) na druhé.
Pokud chci provozovat celý ekosystém služeb, rozhodně není jedno kolik paměti která zabírá. Optimalizací se dá dostat se jednou službou na pár MB RAM a nebo neoptimalizovanou na pár GB RAM a on je to obrovský rozdíl.
-
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.
CDI v Java SE sa da pouzivat uz pomaly desat rokov (Spring) ....