milan boruvka (b)log

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 :D ) 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.

Štítky: eclipse, programovani