Java

The first thing one should undestand before he tries to integrate scripting support into his application / framework are class loading issues. One of the main reasons (next to the ability to easily switch from Java) why we have chosen Groovy as our primary scripting language is very good support for live refresh of Groovy classes when source file has changed. But what does Groovy exactly do when it "refreshes" its loaded classes to conform to a newly modified source file? What about existing instances referencing to this class? Is it even possible in JVM to change class structure in runtime? Yes JavaRebel can do this, but it needs special setup and debug mode for hotswap. And how does all this fit into the existing Spring support? From the documentation it seems, that it all just magically works! Dozens of questions ran in my mind when I started to strive for Groovy integration in our product. Those questions gets answered in this article.

V předchozím článku jsme si ukázali vylepšení iBatisu v souvislosti s XML deklaracemi. Tento navazující článek rozebírá novinky v oblasti Java API. Základem pro toto rozšíření se staly vlastnosti dostupné od verze Javy 1.5 - tedy generiky a anotace. Jednou z velkých kritik původního iBatisu bylo množství XML, které bylo nutné psát. Našlo se mnoho lidí, kterým tento přístup vadil a kteří by spíše uvítali mít vše na jednom místě v kódu. Autoři tyto kritiky vyslyšeli a vytvořili plnohodnotné API, před které je možné využít libovolnou funkcionalitu iBatisu.

Po letech jsme se konečně dočkali třetí verze populární knihovny iBatis. Nová verze přináší velkou řadu novinek a jedná se o kompletní rewrite, který využívá generik, anotací a dalšího API Javy 1.5. iBatis je prozatím ve verzi Beta 1 (doposud ještě není dostupný ani v Maven repository), ale doufejme že nebude dlouho trvat a dočkáme se verze stabilní.

Společně s iBatisem vychází i úplně nový produkt iBATIS Schema Migration System inspirovaný Rails Migrations. Migrations představují podporu pro konzistentní úpravy databázových schémat s důrazem na: konzistenci, opakovatelnost, reverzibilnost, verzování, auditovatelnost a automatizaci. Jedná se o nástroj pro příkazovou řádku, s jehož pomocí je možné systémově vytvářet a spravovat databázové change skripty, které jsou přehledné, dají se kdykoliv revertovat a měly by výrazně ulehčit práci v týmu (pro čtenáře z Forresta: pokud vám to připomíná náš DbAutoupdater, jste doma :-) ).

Tento článek píšu se záměrem zjistit, zda jsme k těmto závěrům dospěli sami, nebo je to evoluční záležitost, ke které časem dospěje každý tvůrce produktů sloužících k dalšímu vývoji. Ve Forrestu k realizaci webů a webových aplikací používáme interní CMS systém, který je nadstavbou nad vybranými Javovskými knihovnami a frameworky. Namátkou například Spring Framework, Freemarker, Groovy, Spring Security, Stripes, DWR, iBatis a řada dalších. Tím, že jsme CMS systém (ona už je to vlastně tak trochu programová platforma) postavili nad existujícími knihovnami jsme dosáhli toho, že můžeme využívat většiny jejich širokých možností a máme zdarma zajištěn i další vývoj, který nás v podstatě bezpracně posouvá zase dál.

Poslední várka zpracovaných záznamů z letošního jOpenspace na sebe nechala chvilku čekat, ale nakonec se mi ji přeci jen podařilo zpracovat. Myslím, že si v ní každý najde něco pro sebe - rozhodně bych doporučil třeba lightning talk Petra Šmída o API Festu pořádaném v HP, ZFS filesystému v Open Solaris Roumena a související přednáškou Petra Adámka, ale myslím, že i ostatní session stojí za poslech. Kvalita je myslím velmi dobrá, podobně jako u ostatních přednášek z jOpenSpace 2009.

Dnes skončil druhý ročník Javovské ne-konference s názvem jOpenSpace, kterou pořádají pánové z Inmite. Podle metody obrácené pyramidy, přejdu rovnou k závěru: letošní ročník byl daleko více uvolněnější než ten minulý (dokonce i na sport se čas našel), přesto mi přinesl dostatek inspirace do příštích měsíců a především řadu kontaktů na zajímavé osobnosti české Java scény. Ty nejhodnotnější informace jsem spíš než z "organizovaného" programu získal z neformální konverzace při jídle a v přestávkách. Ze všech bych vypíchl snad jen skvělé zkušenosti a rady Lukáše Vlčka v oblasti fulltextového vyhledávání (díky Lukáši) nebo skvělou dvouhodinovou konverzaci v kroužku Pavla Juhoše (HP), Václava Pecha (JetBrains) a Maaartina o budoucnosti jazyka Java, porovnání progresivity oproti .NET, jazycích jako je Groovy / Scala apod. Zkrátka a jednoduše, přestože vznikly záznamy z oficiálních "session", ty nejcennější zážitky / informace zachytit na pásku nelze. Ty si člověk odnese, jen když na konferenci prostě je.

