Programy v Jave a pachatele skriptu ktere ji pousti

21.2.2007 23:37 | Přečteno: 1785× | Unix

Programky v Jave se nespousti zrovna jednoduse, pokud nejde o neco co se deployne do nejakyho uz beziciho serveru, tak je vetsinou potreba predat haldu parametru (classpath, parametry jvm, parametry prostredi (napr. http. proxy), a pak to sileny jmeno tridy kterou spustit, plus samozrejme parametry programu.

Vetsina lidi ma nastesti dost soudnosti, ze to nenecha na uzivateli, ale snazi se spusteni nejak "zabalit", vetsinou do skriptu. Vynecham MS "bataky", vetsinou se s nima nemusim trapit. S cim se ale casto trapim, jsou "shell skripty", teda povetsinou pokusy o shell skripty, nemuzu ocekavat ze clovek co dela v jave umi automaticky uzasne elegantne skriptovat.

Co me ale prekvapilo, je ze i v velky firme, ktera se zivi prodavanim javovejch programu je hodne velmi neefektivnich skriptu, ktere dovedou kooperaci nekolika javovych programu krasne zneefetivnit. A nejde jen o neefektivitu, skripty trpi hodne nekonzistenci - jednou jsou vystupy ponechany, jindy jsou poctive vsechny vystupy presmerovany do logsouboru, nekdy jsou namichany vsechny vystupy dohromady, nekdy silene oddelene... Nektere skripty po svem skonceni vypisi aktivne kam logovaly, ale co vlastne zalogovaly si musite najit v souboru, jine zase nikdy nevypisi nic na konzoli, ale jen do "tajneho" souboru, jehoz jmeno je nekde ve skriptu... Dokonce jsem se setkal s tak aktivnim skriptem, ktery zachytaval do souboru std. vystup, ale std error poctive posilal do /dev/null. Asi uhodnete, ze prave uzasna laditelnost toho posledne zmineneho skriptu me "inspirovala" k napsani tohoto textu.

Ocekaval jsem ze ve velky firme bude alespon nejaka kvalita. Bohuzel, spadly mi ruzovy brejle, kdyz vidim kvalitu kodu v jave, nemuzu ocekavat kvalitni skripty, ze. Navic, hodne Java programatoru ma jako svuj hlavni OS neco od MS (Java jim paradoxne umoznila tvorit programy ktery pobezej i na unixech, a pritom muzou zustat ve windows, cimz je nenuti se neco o unixu naucit). To bohuzel vyjadruje i jejich skriptovaci schopnosti.

Takze pro ostatni - nedelejte chyby co delaj ostatni. Pokud mate uzasny program v jave, chcete ho spustit ze skriptu a neumite psat skripty, nebojte se to priznat a nechte si poradit od nekoho kdo to umi. Spatnej skript umi znicit i uzasnej program. A mate-li kolegy windowsaky, kteri s vami/pro vas tvori programy v jave, nenechte je skriptovat. Nebo jeste lip, najdete si cas a naucte je to.

Jake z toho vyplyva moralni ponauceni? Nestaci mit jenom "coding standard" pro javu (ten stejne nemame), neni od veci mit coding stadard i pro shell skripty...

P.S.Tento zapisek jsem puvodne napsal 13.11, ale nechal jsem ho "ulezet", abych si moh casem "upravit" svuj nazor na tuhle vec. Nazor jsem nezmenil, proto publikuju jak jsem zapsal puvodne

       

Komentáře

[anicka]

Nekdy mivam pocit, ze ocekavat od obvykleho javovskeho programatora, ze umi cokoliv, je prehnany pozadavek

[qk]

no to se mi zda trochu predpojaty, spousta java programatoru umi hodne, ale stejne jako u vseho kdyz se do toho vrhne nejaky lidovy "umelec" tak vysledek stoji za to, zalezi akorat na tom, jakej jazyk je u takovych lidi zrovna v mode a ted je to zrovna java a C#.

Jinak k tematu, psat na javovsky porgramy shellscripty neni zrovna vhodny, konkretne pro javu pouzivam anti build.xml, kterej funguje vyborne a staci mu dat ant run (pripadne jinak nadefinovany prikaz pro spusteni) a jede, ale samozrejme se k tomu da pouzit i klasicky makefile.

[zabza]

Jinak k tematu, psat na javovsky porgramy shellscripty neni zrovna vhodny, konkretne pro javu pouzivam anti build.xml, kterej funguje vyborne a staci mu dat ant run (pripadne jinak nadefinovany prikaz pro spusteni) a jede, ale samozrejme se k tomu da pouzit i klasicky makefile.

To jako ze kdyz si chci spustit vas program, musim si krome JRE a programu nainstalovat jeste ant nebo make? No mozna to nebylo zas tak "predpojaty"

[qk]

no vzhledem k tomu ze programy davam jako opensource, tak je to rozhodne lepsi (protoze to ridi i vse podstatne). Pokud bych je poskytoval jako zavreny, tak bych to resil jako uz tu bylo zmineno pres jar se spousteci tridou a pokud by byli specialni naroky na VM tak bych asi pouzil ten shell script, ale musim rict ze nechapu, proc bych mel zakaznika otravovat presmerovanim cehokoliv kamkoliv. Bud delam sam logy a resim to v jave nebo necham na zakaznikovi co udela s vypisem programu.

Ale stejne sem zastance ze je lepsi dat zdrojak, protoze z mezikodu se da stejne program sestavit zpatky a navic takhle muze dotycny optimalizovat pro svoji VM (napriklad kdyz ma 1.6, tak nemusi kompilovat se zpetnou kompatibilitou pro 1.5).

[zabza]

To je samozrejme prima, ze jsou vase programy opensource... Ale pro me to znamena, ze abych mohl vas program pouzivat, musi mi ho predzvykat nejaky spravce balicku (clovek, ne program ) v me distribuci a vytvorit z vasich uzasnych otevrenych zdrojaku a make-filu a ant-fajlu onen spousteci skript, kteremu se tak vehementne branite... A troufnu si odhadnout, ze nebudu sam

[qk]

No a ant neni zas tak tezky prezvykat, kdyz je tam napsany neco takovyho

 < target name="run" depends="dist">

      < java classname="cz.ive.IveExecutor" fork="true">

        < classpath> 

            < pathelement location="${dist}/demoworld.jar"/>

            < pathelement location="../ive_core/dist/ive_core.jar"/>

        < /classpath>

        < arg line="-w resources/cz/ive/resources/DemoWorld.xml"/>

      < /java>

   < /target>

to rika vse samo a dat to do shellscriptu je otazka deseti sekund.

[happy barney]

no to se mi zda trochu predpojaty

Nie je, to je štatistika ... (ano, Churchill)

Jinak k tematu, psat na javovsky porgramy shellscripty neni zrovna vhodny, konkretne pro javu pouzivam anti build.xml,

head -1 ant
#! /bin/sh

wc -l ant
326 ant

hmm, používa ant a pritom "neni zrovna vhodny"

[miro]

Nie je, to je štatistika ... (ano, Churchill)

Neverim ziadnej statistike, ktoru si sam nesfalsujem ... (ano, tiez Churchill ;)

[Vinicius]

To asi programatorum v Jave trochu krivdite. Ne vsichni delaji takovehle veci. Lepsi jsou ale programy, ktere vyzaduji velejednoduchy skript na spusteni.

Mel jsem jeden program s veleslozitym skriptem na spusteni. V tom skriptu byly veci patrici do konfiguracniho souboru, tolik promennych tam bylo, fuj. Musel jsem upravit CONFIG.SYS, aby se vsechny vesly (Win98, blahe pameti)

. Ale takovych programu je nastesti mensina.

[User682]

Ktera zena nema vetsinou nekdy prehnane pozadavky ?

Zadny programator nebude umet cokoli a ti v Novellu nebudou vyjimkou. Nekteri programatori budou umet teba i shell, GSS-API a log4j.

obvykly javovsky programator

bye gf

[elviin]

Java jim paradoxne umoznila tvorit programy ktery pobezej i na unixech, a pritom muzou zustat ve windows, cimz je nenuti se neco o unixu naucit.

Ja si myslim, ze obecne Java svym "vstricnym" api nenuti programatora poznat OS, tak jako napr. u C++. Nemuzu napsat, ze je to nevyhoda. Zalezi na kriteriich, na vahach ktere k nim priradime. Ale je to tak. Slovo paradoxne jsi zvolil dobre.

[Filip Jirsák]

Pokud píšete programy v Javě, pokud možno nepiště ani nepřenosné startovací skripty. vytvořte balík jar, který má ve svém manifestu uvedenu jak classpath tak spustitelnou třídu, a případné parametry programu načítejte ze souboru properties, jehož umístění dovolte změnit přes systémovou vlastnost. Takže pak na všech platformách, kde je JVM, půjde program spustit prostým

java -Dconfiguration=config.properties -jar aplikace.jar

Zvláštní je, že většina startovacích skriptů po různé magii nakonec skončí stejně tím, že spustí právě java -jar apliakce.jar, případně předá ještě nějaké parametry. Takže člověk může na startovací skript klidně zapomenout a pouštět program klasicky. Co někoho vede k složitému tvoření takového složitého skriptu, to je mi záhadou.

[Trained.Monkey]

Programy v jave se daji spousted docela dobre s timhle:

http://launch4j.sourceforge.net/

udela to nativni binarku do ktere zabali jar. Funguje na win, linux a macosx a solaris. Binarka je pouze o 20kb vetsi.

Pokud nenajde virtualni masinu zobrazi hlasku, nebo otevre stranku s downloadem.

[Ladicek]

Co, firmy. Vřele doporučuju spouštěcí skript Tomcatu. Ten drzoun předpokládá, že v systému nemůže běžet kocourů několik, a když ho spustíte z jeho vlastního adresáře (./startup.sh), odmění se vám tvrzením, že ólredy ranink

[Marek 'marx' Grác]

Tomcat 5 podporuje beh viacerych instancii na jednom stroji, akurat je potreba o kusok viac nastavovania. To, ze standardne sa spusti len raz je v linuxovych distribuciach uplne bezne. Ak vacsine ludi staci spustat /etc/init.d/tomcat start tak potom je to v poriadku. Komu to nestaci, tak pouziva napr. resource agents v RHEL.

[Jiří (BoodOk) Kadeřávek]

Může mi někdo zasvěcený sdělit, zda je to problém jen Javy nebo i jiných jazyků a co za tím stojí, resp. proč často potřebujete na spuštění programu v Jave spoustu parametru, když program v C prostě jen spustíte, max. se informujete přes --help?

[happy barney]

v C vytvoríte súbor spustiteľný na danej platforme, v jave len nejaký skript.
keby ľudia navrhujúci javu rozmýšľali, tak by v rámci hesla "write once run twice" preferovali Solaris na úkor Windows, a .class súborom nadefinovali začiatok #!/usr/bin/java\n

[Jiří (BoodOk) Kadeřávek]

Skript? Javac snad kompiluje do bytekódu JVM.

[happy barney]

ok, ak vám samotné slovo skript vadí, použijem výraz intepreter script. Nič iné to totiž nie je, len súbor inštrukcií pre interpreter.

[Jiří (BoodOk) Kadeřávek]

Ve vašem pojetí je samozřejmě skriptem i strojový kód a tudíž i normální spustitelný soubor.

[Filip Jirsák]

Pokud chcete předat programu v C nějaké parametry, máte dvě možnosti – proměnné prostředí nebo parametry na příkazové řádce. Java k tomuhle systému přidává systémové vlastnosti [system properties], které jsou obdobou proměnných prostředí, ale mají platnost pouze pro aktuálně spuštěný Java Virtual Machine. Pokud programátor podlehne snadnosti použití těchto systémových vlastností v aplikaci, a neumožní je nastavit v jednom konfiguračním souboru, může ta aplikace vyžadovat spoustu parametrů. To není problém jazyka nebo platformy, ale programátora.

Druhý a závažnější problém je to, zda ony startovací skripty jsou vůbec potřeba – v drtivé většině případů totiž nejsou. Každá aplikace by měla mít nějaké výchozí konfigurační volby (přímo v sobě), a pokud chci něco změnit, udělám to při spouštění příslušné aplikace:

java -Dx=y -Da=b-jar aplikace.jar

Až to budu psát do příkazové řádky po desáté, naštvu se, a dvouřádkový skript si na to napíšu sám. Skript distribuovaný autorem tomuhle nepomůže – ten zná zase pouze defaultní parametry.

Ty spouštěcí skripty navíc často dělají to, že zjišťují, kde je umístěna Java, různě se to pokouší uhodnout a testují výsledek atd. Přitom je obecně uznávanou dohodou nastavovat tohle do proměnné prostředí JAVA_HOME – a není nic snazšího než tuto proměnnou v Java aplikaci otestovat a pokud neexistuje, oznámit chybu. Druhá možnost je nastavení různých vlastností přímo JVM (např. velikost použitelné paměti), jenže to je zase otázka jednořádkového skriptu, ještě lépe větičky v dokumentaci.

Takže ony spouštěcí skripty jsou v drtivé případě případů zbytečné, často špatně napsané a psát je je spíš takový folklór pocházející z doby, kdy spousta lidí zřejmě měla nainstalovánu Javu ale neměla jí v $PATH, takže prosté java -jar aplikace.jar nefungovalo. Snad jediná Java aplikace, se kterou jsem se setkal, kde má spouštěcí "skript" opodstatnění, je eclipse. A to má stejně vazby přímo na operační systém (SWT) s "startovací skript" je realizován přímo jako binárka pro daný systém. Navíc konfigurační parametry si zase čte ze souboru, není potřeba psát kilometrovou příkazovou řádku.

Je to tedy problém těch, co ty zbytečné skripty píšou.

[happy barney]

btw, prečo java -jar aplikace.jar, keď môžete mať multiplatformný Bourne shell skript s názvom aplikace? (nevraviac o tom, že .jar je vlastne len knižnica ...)
čo sa týka parametrov, viem si predstaviť rozmýšlanie bežného javistu ...

# ls -ldtr *
java \
  -Dgnu.utils.ls.format=long \
  -Dgnu.utils.ls.expandDirectory=false \
  -Dgnu.utils.ls.orderBy=time \
  -Dgnu.utils.ls.reverseOrder=true \
  -jar /bin/ls.jar

(a to som ešte optimista, že používam aj vymenované hodnoty). Ako vravíte, o tomto sa v príručkách javy bohužiaľ nepíše.

[Jiří (BoodOk) Kadeřávek]

Chápu to dobře tak, že jak je ukecaná celá java, stejně tak je ukecané i spouštění aplikací v ní napsaných? A záleží na programátorovi zda se s tím zlozvykem dokáže porvat pro dobro uživatele? A že fakt, že javisti málo (nebo vůbec, ale to byl záměr Javy nevědět nic o systému) dbají na systémové prostředky se odráží i v tomto ohledu? Mohlo by vypadat na to, že útočím na programátory v Jave, ale tak to není, spíše mi jde o to, aby se, dovozuji-li dobře, o tomto nešvaru vědělo a snažilo se s tím něco dělat.

[happy barney]

nejde o nešvar javy, java je len pokus (s kladnou spätnou väzbou) o jeho riešenie .

[Filip Jirsák]

Java umožňuje číst parametry z příkazové řádky stejně jako C. Pokud se nějaký programátor rozhodne předávat parametry programu jiným způsobem, než je obvyklé, je to jeho problém – a může to udělat stejně v C, v Javě, i kdekoli jinde.

To, co se dělá v Javě předáním systémových vlastností (-Dněco=něco) se v C aplikacích nebo skriptech zpravidla řeší proměnnými prostředí a konfiguračními soubory. Takže třeba když Portage má konfiguraci v /etc/make.conf a pokud jí chcete při jednom spuštění upravit, můžete použít

USE="-kde" emerge -a cosi

v Javě by se spíš použilo

java -Duse=-kde -jar emerge.jar -a cosi

Můžete použít i proměnnou prostředí, jenže jsou operační systémy, kde nastavit proměnnou prostředí jen pro právě spouštěný příkaz nejde. Java zavedla systémové vlastnosti jako alternativu pro proměnné prostředí, která se bude chovat na všech platformách stejně. Použití systémových vlastností nebo proměnných prostředí místo parametrů programu je opravdu řídké (teď si nevzpomenu na žádný program, který by tohle dělal – příklad uvedený výše v diskuzi je možná první takové použití systémových vlastností, které jsem někde zaznamenal) a Java v tom není žádnou výjimkou. Takže popsaný nešvar vznikl v této diskuzi, s reálným světem nemá nic společného.

[Jiří (BoodOk) Kadeřávek]

OK, díky, už v tom mám jasněji.

[Filip Jirsák]

To už se pak dostáváme k otázkám, jaký je rozdíl mezi knihovnou a spustitelným programem, nebo mezi interpretem a procesorem.

A co třeba tohle?

GNU_UTILS_LS_FORMAT="long" \
GNU_UTILS_LS_EXPAND_DIRECTORY="false" \
GNU_UTILS_LS_ORDER_BY="time"\
GNU_UTILS_LS_REVERSE_ORDER="true \
ls *

[Jiří (BoodOk) Kadeřávek]

Myslím, že rozdělení výsledku programátora podle toho zda distribuuje skripty, bytekód nebo strojový kód je OK. Že se i ten skript nakonec stane strojovým kódem je zřejmé, avšak každý z těch přístupů má jisté výhody a úskalí. Nicméně, přistoupí-li široké publikum na tvrzení, že Java je scriptovací jazyk, přizpůsobím se.

[happy barney]

rozdiel je imho v tom, že tie propeties máte v jave prístupné takmer vždy, kdežto pre prístup ku cmd-line argumentom by jeden musel napísať a inicializovat singleton (tých cca 10%, ktorí to slovo pochopili), zvyšok by to predával ako argumenty (a ekvivalent pomenovaných parametrov v jave, hmm, v tutorialoch o tom nepíšu).

[Filip Jirsák]

Tedy úplně stejně, jako máte v C přístup k proměnným odkudkoli a k parametrům příkazové řádky jen z funkce main. A přesně to i odpovídá způsobům použití – systémové vlastnosti nebo proměnné prostředí používám k celkovému nastavení chování programu při každém běhu – kde má logovací soubor (to potřebuje vědět každá část programu), jaké má používat parametry TCP/IP spojení (proxy server, timeouty) atd. Naproti tomu parametry příkazového řádku určují co má teď program dělat – a to nemusí vědět každá část programu, naopak při startu je potřeba podle těchto parametrů rozhodnout, co a jak dál.

Představte si to na analogii s GUI – Soubor – Otevřít nebo Soubor – Tisk odpovídá program --open nebo program --print. Změna konfiguračních voleb v Nástroje – Možnosti apod. odpovídá změnám v proměnných prostředí nebo systémových proměnných.

[happy barney]

to je filozofická otázka, čo kam patrí. Osobne by som aj tie systémové vlastnosti dal prístupné iba z main. IMHO to, že sú prístupné odvšadiaľ znižuje znovupoužiteľnosť kódu (v jednej aplikácii i vo viacerých aplikáciach zároveň). Na druhej strane, ak sa o prístup stará interpreter, nemusí to vedieť naprogramovať programátor, a teda stačí zamestnať "lacných" drevorubačov.

[Filip Jirsák]

Java je postavená na tom, že používá to, co se již osvědčilo jinde. A přístup k proměnným prostředí odkudkoli je lety ověřená praxe Taky zapomínáte na to, že proměnné prostředí i systémové vlastnosti jde měnit i za běhu aplikace. Uvědomte si, co se systémovými vlastnostmi zpravidla nastavuje: defaultní locale, třída implementace SAX parseru, třída implementace XSLT transformeru atd. Nechtěl bych být nucen na začátku běhu programu si odchytit nastavené locale a pak jej propagovat do všech tříd aplikace…

[happy barney]

dobre, locale ako systémové nastavenie akceptujem. Všetko ostatné v príspevku vymenované je aplikačné nastavenie.

Výraz lety ověřená praxe znamená dlhotrvajúca chyba ? Podľa mňa by prístup k nastaveniu systému mali mať len privilegované entity. Inak to celé dopadne ako registry.

[happy barney]

btw, java je postavená na tom, že sa z nej vyhádzalo všetko, čo nutí používateľov premýšlať je to taký jazyk pre managerov. dobrý na výuku, slabý pre prax.

[miro]

Blbost, java je vyborna pre prax. Preco by sa v nej inak tolko pisalo?

[happy barney]

paneboze, to je tvrdenie, to ako keby ste napisal, ze skodovka je lepsie auto ako mercedes, pretoze ich tolko jazdi. co na tom, ze len vo vasom blizkom okoli, zanedbatelnom voci rozmerom vesmiru.

[miro]

Ak je skodovka dobra na presuvanie z miesta na miesto a naklady na prevadzku su nizke, tak je to dobre auto. Netvrdim, ze mercedes nie je dobry, tvrdim, ze skodovka je dobra...

Mimochodom, v jave sa nepise len v mojom okoli. To je navyse este rozdiel oproti skodovke.