milan boruvka / log

Na portálu java.cz jsem publikoval recenzi na JGear LiveSource, Eclipse plugin, který je pokračovatelem populárního TogetherJ a je základním kamenem nového JBuilderu 2007:

JGear LiveSource je nový modelovací nástroj firmy CodeGear. LiveSource umožňuje modelování a vizuální návrh Java /Java EE aplikací pomocí modelovacího jazyka UML. Tento produkt je distribuován jako plugin pro vývojové prostředí Eclipse. V tomto příspěvku bych chtěl popsat svoje dojmy a zkušenosti z tohoto produktu.

Celou recenzi naleznete zde:

JGear LiveSource – Namodelujte si své Java EE aplikace! (java.cz)

Zde se můžete podívat na screenshoty.

Alternativní nadpis tohoto příspěvku by mohl znít „Jak použít Eclipse (java) compiler“ mimo IDE. Tímto jsem asi dost napověděl, o čem budou následující řádky pojednávat.

Remote Debugging

Vzdálené debugování (remote debugging) je užitečný nástroj pro ladění „vzdálených“ aplikací – „vzdálených“ v tom smyslu, že se pomocí svého debuggeru připojujete do jiné běžící Java Virtual Machine nejspíše s úmyslem ladění dané aplikace 😉 Nebudu nosit dříví do lesa: Více si o tomto tématu přečtete například v článku Debugging v praxi – opravdu samozřejmost?! od otce Fura či Eclipse a drobné maličkosti – vzdálené debugování od Dagiho.

Hot Swap

S remote debuggingem souvisí další funkcionalita, která z mé vlastní zkušenosti dokáže ušetřit obrovské množství času. Tato funkcionalita se jmenuje hot swap. Hot swap umožňuje „vpašovat“ do běžící aplikace novou verzi přeloženého kódu a nahradit jí tak kód původní.

Pro lepší představu, proč považuji hot swap za maximálně efektivní pomůcku, uvedu jeden příklad z mé praxe. Pracoval jsem na Ariba projektu, kde restart modulu Ariba aplikace (to jest jedné instance Weblogicu) na které jsem pracoval, trval na laptopu přibližně 9-10 minut (díky tomu, že se inicializovaly různé adaptéry, Tibco repositories, kontrolovala se XML metadata,…).

Součástí typického úkolu na tomto projektu byl vývoj nějakého vysoce sofistikovaného 😉 java kódu, který používá pokud možno public API aplikace a na konci dosáhne kýženého výsledku, za aplausu business consultantů 🙂 V uvedené konfiguraci, kdy jedním restartem ztratíte tolik času, si musíte dávat sakra dobrý pozor na jakékoliv triviální chyby (na netriviální chyby si často pozor dát ani nemůžete, například z toho důvodu, že API není zrovna dobře zdokumentované a až stacktrace při testování vás upozorní na možný problém) 😉

Zde se pomalu dostávám k jádru věci. Hot swap vám v těchto případech velice dobře poslouží: triviální problém – zapomněli jste test na null? Chcete přidat debugovací řádku…? S hrůzou zjistíte že nerovnost v podmínce je přesně obráceně? Bez remote debuggingu (aneb tak jak jsem to viděl kupodivu u velkého množství kolegů konzultantů) musíte shodit server, opravit, překompilovat, zrestartovat a dvacet minut je pryč. Následnovně zjistíte, že o pár řádků dále je problém podobný a tak pořád dokola.

Ti rozumnější (případně ti pracující v módu fixed fee a ne time&material 😀 ) využijí hot swap: kód v IDE jednoduše opravíte, upravíte, přeložíte, a pokud jste debuggerem připojeni do JVM v které běží aplikace, hot swap nahraje novou verzi byte-kódu do JVM a nahradí jí kód původní. V těchto jednoduchých případech vám hot swap nezanedbatelně šetří čas. (Samozřejmě zde existuje mnoho omezení, která když porušíte, debugger zobrazí varování, že daná změna není podporována (změny v hierarchii tříd ale i například přidání public metody atd.) a restartu se stejně nevyhnete).

Hot Swap v Eclipse

Zatímco v Intellij Idee hot swap fungoval bez problémů a intuitivně, po přechodu na Eclipse mi hot code replace (jak se tato feature v eclipsu nazývá) v mnoha případech nefungoval. Po rekompilaci třídy se mi místo očekávaného nahrání nového byte-kódu na server zobrazovalo často následující varování:

Trochu jsem pátral co je příčinou a dopátral jsem se. Na obranu debuggingu v Eclipsu můžu uvést, že je v tom (částečně nevinně).

Scheme change not implemented

Zásadní problém je ten, že Eclipse pro kompilaci nepoužívá sunovský javac, nýbrž svůj kompilátor (součást JDT Core component). Vyprodukovaný byte kód se liší (nezkoumal jsem do detailů jak…) od byte kódu class přeložených javac kompilátorem. Tyto rozdíly jsou pro debugger ale podstatné tak, že neumožní záměnu byte kódu za běhu. Podobný problém viz např. na news.eclipse.tools.jdt: Scheme change not implemented.

(Nutno podotknout, že důvod proč se mi na serveru objevuje kód kompilovaný jiným kompilátorem (javac než z IDE (eclipse compiler), je fakt, že instalace a deployment této aplikaci je poměrně komplikovaný proces a je pro něj přepdřipravena sada nástrojů (Ant skriptů), které je nutné ve správném pořadí použít v závislosti na prováděné změně).

Řešení

Řešení problému spočívá v použití stejného kompilátoru v obou případech.

První možnost je donutit Eclipse kompilovat pomocí javac. To jde podle mě jednoduše pouze pomocí nového ANT builderu a custom Ant scriptu. Což není zrovna elegantní.

Druhá varianta je donutit existující produkt, který obsahuje vlastní „Ant“ build systém, kompilovat pomocí Eclipse kompilátoru.

To jde celkem jednoduše:

1. stáhnout ecj.jar (JDT Core Batch Compiler)z eclipse.org
2. donutit Ant použít tento compiler: tzn. nastavit hodnotu Ant property build.compiler na org.eclipse.jdt.core.JDTCompilerAdapter
3. a nakonec samozřejmě přidat ecj.jar do classpath (tip pro lenochy: nahrát tento jar do adresáře ant/lib)

Tímto donutíme Ant kompilovat pomocí Eclipse kompilátoru a hot swap neboli hot code replace funguje tak jak má. Malá poznámka na konec. Rozhodně bych nedoporučoval měnit použitý compiler na produkčním server, o čem tu pojednávám, je prostředí vývojáře! Více kompilování v Eclipse o možnostech použití vně Eclipse IDE se lze dočíst v online nápovědě: JDT Plug-in Developer Guide > Compiling Java code.