Java Beans

Java Beans: jméno komponentního modelu, vyvinutého pro jazyk Java a s ohledem na potřeby tzv. vizuálních autorských nástrojů. Cílem je usnadnit tvorbu rozsáhlejsích programových celků v jazyku Java jejich sestavováním z mensích stavebních bloků (komponent) pomocí takových autorských nástrojů, které umozňují manipulovat s jednotlivými komponentami jako s grafickými objekty.

Snad ve vsech oborech lidské  23423x2311x 69;innosti platí, ze je vhodné se vyvarovat opakovanému vynalézání kola - neboli opakovanému objevování, vymýslení, vytváření či ladění něčeho, co uz bylo jednou objeveno, vymysleno, vytvořeno, odladěno apod. Platí to samozřejmě i v případě tvorby programů, kde je velmi velký tlak na opakovanou vyuzitelnost jiz 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 mozná nejvíce připomínal práci se stavebnicí, neboli sestavování něčeho nového z jiz existujících a předem připravených "kostek" - protoze právě tímto způsobem lze asi nejvíce zvýsit produktivitu práce při vytváření nových programů.

Konkrétních způsobů a technik, jak opakovaně vyuzívat jeden a ten samý kód, je hned několik. Jednou mozností jsou knihovny zdrojových programů, zavedené jiz 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., ulozené ve vhodné databázi (označované nepřílis sť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 pouzíval (volal). Překladač, který takovýto program překládal, pak hledal zdrojový tvar vsech takovýchto částí programu v příslusných zdrojových knihovnách. Podstatné bylo to, ze veskerá "stavebnicovost" se zde odehrávala na úrovni zdrojového kódu, a s překladem zcela zmizela, protoze 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 - kazdá aplikace musela znovu a znovu obsahovat kód, který zajisťoval to samé co přesně stejný kód obsazený v jiné aplikaci. Z hlediska minimalizace velikosti aplikací je jistě výhodnějsí stejný kód ponechat jen v jediném exempláři a ten sdílet více aplikacemi. Problém je ale v tom, ze něco takového jiz nejde zařídit prostřednictvím knihoven zdrojových textů - je k tomu nutný úplně odlisný přístup ke "stavebnicovosti". Takový přístup, který umozní vytvářet knihovny nikoli na úrovni zdrojového tvaru kódu, ale knihovny odpovídající jiz přelozené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 "sit 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řerusení, 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 snazí být nezávislé na konkrétní platformě (coz je případ jazyka Java, který se přímo pysní sloganem "write once, run everywhere" - doslova: napis jednou, provozuj vsude). Samotný jazyk Java samozřejmě také nabízí různé moznosti pro "stavebnicový" charakter vytváření aplikací: jiz na úrovni zdrojového tvaru lze, podobně jako ve vsech objektově orientovaných jazycích, vyuzívat koncepci objektů a vytvářet nejrůznějsí podobjekty, vyuzívat jejich dědičnosti atd. Stejně tak je pamatováno i na "skládání" na úrovni jiz přelozených modulů (run-time knihoven), i kdyz 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 vlozené do jednotlivých WWW stránek, a jsou prováděny přímo v uzivatelově 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 jiz také existují vhodné mechanismy - applety lze spoustě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ůlezité přitom je, ze 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 lepsí vyuzití při "stavebnicové" tvorbě větsích aplikací, je skutečnost ze nevychází přílis vstříc těm autorským nástrojům, které se dnes pro tvorbu aplikací pouzívají nejvíce. Těmito nástroji jsou tzv. vizuální nástroje, které umozň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ětsí 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říslusné autorské nástroje pracující ve "vizuálním" rezimu 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 vsemu 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" vsak stávající Javovské komponenty (třídy, resp. applety) neposkytují.

Řesení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é řesení dostalo název Java Beans (doslova: javovská zrnka, čímz 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 řesením které výrazně usnadní nezávislou tvorbu nejrůznějsích opakovaně vyuzitelných komponent pro Javovské aplikace.