Dnes se mi podařilo vychytat velmi dobré přednášky, takže jsem si po včerejším dm Serveru rozhodně spravil chuť. První dnešní přednášky se týkala Groovy a především novinek ve verzi 1.6. Zprvu se zdálo, že Guillame pojede pouze po povrchu Groovy, ale brzy se přednáška rozjela, takže si z ní člověk nakonec odnesl opravdu hodně. Přednáška stavěla na publikovaném článku o Grovy 1.6 na InfoQ. Groovy by ve verzi 1.6 mělo být výrazně rychlejší (různé micro benchmarky ukazují zlepšení výkonnosti od 150% do 430%), díky hotspotu dle Guillama dokonce předběhnou některé jiné dynamické jazyky mimo JVM platformu (konkrétně zmiňoval Ruby). Groovy běží bez problémů na GAP - dokonce je tam k vyzkoušení volně dostupná Groovy konzole. Rozvoj Groovy jede raketovou rychlostí, řekl bych že věci, které tam jsou, v Javě neuvidíme ještě léta a kdo ví jestli vůbec (closures, tuples, properties, statická inicializace properties v rámci konstruktoru). Jediné co nám brání dosud ve firmě nasadit Groovy, je zajištění aby groovy instance vytvořené Springem a naše vlastní instance nad společným Groovy classoaderem sdílely podobné rekompilační chování jako nabízí GroovyScriptingEngine. Groovy je ale rozhodně směr, kterým se chceme ubírat.

Dnešní den přenesl (alespoň v mém případě) řadu roztrpčení. K tomu se ale dostanu až o pár odstavců později. Dnešní keynote se nesla v duchu Lean software development - a to především ve smyslu, jak se co nejrychleji dostat z fáze vývoje do fáze produkčního běhu. Přednáška byla poměrně zajímavá - Adrian Colyer ukazoval prostřednictvím STS živý deployment Spring / Grails aplikací (byť) triviálních přímo na Google App Engine nebo na Amazon EC2. Ačkoliv pro to zatím nemám usecase, praktická ukázka byla skutečně impresivní. Adrian je především skvělý přednášející, který je schopný živě reagovat na odezvu publika a vkládat skutečně zajímavé oživující prvky, které udrží dobrou náladu a pozornost posluchačů (jako třeba bílý tučnák, kterého v průběhu přednášky trestal za jakoukoliv chybu, která se mu ukázkách povedla). Kéž bych uměl své přednášky udělat tak zajímavé jako on ;-) . To co jsem si z přednášky odnesl je to, že nasadit Spring aplikaci na GAE nebo EC2 nemusí být zase tak těžké, jak by se na první pohled mohlo zdát.

Dynamic proxies can be very nasty if you don't know what happening under the cover. Last week I was searching for the memory leak that caused our application to crash. Even though Tomcat had assigned 1GB memory for heap and 0,5GB for PermGenSpace it stood alive for only approximately twelve hours. It's pretty nasty situation having known that application is only in betatesting with relatively low traffic.

When analyzing generated heap dump I have found, that memory leak was caused by web application classloader, that managed thousands of CgLib dynamically generated classes. I was using Eclipse Memory Analyzer, that's probably the best tool for memory heap dump analysis I have ever seen. It's the third time it quickly identified the suspicious classes, by heuristic analysis called Leak suspect.

V prosinci jsem znovu řešil problém s kódováním českých znaků při AJAXové komunikaci se serverem. Znovu říkám proto, že jsem stejný problém řešil před pár měsíci, ale řešení jsem stihnul úplně zapomenout. Tentokrát jsem si ale poklepal na čelo a říkám si: "Furo tvá paměť se horší, zapiš to nebo nad tím budeš za měsíc trávit čas znovu".

Problém je poměrně obecného charakteru - kdysi jsem na to narazil při používání knihovny Prototype.js, nyní to byla jQuery s Tomcatem na straně serveru. Obě dvě knihovny mají pro AJAX (jQuery, Prototype.js) velmi pěknou podporu - ačkoliv bych řekl, že Prototype.js je v tomto ohledu o kousek dál.

Tento týden proběhla na Univerzitě v Hradci Králové přednáška na téma iBatis SqlMaps. V přednášce jsem se snažil projít všemi základními funkcionalitami iBatisu a porovnat jej krátce s několika dalšími přístupy k implementaci datové vrstvy (plain JDBC, JPA / Hibernate) a podívat se co nového nás čeká v nové verzi iBatis číslo 3.

Kvůli omezenému rozsahu (1,5 hodiny) nemohlo dojít na trošku sofistikovanější záležitosti jako je použití diskrimintárů a resultObjectFactory, integrace se Springem, dávkovému zpracování dotazů do databáze a použití iBatoru. Pokud byste měl kdokoliv nějaké otázky týkající se těchto oblastí, neváhejte je napsat do komentářů k tomuto postu, a já se je pokusím zodpovědět a popřípadě publikovat i další příklady.

I had a discussion with Jira recently, whether we could be still looking forward to iBatis 3. It has been long time since iBatis 3 Whiteboard was seriously touched and I haven't found any other clue when or whether there is going to be iBatis 3. There is very small activity for 3.x version in Jira, though there were some commits into iBatis 3 core. As I am going to have a speech in University Hradec Králové on iBatis, I have decided to ask directly its authors about this issue.

