Ant compile - z definice rozbité

18.5.2009 22:36 | Přečteno: 997× | Ani zbla

V Javě jsem zvyklý využívat dobře definovaných class souborů. Myslím tím, že je možné nahradit v nějakém programu jeden class soubor jiným, za předpokladu že mají stejné rozhraní. Ono totiž ty class soubory jsou takové hezky deoptimalizované, všechny špinavé triky (inlinování atd.) dělá JVM až za běhu.

Tato deoptimalizace má jednu velkou výjimku. Přišel jsem na to tak, že nefungoval "inkrementální" překlad v antu, tj. po zadání obligátního ant compile se program občas choval jinak než po ant rebuild.

Pokud máte třídu

public class Conf {
    public static final int DEBUG = 1;
}

tak třídy, které čtou konstantu DEBUG ji ve skutečnosti nečtou. Překladač do jejich těla s klidem vloží přímo literál, tedy jedničku. Takže když v Conf změníte hodnotu na DEBUG = 0 a znovu ji samu samotinkou přeložíte, změny se nepromítnou do jiných částí programu. Pomůže rebuild.

       

Komentáře

[petr_p]

A to je vlastnost Antu nebo javac?

[alblaho]

Javac kompiluje tak, že Ant není schopen přesně určit závislosti (on se dívá jenom na timestamp souboru).

[Filip Jirsák]

To je vlastnost javac od Sunu od verze 1.5. A je to zdokumentovaná funkce, všichni (hm, skoro všichni) o ní vědí a vědí, že release projektu se dělá jako čistý build, nikdy jako výsledek inkrementální kompilace. Inkrementální kompilace je jenom pomůcka pro zrychlení vývoje (a třeba takový elcipse kompilátor dělá i horší věci, klidně přeloží soubor se syntaktickou chybou a příslušnou metodu s chybou nahradí pouze vyhozením výjimky, kde je zpráva o tom, že tam je syntaktická chyba).

[alblaho]

Nikdo netvrdí, že to není zdokumentovaná vlastnost. Jenom jsem o tom nevěděl, to je celé. A o releasování projektu též nikdo nemluvil.

[mkoubik]

To jsi z toho vyvázl ještě dobře. Když podstrkuješ jiné .class soubory stejného názvu místo původních, aniž bys použil classloader, tak buď rád, že se ještě nesmažíš v pekle.

[alblaho]

Můžeš to rozvést? Já ale nedělám takové věci u živé běžící aplikace (to obecně fungovat nemůže), prostě upravím a spustím.

[mkoubik]

Pokud napíšeš Conf c = new Conf();, tak kompilátor předpokládá, že třída Conf bude vždy vypadat tak, jak je popsána v Conf.java a všemožné optimalizace na to nejspíš spoléhají. Kdežto když použiješ Conf c = Class.forName("Conf").newInstance();, tak by to mělo fungovat, protože se třída hledá až v runtimeu (stejně tak by parametrem forName mohla být proměnná).

Pokud tvrdíš, že třída Conf vypadá tak a tak a potom ji vyměníš, je to jako bys otevřel slinkovaný céčkový program v hexaeditoru a začal přepisovat části odpovídající nějakému objektu - taky radši použiješ shared object (.so).

Skrátka třídy, které se navzájem "jůzujou" je lepší považovat za "slinkované", v prvním případě používáš přímo třídu Conf, v druhém pouze třídu java.lang.Class, která se, předpokládám, měnit nebude.

A rada na závěr: na konfiguraci je XML.

[alblaho]

Conf bude vždy vypadat tak, jak je popsána v Conf.java a všemožné optimalizace na to nejspíš spoléhají.

Je právě otázka, jaké optimalizace se odehrají. Pokud je mi známo, je inlinování konstanty jediná výjimka, zbytek se děje až za běhu.

PS: v mém projektíku si z různých důvodů nemůžu konfiguraci v XML dovolit

[default]

PS: v mém projektíku si z různých důvodů nemůžu konfiguraci v XML dovolit

Tak použij -D parametry

[Ladicek]

Proměnné prostředí se občas hodí. Ale jinak kód jsou data a data jsou kód a konfigurace v kódu je úplně v pořádku, pokud nepotřebuje uživatel dynamické změny. (A pokud je potřebuje, stačí použít skriptovací jazyk )

[default]

I tak bych to řešil properties souborem na ClassPath. Kvůli jedný blbině nemusíš zbytečně rekompilovat…

[mkoubik]

pokud nepotřebuje uživatel dynamické změny

Což pravděpodobně potřebuje, když vyměňuje .class soubory. Teď nemyslím konkrétně tenhle případ - zapínání/vypínání debugování se takhle řešit dá, ale jak už tu zaznělo, je potřeba před produkčním nasazením celý projekt přebuildovat.

[alblaho]

Konfigurace a vyměňování classů spolu nesouvisí. Párkrát jsem class vyměňoval a teď jsem (na příkladu s konfigurací) objevil případ, kdy to nefunguje, to je celé.

[default]

Co se té třídy Conf týče:

