Portál AbcLinuxu, 1. května 2025 08:30
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"
) 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
< target name="run" depends="dist">to rika vse samo a dat to do shellscriptu je otazka deseti sekund.
< 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>
no to se mi zda trochu predpojatyNie 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 anthmm, používa ant a pritom "neni zrovna vhodny"
Nie je, to je štatistika ... (ano, Churchill)Neverim ziadnej statistike, ktoru si sam nesfalsujem ... (ano, tiez Churchill ;)
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.
22.2.2007 07:49
elviin | skóre: 29
| blog: elviin
| Plzeň-Praha
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.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.jarZvláš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.
./startup.sh), odmění se vám tvrzením, že ólredy ranink
#!/usr/bin/java\n 
intepreter script. Nič iné to totiž nie je, len súbor inštrukcií pre interpreter.
java -Dx=y -Da=b-jar aplikace.jarAž 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.
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 ...)# 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.
.
-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 cosiv Javě by se spíš použilo
java -Duse=-kde -jar emerge.jar -a cosiMůž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.
GNU_UTILS_LS_FORMAT="long" \ GNU_UTILS_LS_EXPAND_DIRECTORY="false" \ GNU_UTILS_LS_ORDER_BY="time"\ GNU_UTILS_LS_REVERSE_ORDER="true \ ls *
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.
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.
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…
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.
je to taký jazyk pre managerov. dobrý na výuku, slabý pre prax.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.