Po relativně krátké době se chystá nová přednáška na Univerzitě Hradec Králové - tentokrát o knihovně iBatis, která řeší objektově relační mapování tak trochu jiným způsobem než jde JPA a Hibernate. A to způsobem, který vyhovuje nejen nám, ale i tisícům vývojářů po celém světě. iBatis je řešením, které leží někde mezi JDBC a JPA - na jednu stranu už se nemusíte zabývat detaily spojenými s používáním JDBC (uvolňování zdrojů, konverze dat z ResultSetu do Pojo, cachování atd.), na druhou stranu zůstává vše stále na jednoduché úrovni bez použití magie (nad kterou hloubá každý, kdo se pokouší začít třebas s Hibernatem).

Tento článek mám ve WordPressu rozepsaný snad už rok. Jeho původní název zněl "ResourceBundle - stačí Javě beze změny?". Plno věcí, které jsme původně jako Java vývojáři dělali my, postupně uzpůsobujeme tak, aby je mohli dělat web designeři. Na prezentační vrstvu zcela jistě patří lokalizované texty a zprávy, pro které standardně používáme ResourceBundly Javy, které se načítají z property souborů. Ideální model pro web developery je iterace: navrhnu stránku, vložím text do property bundlu, uložím, reloadnu stránku a kouknu jak to vypadá. V tomhle jednoduchém scénáři jsme však narazili hned na několik problémů.

Ano, ano. Dnes jsem po nasazení nového buildu opět strávil plodné čtyři hodiny věštěním z křišťálové koule zvané Oracle Application Server. Ještě ke všemu na prostředí, ke kterému není přímý přístup. Kód, který máme již na tuctu instalací, který bez problémů běží i na dvou testovacích strojích s "přibližně" stejnou konfigurací na produkci ne a ne.

Výsledkem mého pátrání bylo to, že pokud se na konkrétní verzi OC4J zavolá metoda getParameterMap() dřív než některá z metod getParameter, getParameterNames nebo getParameterValues, tak je výsledkem prázdná mapa, přestože se v requestu parametry nachází.

Toto školení vám ukáže, jak co nejlépe využít různých pomůcek vývojového nástroje Eclipse IDE pro urychlení vývoje SW. Není zaměřeno na žádné pluginy pro Eclipse, veškeré tipy využijete v základní instalaci.

Předevčírem se v mé RSS síti zachytila zajímavá zpráva, která dobře zapadá do katalogu řešení pro automatické testování. Jedná se o MockFtpServer, který se velmi podobá přístupu SubEtha SMTP Serveru, se kterým mám velmi pozitivní zkušenosti.

Princip je skutečně analogický zmiňovanému SubEtha SMTP Serveru, se kterým lze jednoduše ověřovat správné rozesílání emailů. Jednoduše nakonfigurujeme "virtuální" FTP server a nastartujeme jej na konkrétním portu. V testech pak můžeme ověřovat kód, který komunikuje s FTP serverem, aniž bychom museli vytvářet vlastní stub nebo mock objekty:

V polovině listopadu jsem měl na Univerzitě Hradec Králové přednášku o automatickém testování v Javě, ve které jsem zabrousil už trošku do větší hloubky než v té, která proběhla na jaře tohoto roku. Přestože jsem především závěr přednášky nemohl probrat do takových podrobností, jak bych rád, doufám, že se mi většinu nasbíraných zkušeností nějakým způsobem podařilo předat. Pokud vás tedy opakovaně trápí některé problémy při psaní unit a integračních testů, možná při poslechu zjistíte, že i já jsem řešil podobný problém a můžu vám nabídnout nějaký tip co s daným problémem udělat, popř. čeho se vyvarovat.

Nevím jak vy, ale já mám vždy radost, když někdo jiný nezávisle dojde ke stejným závěrům, jako jsem došel já sám. Osobně to považuji za jisté potvrzení smysluplnosti mých vlastních úvah a toho, že nejsem tak úplně "mimo mísu".

Dnes vyšel na java.DZone.com článek s názvem Monitoring Declarative Transactions in Spring od Toma Celluciho, který se zabývá jednoduchým otestováním správného nastavení pointcutů při používání deklarativního nastavení transakcí ve Springu. Pokud si pamatujete, sám jsem tuto problematiku řešil před pár měsíci a publikoval vlastní řešení (a tak trochu mě zviklal Dagi, když se na něj na jOpenSpace moc netvářil).

Díky mému špatnému odhadu, kolik je možné probrat za hodinu a půl jsem se na minulé přednášce nestihnul dotknout žádného z pokročilejších témat souvisejících s automatickým testováním, se kterými se při douhodobém vývoji s použitím testů zcela jistě setkáte. Proto jsem se s Tomášem Kozlem z Univerzity Hradec Králové dohodl na druhé přednášce, která by se věnovala už jen pouze těmto záludnějším věcem a také rozkryla podporu pro testování ve Spring Frameworku.