Proč je Java špatná na server?

[Lenin POWER!]

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.

[Reklama]

[zzxzxzx]

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

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 ...

[Jan Forman]

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ší).

[Nobody]

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.

[noef]

Napr. Scala (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 vypada hodne nadejne:

Kód: [Vybrat]

$ 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).

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.

[Reklama]

[eMko]

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.

[noef]

Opravdu je nutne mit IDE na servru, nestaci si jen nasdilet adresar se skriptem a pouzivat IDE z lokalniho stroje?

[podlesh]

Napr. Scala (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.

[Ladislav Zitka]

Co ctu, tak se tu dost kritizuje doba startu JVM. Osobne jsem nezkusil, ale projekt Nailgun vypada hodne nadejne:

Kód: [Vybrat]

$ 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).

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/ 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
Dalsi treba JNC ale ten je taky uz v kelu 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
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/

Ladik

[Ladislav Zitka]

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 

[zzxzxzx]

Opravdu je nutne mit IDE na servru, nestaci si jen nasdilet adresar se skriptem a pouzivat IDE z lokalniho stroje?

vynikajuci napad

[zzxzxzx]

Kazdopadne,

skusil som si startup casy Javy a Java SE embedded a aj to je celkom zaujimave:

Kód: [Vybrat]

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

Kód: [Vybrat]

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:

Kód: [Vybrat]

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:

Kód: [Vybrat]

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:

Kód: [Vybrat]

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)


Kód: [Vybrat]

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

[zzxzxzx]

Ale no

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

Kód: [Vybrat]

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

Kód: [Vybrat]

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)


Kód: [Vybrat]

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 To je celkom sila

este jedno porovnanie

Kód: [Vybrat]

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 #


[Ladislav Zitka]

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:

Kód: [Vybrat]

/*
 * 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

Kód: [Vybrat]

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

Kód: [Vybrat]

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

Kód: [Vybrat]

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:

Kód: [Vybrat]

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.

[zzxzxzx]

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