zpravidla jsou tyto třídy javí interfaces, takže s nimi není třeba nikterak šachovat (když jo, tak se refaktoruje na obou stranách). A jak pak vypadá ta ConfImpl třída — to je už opravdu jedno. Jenom musí implementovat ten interface. Takhle třeba funguje vychytávka services.

Docela se mi líbí ten princip modulů v NetBeans. Každý modul je rozdělen na dvě části (pozor, zjednodušuji!): první je public API (ty interfáče) a pak pod tím — ta druhá — je private API s implementací. Pomocí ClassLoaderů je zajištěno, že jiný modul se k té druhé části nedostane. Takže já pak můžu mít několik modulů, které implementují stejné veřejné API a implementace dělá něco trošku/úplně jiného. Je to v podstatě ten model services, akorát víc dotažený.

[Ladicek]

Já bych k tomu řekl jenom tolik: moje vývojové prostředí si závislosti hlídá

[alblaho]

Hmm, že by bash nebyl tím nejlepším IDE?-).

Chtělo by to nějaký plugin do anta. Jenomže když ant bude zkoumat každou třídu jestli tam něco takového není, to už může rovnou nechat přeložit všechno. IDE tohle zkoumání může dělat průběžně.

[default]

Sranda. Zrovna včera jsem na tenhle paskvil upozornil v naší aplikaci. Konstanty obencě by neměly být public nebo package public. Od toho jsou enumy. (Pro rejpaly: neříkám, že to nejde nebo že se to nesmí. Ale zrovna debug level je učebnicová ukázka, jak se to používat nemá. )

Když není nazbyt, tak se to řeší takto:

public static final String SOMETHING;

static {
    SOMETHING = "foo";
}

Takto se vytvoří jen vazba na třídu (aspoň současná verze javac ten trik neumí odhalit) a inlinování provede až ClassLoader za běhu.

Doporučuji si přečíst pár článků o modulárním programování v Javě. Toto konkrétně se řešilo před pár lety, když designovali GlassFish v3. Obecně o modulárním programování pojednává Jaroslav Tulach z NetBeans.

Ale třeba o tom vím jen velký kulový. Koneckonců, v Javě jsem dělal naposledy před rokem.

[Ladicek]

Jako člověk, který tomu ani trochu nerozumí a má tak patřičný odstup, pravím: modulární programování v Javě je jedna velká pakárna a ta classloaderová magie, kterou předvádí OSGi, je zralá akorát tak na cvokhaus. Zlatí chlapci od .NETu, v tohle.

A dělat takovéhle triky s konstantami mi přijde padlé na hlavu. Pokud někdo tvrdí, že dělá inkrementální překlad, a přitom si nepohlídá závislosti, je to chucpe.

[alblaho]

Classloaderovou magii opravdu nemusím. Jak je to v .NETu ovšem netuším, umí vůbec nahrát dvě různé verze jedné assembly?

Občas za běhu reloadnu nějaký modul v Pythonu, tam se na optimalizace kašle a všechno jede hezky dynamicky.

[default]

Classloaderovou magii opravdu nemusím.

ClassLoadeři jsou mí nejlepší kamarádi. Ale já byl vždycky jinej. Když si vzpomenu třeba na ResourceClassLoader, který natahoval aplikaci z resourců přímo z Jar archivu, takže jsem nemusel řešit takový ty lib/ adresáře a -cp parametry… Nebo můj miláček — EndorsedClassLoader. A endorsed.dirs šly tam, odkud přišly.

[Ladicek]

takže jsem nemusel řešit takový ty lib/ adresáře a -cp parametry

JarJar Links

[default]

No, až na to, že to ty knihovny přebalí a cosi to udělá s třídami — tak je to cool. Ale ten ClassLoader mi připadá trošku bezpečnější.

[Ladicek]

Modifikace bajtkódu vládne světu. Sláva javovskému verifikátoru

[alblaho]

Hm, dobrý workaround. Akorát je mi nesympatické psát složitější kód jenom proto, aby to javac nezoptimalizoval .

[mirec]

Určovať závislosti v jave je dosť ehm .. ako by som to správne nazval .. povedzme, že zložité. Minule som do školy riešil pár vecí a používal som vlastné makefile súbory, takže som si užíval to, že javac je neštandardný kompilátor snáď vo všetkom. U C som bol zvynutý na jednoduché generovanie hocičo.c -> hocičo.o pričom názov som si určoval sám. Z jedného súboru vždy práve jeden výstup. Javac to má výrazne zložitejšie pretože pri kompilácii niektorého súboru skompiluje automaticky aj všetky závislosti a ešte to aj pohádže do rôznych adresárov podľa balíčkov. Písať makefile pre toto je fakt peklo. Ale s dodržiavaním pár pravidiel a určením (nie všeobecných) pravidiel v makefile to bolo celkom ľahké a dovolím si tvrdiť, že som makefile napísal rýchlejšie než by mi nabootoval operačný systém netbeans.

[alblaho]

No zkrátka Java je dost jiná než C. Právě proto je lepší použít nástroje, které jsou jí šité na míru, třeba ten ant.