Java Beans
Snad ve všech oborech lidské činnosti platí, že je vhodné se vyvarovat opakovanému vynalézání kola – neboli opakovanému objevování, vymýšlení, vytváření či ladění něčeho, co už bylo jednou objeveno, vymyšleno, vytvořeno, odladěno apod. Platí to samozřejmě i v případě tvorby programů, kde je velmi velký tlak na opakovanou využitelnost již jednou vytvořených programů i jejich jednotlivých částí (obecně tzv. kódu). Lze to přirovnat ke snaze změnit charakter programování tak, aby co možná nejvíce připomínal práci se stavebnicí, neboli sestavování něčeho nového z již existujících a předem připravených "kostek" – protože právě tímto způsobem lze asi nejvíce zvýšit produktivitu práce při vytváření nových programů.
Konkrétních způsobů a technik, jak opakovaně využívat jeden a ten samý kód, je hned několik. Jednou možností jsou knihovny zdrojových programů, zavedené již v prvních pionýrských dobách programování, nejčastěji na úrovni jazyka symbolických adres, neboli v asembleru: jsou to vlastně části zdrojového textu odpovídající jednotlivým podprogramům, rutinám apod., uložené ve vhodné databázi (označované nepříliš šťastně jako knihovna). Programátor, který vytvářel zdrojový text svého programu, některé části svého programu sám nenapsal (nenaprogramoval), ale pouze je používal (volal). Překladač, který takovýto program překládal, pak hledal zdrojový tvar všech takovýchto částí programu v příslušných zdrojových knihovnách. Podstatné bylo to, že veškerá "stavebnicovost" se zde odehrávala na úrovni zdrojového kódu, a s překladem zcela zmizela, protože při překladu vznikla v zásadě monolitická (jednolitá) aplikace. I tak to ale programátorům značně usnadnilo práci.
Nevýhodou "stavebnicovosti" na úrovni sdílení zdrojových tvarů bylo jisté plýtvání kódem – každá aplikace musela znovu a znovu obsahovat kód, který zajišťoval to samé co přesně stejný kód obsažený v jiné aplikaci. Z hlediska minimalizace velikosti aplikací je jistě výhodnější stejný kód ponechat jen v jediném exempláři a ten sdílet více aplikacemi. Problém je ale v tom, že něco takového již nejde zařídit prostřednictvím knihoven zdrojových textů – je k tomu nutný úplně odlišný přístup ke "stavebnicovosti". Takový přístup, který umožní vytvářet knihovny nikoli na úrovni zdrojového tvaru kódu, ale knihovny odpovídající již přeloženému a samostatně existujícímu kódu, který jiné programy mohou za svého běhu podle potřeb volat (obvykle se jim říká "run-time" knihovny, ve smyslu: knihovny volané za běhu). Konkrétní realizace je samozřejmě velmi závislá na tom, o jaké systémové prostředí se jedná – v případě starého dobrého DOSu muselo jít o samostatné rezidentní programy, zatímco například v prostředí MS Windows jde o knihovny DLL (Dynamic Link Library). Programátor, vytvářející zdrojový tvar svého programu, pak musí znát konkrétní rozhraní k takovýmto "run-time" knihovnám, tj. přesný způsob jejich volání. Ten ale také musí být "šit na míru" konkrétnímu systémovému prostředí, kterému jsou ostatně uzpůsobeny i jednotlivé "run-time" knihovny (například jde o volání prostřednictvím přerušení, prostřednictvím funkcí jádra operačního systému apod.).
Takováto závislost na konkrétním prostředí samozřejmě nejde dohromady s filosofií jazyků, které se snaží být nezávislé na konkrétní platformě (což je případ jazyka Java, který se přímo pyšní sloganem "write once, run everywhere" – doslova: napiš jednou, provozuj všude). Samotný jazyk Java samozřejmě také nabízí různé možnosti pro "stavebnicový" charakter vytváření aplikací: již na úrovni zdrojového tvaru lze, podobně jako ve všech objektově orientovaných jazycích, využívat koncepci objektů a vytvářet nejrůznější podobjekty, využívat jejich dědičnosti atd. Stejně tak je pamatováno i na "skládání" na úrovni již přeložených modulů (run-time knihoven), i když v případě Javy není zcela na místě mluvit o překladu (viz například minulý díl tohoto slovníku). Jde konkrétně o tzv. applety, jak se říká obvykle jednoduchým prográmkům v Javě, které cestují po síti vložené do jednotlivých WWW stránek, a jsou prováděny přímo v uživatelově browseru (obecně pak v jakémkoli prostředí, schopném chovat se jako vhodný "kontejner" a vytvářet takové prostředí, jaké applety ke svému běhu potřebují). Pro konkrétní volání jednotlivých appletů přitom již také existují vhodné mechanismy – applety lze spouštět přímo z HTML kódu jednotlivých WWW stránek, nebo prostřednictvím skriptových jazyků, které také lze vkládat do HTML stránek (např. JavaScript, JScript). Důležité přitom je, že jde o takovou formu volání "run-time" knihoven (appletů), která je, stejně jako celý jazyk Java, nezávislá na konkrétní platformě.
Problém s třídami a applety jazyka Java, který komplikuje jejich lepší využití při "stavebnicové" tvorbě větších aplikací, je skutečnost že nevychází příliš vstříc těm autorským nástrojům, které se dnes pro tvorbu aplikací používají nejvíce. Těmito nástroji jsou tzv. vizuální nástroje, které umožňují autorovi manipulovat s jednotlivými komponentami vytvářeného systému jako s grafickými objekty, definovat jejich vazby, upravovat jejich vlastnosti atd. Příkladem mohou být současné verze Visual Basicu, Delphi apod.
Hlavním smyslem "vizuálnosti" je opět větší produktivita práce autora, který svou aplikaci sestavuje z předem připravených komponent, způsobem velmi intuitivním a přehledným. Podmínkou je ale to, aby si příslušné autorské nástroje pracující ve "vizuálním" režimu dokázaly porozumět s těmito komponentami: aby dokázaly poznat, jaké mají vlastnosti, vstupní body, způsoby ovládání (přesněji: jaké mají metody, jaké události generují apod.), a díky tomu mohly autorovi nabídnout přehledný a jednoduchý způsob vzájemného "provázání" těchto komponent. K tomu všemu je ale potřeba, aby i samotné komponenty vycházely vizuálním autorským nástrojům vstříc, aby pro ně byly "čitelné", a poskytovaly jim takové informace, které jsou pro sestavování komponent potřebné. Takovéto "sestavovací informace" však stávající Javovské komponenty (třídy, resp. applety) neposkytují.
Řešením, které se objevilo koncem loňského roku a které připravila firma Sun (resp. její divize JavaSoft), je nový formát "balení" komponent vytvářených v Javě, který na rozdíl od appletů a tříd vychází vstříc potřebám vizuálních autorských nástrojů (obsahuje potřebné "sestavovací informace"), a přitom si stále zachovává dosavadní nezávislost na konkrétní platformě. Toto nové řešení dostalo název Java Beans (doslova: javovská zrnka, čímž pokračuje celá "kávová analogie" Javy). Je významným krokem na cestě ke skutečně vizuálním autorským nástrojům pro Javu, i řešením které výrazně usnadní nezávislou tvorbu nejrůznějších opakovaně využitelných komponent pro Javovské aplikace.
Další zdroje informací:
Výchozím zdrojem informací je domovská stránka Java Beans u firmy Sun (nebo její česká kopie). Zde také lze najít přesné specifikace i úvodní tutoriál. Další stránku s odkazy na zdroje o Java Beans najdete například zde.
Zajímavý a poučný rozhovor s člověkem, který šéfoval vývoji Java Beans přímo u firmy Sun, lze najít zde. Časopisecké články o podstatě a smyslu Java Beans lze najít například zde, zde, zde a zde..