čtvrtek 9. prosince 2004

Eclipse - znáte hot code replace?

Je to již nějaký pátek, co vývojové prostředí Eclipse integruje podporu HotSwap. Java Platform Debugger Architecture (JPDA) definuje rozhraní, které musí poskytovat VM (Virtual Machine). Toto rozhraní slouží pro komunikaci debuggeru a VM, pro zajímavost, debugger a VM spolu komunikuji přes Java Debug Wire Protocol. Java 1.4 představila rozšíření v podobě funkce HotSwap. HotSwap umožňuje debuggeru runtime aktualizaci bytecode. Eclipse resp. debugger v Eclipse tuto funkci využívá.

Co to znamená pro normálního smrtelníka a jaké výhody mu to může přinést? Možná jste si položili jednu z těchto otázek. HotSwap totiž umožňuje realizovat jeden z následujících scénářů. Spustíte aplikaci v debug módu a zjistíte, že jste opomněli opravit část kódu. V normálním případě by bylo potřeba, aplikaci vypnout, kód opravit a znovu nastartovat aplikaci.

Restartování aplikace je činnost nejen nudná, ale někdy i zdlouhavá, viz start aplikačního serveru. Diky HotSwapu restartovat nemusíte, prostě jenom inkriminovaný kousek kódu opravíte, uložíte a Eclipse se postará o zbývající práci. Práce s HotSwap se v Eclipse ukrývá za vlastností Hot code Replace. Samozřejmě Hot Code Replace má své limity, takže půlku aplikační logiky na jeden zátah VM nezměníte.

Druhý scénář opět vychází z úpravy kódu za běhu a jeho pronesení do runtime. Představte si, že krokujete metodu a odhalíte chybu, co uděláte? Chybu opravíte, restartujete aplikaci a počkáte až bude program na daném breakpointu. Jenže to nemusíte, Hot Code Replace při opravě chyby nejen pronese vaše změny, ale i znovu provolá danou metodu, ve které jste změnili kód. Hot Code Replace se tak dá využít, např. při ladění, k opakovanému volání metody.

Pokud se vám Hot Code Replace zalíbil a chcete jej vyzkoušet, tak mějte na paměti, že musíte aplikaci spouštět v debug modu.

Možná by stálo za to osvětlit, proč jsem se o HotSwap rozepsal. Filemon mi dnes básnil o možnostech AOP frameworku AspectWerkz (AW) a mimo jiné argumentoval změnou bytecode v runtime. Samozřejmě, že má první reakce byla, To Eclipse zvládá levou zadní hafo jarů. Nejsem si ovšem jist, jestli AW (online mód) využívá HotSwap. Spíše si myslím, že nikoliv, neboť mu jde o trochu něco jiného, ale to bychom se dostali k point cuts a to je opravdu na jiný šálek kávy.

db4o - databáze a persistence framework v jednom

Nedávno jsem se s Arnym bavil o možnostech zavedení persistence frameworku do jednoho z našich projektů. Zrovna jsme používali na jiném projektu Hibernate, a tak jsem byl nadšen jeho možnostmi, bohužel nasazeni Hibernate bránily dva důvody. Provázání stávajícího relačního modelu na domain model a relativní složitost Hibernate. Myšlenka ORM a persistence frameworku byla zadupána do země a dál jsme to neřešili.

Slovo Embedded se stalo přívlastkem už pro velké množství nástrojů. Pracoval jsem již s embedded servlet kontejnerem Jetty, embedded databázemi Hypersonic či SQLite. Když jsem narazil na článek Jim Paterson Simple Object Persistence with the db4o Object Database, vůbec jsem netušil, že i persistence framework s databází, může být embedded. db4Objects vypadá opravdu zajímavě.

Seznam zajímavých funkcí uvedených v článku

  • No impedance mismatch–objects are stored as they are
  • Automatic management of the database schema
  • No changes to classes to make them storable
  • Seamless Java (or .NET) language binding
  • Automated data bindings
  • Installation by adding a single 250Kb library file (Java jar or .NET DLL)
  • A single database file
  • Automatic schema versioning
  • Query-By-Example
  • S.O.D.A. (Simple Object Database Access),an open source query API

Pokud potřebujete jednoduchou databázi s persistence frameworkem, představuje db4Objects zajímavou možnost. Samozřejmě je třeba uvážit všechna pro a proti embedded řešení, ale minimálně za prozkoumání db4Objects stojí.

úterý 7. prosince 2004

Pojmy, dojmy a promo akce ve znamení J2EE vs .NET

Začne-li se někdo "umně" ohánět studií Comparing Microsoft .NET and IBM WebSphere/J2EE, stoupne mi krev v žilách. Poprvé jsem se ozval, když o této studii informovaly některé blogy na vývojáři. Nebyla to žádná přestřelka, jenom jsem ujasnil některé faktické poznámky k J2EE. Minulý pátek mi přistál v poště dopis Visual Studio .net s podtitulem Mimořádná nabídka pro vývojáře.

Dopis jsem koutkem oka shlédnul a poslal do koše, jediné co mi utkvělo v paměti, byl odstavec nadepsaný Přečtěte si praktické porovnání technologií Microsoft.NET a J2EE.Nějak jsem tomu nevěnoval pozornost, ale pak jsme si uvědomil, že v tom odstavci byla zmíňka o Comparing Microsoft .NET and IBM WebSphere/J2EE. Resuscitoval jsem dopis z koše a radši jsem si to přečetl ještě jednou a pozorně.

Nemám to Microsoftu za zlé, že se snaží touto studií ohánět, ale jasně to ukazuje jak slovíčkaření a překrucování formulací může vytvořit zkreslené informace.

Jak porovnat neporovnatelné

Každá studie, která se honosí podtitulem J2EE vs .NET, je mírně řečeno podezřelá a dopadá na jednu nohu. Je potřeba si uvědomit, že J2EE tvoří množina specifikací a nástrojů. J2EE si jako takové nikde nestáhnete, můžete si stáhnout například Servlet specifikaci, která je součástí J2EE, ale pořád budete mít pouze specifikaci. Ke každé specifikaci existuje minimálně referenční implementace a množina dalších implementací.

Referenční implementací Servletu je Tomcat a mezi další implementace této specifikace patří např. Jetty firmy Mortbay. Tento model si můžeme aplikovat na jakoukoliv součást J2EE, JMS začínaje a EJB konče. DOT.NET je oproti tomu konkrétní produkt firmy Microsoft.

Porovnávat specifikaci s produktem je nesmysl. Zmíněná studie je proto porovnáním produktů .NET a IBM WebSphere. IBM WebSphere je jednou z komplexnějších implementací J2EE a nutno dodat, že podle vyjádření několika nezávislých zdrojů, implementací nijak zvlášť povedenou (jak jsem koupil, tak prodávám).