Možná, už dávno nepotřebuje zvláštní představení. Mnozí znají Eclipse díky Eclipse Java development tools (). Tato populární open-source Java IDE se většinou vývojářů spojuje se slovem „Eclipse“. Nicméně Eclipse je také rozšiřitelná platforma pro integraci vývojových nástrojů (Eclipse Platform) a celá řada IDE postavených na jejím základu, včetně JDT. Eclipse je také Eclipse Project, projekt nejvyšší úrovně, který koordinuje vývoj Eclipse Platform a JDT, a Eclipse SDK – dodávaný výstup tohoto vývoje. Konečně, Eclipse je open-source nadace s obrovskou komunitou projektů, z nichž mnohé nejsou napsány v Javě nebo nemají vztah k vývojovým nástrojům (například projekty a ). Svět Eclipse je velmi různorodý.
V tomto článku, který má přehledný charakter, se pokusíme přezkoumat některé základy architektury Eclipse jako platformy pro budování integrovaných vývojových nástrojů a poskytnout úvodní představu o komponentech Eclipse, které tvoří základ technologické platformy pro „nového Konfigurátora“ 1C: Podnikání, . Samozřejmě, takové přezkoumání bude nevyhnutelně zčásti povrchní a poměrně omezené, včetně toho, že se orientujeme nejen na vývojáře Eclipse jako cílovou skupinu. Doufáme však, že i zkušení vývojáři Eclipse najdou v článku zajímavé informace. Například se podělíme o jedno z „tajemství Eclipse“, o relativně novém a málo známém projektu , který byl založen a podporován společností 1C.
Úvod do architektury Eclipse
Nejprve prozkoumáme některé obecné aspekty architektury Eclipse na příkladu (JDT). Výběr právě JDT jako příkladu není náhodný. To je první integrované vývojové prostředí, které se objevilo v Eclipse. Ostatní *DT projekty Eclipse, jako Eclipse C/C++ Development Tooling (CDT), byly vytvořeny později a převzaly jak základní architektonické principy, tak jednotlivé fragmenty zdrojového kódu z JDT. Základy architektury, položené v JDT, jsou aktuální dodnes pro prakticky jakoukoli IDE, postavenou na Eclipse Platform, včetně 1C:Enterprise Development Tools.
Na prvním místě je třeba zdůraznit, že Eclipse se vyznačuje dostatečně jasnou architektonickou strukturou, která odděluje jazykově nezávislou funkčnost od funkčnosti určené pro podporu konkrétních programovacích jazyků, a odděluje UI-nezávislé „jádrové“ komponenty od komponent spojených s podporou uživatelského rozhraní.
Eclipse Platform tak definuje obecnou, jazykově nezávislou infrastrukturu, zatímco nástroje pro vývoj v Javě přidávají k Eclipse plně funkční Java IDE. Jak Eclipse Platform, tak JDT se skládají z několika komponent, z nichž každá patří buď do UI-nezávislého „jádra“, nebo do vrstvy UI (obr. 1).
Obr. 1. Eclipse Platform a JDT
Uveďme hlavní komponenty Eclipse Platform:
- Runtime — Určuje infrastrukturu pluginů. Eclipse se vyznačuje modulární architekturou. V podstatě je Eclipse sbírkou „bodů rozšíření“ a „rozšíření“.
- Workspace — Spravuje jeden nebo více projektů. Projekt se skládá z složek a souborů, které se přímo zobrazuje na souborovém systému.
- Standard Widget Toolkit (SWT) — Poskytuje základní prvky uživatelského rozhraní, které jsou integrovány s operačním systémem.
- JFace — Nabízí řadu UI frameworků postavených na SWT.
- Workbench — Určuje UI-paradigma Eclipse: editory, pohledy, perspektivy.
Je třeba říci, že Eclipse Platform poskytuje i mnoho dalších užitečných komponent pro vytváření integrovaných vývojových nástrojů, mezi kterými lze zmínit Debug, Compare, Search a Team. Zvlášť je třeba zmínit JFace Text – základ pro tvorbu „inteligentních editorů“ zdrojového kódu. Bohužel, i povrchní prozkoumání těchto komponent, stejně jako komponent vrstvy UI, není možné v rámci tohoto článku, proto se v zbytku této části omezíme na přehled hlavních „jádrových“ komponent Eclipse Platform a JDT.
Core Runtime
Infrastruktura pluginů Eclipse je založena na a je poskytována projektem . Každý plugin Eclipse je OSGi-bundle. Specifikace OSGi určuje mimo jiné mechanismy verzování a řešení závislostí. Kromě těchto standardních mechanismů zavádí Equinox pojem bod rozšíření. Každý plugin může definovat své body rozšíření a přinášet do systému dodatečnou funkčnost („rozšíření“) pomocí bodů rozšíření definovaných tímto nebo jinými pluginy. Podrobné popisy mechanismů OSGi a Equinox vycházejí mimo rámec tohoto článku. Je však důležité poznamenat, že modularizace v Eclipse je naprosto zásadní (jakýkoli subsystém, včetně Runtime, se skládá z jednoho nebo několika pluginů) a prakticky vše v Eclipse je rozšíření. Tyto principy byly zakotveny v architektuře Eclipse už dlouho před zavedením OSGi (v té době byla používána vlastní technologie, která byla do značné míry podobná OSGi).
Hlavní pracovní prostředí
Prakticky každé integrované vývojové prostředí postavené na základě Eclipse Platform pracuje s pracovním prostředím Eclipse. Právě pracovní prostředí obvykle obsahuje zdrojový kód vyvíjené aplikace v IDE. Pracovní prostředí se přímo zobrazuje na souborový systém a skládá se z projektů, které obsahují složky a soubory. Tyto projekty, složky a soubory se nazývají zdroji pracovní prostředí. Realizace pracovního prostředí v Eclipse slouží jako určitý mezipaměť k souborovému systému, což výrazně urychluje procházení stromu zdrojů. Kromě toho pracovní prostředí poskytuje řadu dalších služeb, včetně a .
Za podporu pracovního prostředí a jeho zdrojů odpovídá komponenta Core Resources (plugin org.eclipse.core.resources). Konkrétně tato komponenta poskytuje programový přístup k pracovnímu prostředí ve formě modelu zdrojů. Pro efektivní práci s tímto modelem potřebují klienti jednoduchý způsob, jak reprezentovat odkaz na zdroj. Současně by bylo žádoucí skrýt objekt, který přímo uchovává stav zdroje v modelu, před klientským přístupem. Jinak by například v případě smazání souboru klient mohl nadále udržovat objekt, který již v modelu není, což by vedlo k problémům. Eclipse tuto úlohu řeší použitím tzv. handle zdroje. Handle slouží jako klíč (zná pouze cestu k zdroji v pracovním prostředí) a plně kontroluje přístup k internímu objektu modelu, který přímo uchovává informace o stavu zdroje. Tento design je variantou vzoru .
Obrázek 2 ilustruje idiom Handle/Body v kontextu modelu zdrojů. Rozhraní IResource představuje handle zdroje a je API, na rozdíl od třídy Resource, která toto rozhraní implementuje, a třídy ResourceInfo, která představuje body a API se nestává. Zdůrazňujeme, že handle zná pouze cestu k zdroji v rámci kořene workspace a neobsahuje odkaz na resource info. Objekty resource info tvoří tzv. "strom elementů" (element tree). Tato datová struktura je zcela materializována v paměti. K nalezení instance resource info odpovídající určitému handle se traversuje element tree podle cesty, která je uložena v tomto handle.
Obrázek 2. IResource a ResourceInfo
Jak uvidíme dále, základní design modelu zdrojů (můžeme ho nazvat handle-based) je využíván v Eclipse i pro jiné modely. Zatím uvedeme některé charakteristické vlastnosti tohoto designu:
- Handle je objekt-atribut (value object). Objekty-atributy jsou neměnné (immutable) objekty, jejichž rovnost se nezakládá na identitě. Takové objekty lze bezpečně používat jako klíč v hashovaných kontejnerech. Několik instancí handle může odkazovat na stejný zdroj. Pro jejich porovnání je třeba použít metodu equals(Object).
- Handle určuje chování zdroje, ale neobsahuje informace o stavu zdroje (jediné údaje, které uchovává, jsou "klíč", cesta k zdroji).
- Handle může odkazovat na neexistující zdroj (buď zdroj, který ještě nebyl vytvořen, nebo zdroj, který již byl odstraněn). Existenci zdroje lze ověřit pomocí metody IResource.exists().
- Některé operace mohou být implementovány čistě na základě informací uložených v samotném handle (takzvané handle-only operace). Příklady zahrnují IResource.getParent(), getFullPath(), atd. Zdroje nemusí nutně existovat pro úspěšné provedení takové operace. Operace, pro jejichž úspěšné provedení je požadováno, aby zdroj existoval, vyhazují výjimku (CoreException), pokud zdroj neexistuje.
Eclipse poskytuje efektivní mechanismus oznamování změn zdrojů pracovního prostoru (obr. 3). Zdroje se mohou měnit jak v důsledku akcí prováděných přímo v Eclipse IDE, tak v důsledku synchronizace se souborovým systémem. V obou případech je klientům přihlášeným k odběru oznámení poskytována podrobná informace o změnách ve formě „delta zdroje“ (resource delta). Delta popisuje změny mezi dvěma stavy (pod-)stromu zdrojů pracovního prostoru a sama je stromem, jehož každý uzel popisuje změnu určitého zdroje a obsahuje seznam delta na další úrovni, které popisují změny podřízených zdrojů.
Obr. 3. IResourceChangeEvent a IResourceDelta
Na základě delta zdrojů má mechanismus oznamování následující vlastnosti:
- Jednotlivá změna a více změn jsou popsány pomocí stejné struktury, protože delta je konstruována na principu rekurzivní kompozice. Klienti-předplatitelé mohou zpracovávat oznámení o změnách zdrojů pomocí rekurzivního průchodu stromem delta.
- Delta obsahuje úplné informace o změně zdroje, včetně jeho přesunu a/nebo změny asociovaných „markerů“ (například chyby kompilace jsou představovány jako markery).
- Jelikož odkazy na zdroj jsou realizovány prostřednictvím handle, může delta přirozeně odkazovat na odstraněný zdroj.
Jak brzy uvidíme, hlavní komponenty návrhu mechanismu oznamování změn modelu zdrojů jsou relevantní i pro další modely založené na handle.
JDT Core
Model zdrojů pracovního prostoru Eclipse je základním jazykově nezávislým modelem. Komponenta JDT Core (plugin org.eclipse.jdt.core) poskytuje API pro navigaci a analýzu struktury pracovního prostoru z pohledu Java, takzvaný „Java model“ (Java model). Toto API je definováno v termínech Java prvků, na rozdíl od nižšího API modelu zdrojů, které je definováno v termínech složek a souborů. Hlavní rozhraní stromu prvků Java jsou zobrazeny na obr. 4.
Obr. 4. Prvky modelu Java
Model Java používá stejnou idiom handle/body jako model zdrojů (obr. 5). IJavaElement je handle, zatímco JavaElementInfo hraje roli body. Rozhraní IJavaElement definuje protokol, který je společný pro všechny prvky Java. Některé z jeho metod jsou pouze handle: getElementName(), getParent() atd. Objekt JavaElementInfo uchovává stav odpovídajícího prvku: jeho strukturu a atributy.
Obr. 5. IJavaElement a JavaElementInfo
Model Java má některé odlišnosti v realizaci základního designu handle/body ve srovnání s modelem zdrojů. Jak bylo zmíněno výše, v modelu zdrojů je element tree, jehož uzly jsou objekty resource info, zcela uložen v paměti. Ale v modelu Java může být výrazně více prvků než v stromu zdrojů, protože representuje také vnitřní strukturu .java a .class souborů: typy, pole a metody.
Aby se předešlo úplné materializaci celého stromu prvků v paměti, realizace modelu Java používá omezenou velikostí LRU-cache element info, kde klíčem je handle IJavaElement. Objekty element info jsou vytvářeny na požádání, jakmile probíhá navigace stromem prvků. Přitom jsou nejméně používané prvky vytlačovány z cache a spotřeba paměti modelem zůstává omezena zadanou velikostí cache. To je další výhoda designu na bázi handle, který zcela skrývá takové detaily implementace před klientským kódem.
Mechanismus notifikace o změnách prvků Java je v obecných rysech analogický výše uvedenému mechanismu sledování změn zdrojů workspace. Klient, který chce sledovat změny v modelu Java, se přihlašuje k notifikacím, které jsou prezentovány ve formě objektu ElementChangedEvent, který obsahuje IJavaElementDelta (obr. 6).
Obr. 6. ElementChangedEvent a IJavaElementDelta
Model Java neobsahuje informace o těle metod nebo o názvy, proto pro podrobné analýzy kódu napsaného v Java poskytuje JDT Core další (ne handle-based) model: (abstraktní syntaktický strom, AST). AST představuje výsledek syntaktické analýzy zdrojového textu. Uzly AST odpovídají prvkům struktury daného modulu (prohlášení, operátory, výrazy atd.) a obsahují informace o souřadnicích odpovídajícího prvku ve zdrojovém textu, a také (volitelně) informace o rozlišení názvů ve formě odkazů na tzv. bindings. Baindingy jsou objekty představující pojmenované entity, jako jsou typy, metody a proměnné, které jsou známé překladači. Na rozdíl od uzlů AST, které tvoří strom, bindingy podporují křížové odkazy a obvykle vytvářejí graf. Abstraktní třída ASTNode je společnou základní třídou pro všechny uzly AST. Podtřídy ASTNode odpovídají konkrétním syntaktickým konstrukcím jazyka Java.
Jelikož syntaktické stromy mohou spotřebovávat značné množství paměti, JDT ukládá do mezipaměti pouze jeden AST pro aktivní editor. Na rozdíl od modelu Java se AST obvykle považuje za "mezičlánek", "dočasný" model, jehož prvky by si klienti neměli uchovávat odkazy mimo kontext akce, která vedla k jeho vytvoření.
Uvedené tři modely (Java model, AST, bindings) společně tvoří základ pro vývoj "inteligentních vývojových nástrojů" v JDT, mezi kterými je mocný editor Java s různými "asistenty", různé akce pro zpracování zdrojového kódu (mezi nimi organizace seznamu importu názvů a formátování podle nastaveného stylu), nástroje pro vyhledávání a refaktoring. Přičemž model Java hraje zvláštní roli, protože je použit jako základ pro vizuální zobrazení struktury vyvíjené aplikace (například v Package Explorer, Outline, Search, Call Hierarchy a Type Hierarchy).
Komponenty Eclipse používané v 1C:Enterprise Development Tools
Na obr. 7 jsou znázorněny komponenty Eclipse, které tvoří základ technologické platformy pro 1C:Enterprise Development Tools.
Obr. 7. Eclipse jako platforma pro 1C:Enterprise Development Tools
Eclipse Platform poskytuje základní infrastrukturu. Některé aspekty této infrastruktury jsme probrali v předchozí části.
(EMF) poskytuje obecné nástroje pro modelování strukturovaných dat. EMF je integrován s platformou Eclipse, ale může být také používán samostatně, v běžných aplikacích Java. Poměrně často jsou začínající vývojáři Eclipse již dobře obeznámeni s EMF, i když ještě úplně nerozumí nuancím platformy Eclipse. Jedním z důvodů této zasloužené popularity je univerzální design, který zahrnuje mimo jiné také sjednocené API metaúrovně, které umožňuje generalizovanou práci s jakýmkoli modelem EMF. Poskytované základní implementace EMF pro objekty modelu a subsystém generování kódu modelu podle meta-modelu podstatně zvyšují rychlost vývoje a snižují počet chyb. EMF také obsahuje mechanismy serializace modelů, sledování změn v modelu a mnoho dalšího.
Stejně jako každý skutečně univerzální nástroj, EMF je vhodný pro řešení široké škály úkolů spojených s modelováním, ale některé třídy modelů (například výše zmíněné modely založené na handle) mohou potřebovat specializovanější modelovací nástroje. Mluvit o EMF je dosti vděčný úkol, zejména v omezených rámci jednoho článku, protože to je téma samostatné knihy, a to docela objemné. Upozorníme pouze na to, že kvalitní systém generalizací, který stojí za EMF, umožnil vznik celého spektra projektů zaměřených na modelování, které patří do projektu vyšší úrovně. spolu s EMF samotným. Jedním z takových projektů je Eclipse Xtext.
poskytuje infrastrukturu pro 'textové modelování'. Xtext využívá pro syntaktickou analýzu zdrojového textu a EMF pro reprezentaci výsledného ASG (abstraktního sémantického grafu, který je v podstatě kombinací AST a bindings), nazývaného také "sémantickým modelem". Gramatika modelovaného jazyka pomocí Xtext je popsána vlastním jazykem Xtext. To umožňuje nejen generovat popis gramatiky pro ANTLR, ale také získat mechanismus serializace AST (tj. Xtext poskytuje jak parser, tak unparser), kontextové nápovědy a řadu dalších jazykových komponent. Na druhé straně, jazyk popisu gramatiky používaný v Xtext je méně flexibilní ve srovnání s jazykem popisu gramatiky v ANTLR. Proto je někdy nutné "přizpůsobit" implementovaný jazyk Xtext, což obvykle není problém, pokud se jedná o jazyk vyvíjený od nuly, ale může být nepřijatelné pro jazyky s již zavedenou syntaxí. Navzdory tomu je Xtext v současnosti nejzralejší, funkčně nejkompletnější a nejuniverzálnější nástroj v Eclipse pro vytváření programovacích jazyků a nástrojů pro ně. Je to zejména ideální nástroj pro rychlé prototypování. (domain-specific language, DSL). Kromě zmíněného "jazykového jádra" na základě ANTLR a EMF, Xtext poskytuje řadu užitečných komponent na vyšší úrovni, včetně mechanismů indexování, inkrementálního budování, "inteligentního editoru" a mnoha dalších, ale vynechává jazykové modely založené na handle. Stejně jako EMF je Xtext předmětem hodným celé knihy a těžko bychom mohli i jen letmo přehledněji přiblížit všechny jeho možnosti.
1C:Enterprise Development Tools aktivně využívají jak EMF samotné, tak i řadu dalších projektů Eclipse Modeling. Konkrétně, Xtext je jedním ze základů nástrojů pro vývoj pro jazyky 1C:Enterprise, jako je integrovaný programovací jazyk a jazyk dotazů. Dalším základem těchto nástrojů je projekt Eclipse Handly, na kterém se podrobněji zastavíme (z uvedených komponent Eclipse je zatím nejslaběji známý).
, podprojekt nadřazeného projektu Eclipse Technology vznikl díky počátečnímu přispění kódu do Eclipse Foundation, které provedla společnost 1C v roce 2014. Od té doby společnost 1C pokračuje v podpoře vývoje projektu: komitátoři Handly jsou zaměstnanci společnosti. Projekt je malý, ale zaujímá dostatečně unikátní místo v Eclipse: jeho hlavním cílem je podpora vývoje modelů založených na handlech.
Hlavní architektonické principy modelů založených na handlech, jako je idiom handle/body, byly uvedeny výše na příkladu modelu zdrojů a modelu Java. Také bylo zmíněno, že jak model zdrojů, tak i model Java jsou významné základy pro Eclipse Java Development Tools (JDT). A protože většina projektů *DT v Eclipse má podobnou architekturu jako JDT, nebude velkým přeháněním říci, že modely založené na handlech leží v základech mnoha, ne-li všech IDE, postavených na platformě Eclipse. Například v Eclipse C/C++ Development Tooling (CDT) existuje model C/C++ založený na handlech, který v architektuře CDT plní stejnou roli jako model Java v JDT.
Před příchodem Handly Eclipse nenabízel specializované knihovny pro výstavbu jazykových modelů založených na handlech. Existující modely byly vytvářeny převážně přímo adaptací kódu modelu Java (známé jako copy/paste), v těch případech, kdy to umožňuje Eclipse Public License (EPL). (Je jasné, že pro projekty samotného Eclipse to obvykle nepředstavuje právní problém, což se nedá říci o produktech s uzavřeným zdrojovým kódem.) Kromě typické bezsystémovosti tato metoda vede k dobře známým problémům: duplicita kódu, chyby přenesené při adaptaci atd. Co je ještě horší, výsledné modely zůstávají "věcí v sobě" a nevyužívají existující potenciál pro unifikaci. A přitom by vymezení společných konceptů a protokolů pro jazykové modely založené na handlech mohlo vést k vytvoření opakovaně použitelných komponent pro práci s nimi, podobně jako tomu bylo v případě EMF.
Nelze říci, že v Eclipse nebylo pochopení těchto problémů. Již v roce 2005 , shrnující zkušenosti s vývojem prototypu CDT, potřeba vytvoření společné infrastruktury pro jazykové modely, včetně modelů založených na handlech. Jak to však často bývá, kvůli prioritnějším úkolům se realizace těchto myšlenek tehdy nedočkala. Mezitím faktorování kódu *DT projektů stále zůstává jedním z nedostatečně prozkoumaných témat v Eclipse.
V jistém smyslu je projekt Handly navržen tak, aby řešil přibližně stejné úkoly jako EMF, ale pro modely založené na handlech, přičemž se zaměřuje především na jazykové modely (tj. reprezentující prvky struktury určitého programovacího jazyka). Níže jsou uvedeny hlavní cíle, které byly stanoveny při návrhu Handly:
- Vymezení hlavních abstrakcí domény.
- Snížení úsilí a zvýšení kvality implementace jazykových modelů založených na handlech díky opětovnému používání kódu.
- Poskytnutí jednotného API metaúrovně k výsledným modelům, což umožňuje vytváření společných komponent IDE, které pracují s jazykovými modely založenými na handlech.
- Flexibilita a škálovatelnost.
- Integrace s Xtext (v samostatné vrstvě).
Pro vymezení společných pojmů a protokolů byly analyzovány existující implementace jazykových modelů založených na handlech. Hlavní rozhraní a základní implementace poskytované Handly jsou znázorněny na obr. 8.
Obr. 8. Společná rozhraní a základní implementace prvků Handly
Rozhraní IElement představuje handle prvku a je společné pro prvky všech modelů založených na Handly. Abstraktní třída Element implementuje obecný mechanismus handle/body (obr. 9).
Obr. 9. IElement a obecná implementace handle/body
Kromě toho Handly poskytuje obecný mechanismus notifikace o změně prvků modelu (obr. 10). Jak lze vidět, v obecných rysech je podobný mechanizmům notifikace implementovaným v modelu prostředků a Java modelu, a používá IElementDelta pro jednotné zobrazení informací o změně prvku.
Obr. 10. Společná rozhraní a základní implementace notifikačního mechanismu Handly
Výše uvedená část Handly (obr. 9 a 10) může být použita pro reprezentaci prakticky jakýchkoliv modelů založených na handlech. Pro vytváření jazykových modelů projekt nabízí další funkčnost – konkrétně společná rozhraní a základní implementace pro prvky struktury zdrojového textu, takzvané source elements (obr. 8). Rozhraní ISourceFile představuje zdrojový soubor, zatímco ISourceConstruct – prvek ve zdrojovém souboru. Abstraktní třídy SourceFile a SourceConstruct implementují generické mechanismy pro podporu práce se zdrojovými soubory a jejich prvky, například práci s textovými buffery, vazbu na souřadnice prvku v původním textu, usmiřování modelu s aktuálním obsahem pracovního buffera atd. Implementace těchto mechanismů bývá obvykle dost složitým úkolem a Handly může významně zkrátit úsilí o vývoj jazykových modelů založených na handlech díky poskytování kvalitních základních implementací.
Kromě uvedených základních mechanismů Handly poskytuje infrastrukturu pro textové buffery a „snímky“ (snapshots), podporu integrace s editory zdrojového kódu (včetně předem implementované integrace s editorem Xtext) a také některé obecné komponenty UI, které pracují s modely založenými na Handly, jako je framework outline. Pro ilustraci svých schopností projekt poskytuje několik příkladů, včetně implementace modelu Java na Handly. (Ve srovnání s úplnou implementací Java-modelu v JDT je tento model záměrně poněkud zjednodušen pro větší přehlednost.)
Jak bylo zmíněno dříve, vážná pozornost při počátečním projektování Handly a jeho dalším rozvoji byla a nadále je věnována škálovatelnosti a flexibilitě.
V principu jsou modely založené na handlech poměrně dobře škálovatelné „z výroby“. Například idiom handle/body umožňuje omezit množství paměti spotřebované modelem. Existují však i nuance. Během testování Handly na škálovatelnost se objevila v realizaci mechanismu notifikace problém – při změně velkého počtu prvků zabíralo sestavení delta příliš mnoho času. Ukázalo se, že stejný problém se nachází také v Java-modelu JDT, ze kterého byl v minulosti adaptován odpovídající kód. Opravy chyby v Handly byly provedeny a připravil se podobný patch pro JDT, který byl s vděčností přijat. To je pouze jeden z příkladů, kdy by implementace Handly do stávajících realizací modelů mohla být potenciálně užitečná, protože v tomto případě by bylo možné takovou chybu opravit pouze na jednom místě.
Aby bylo možné technicky integrovat Handly do stávajících implementací modelů, musí mít knihovna značnou flexibilitu. Hlavním problémem je zachování zpětné kompatibility API modelu. Tento úkol byl vyřešen čistým oddělením specifického pro model API, které je definováno a plně kontrolováno vyvíjejícím, od unifikovaného API metaúrovně, které poskytuje knihovna. To nejen usnadňuje technickou integraci Handly do stávajících implementací, ale také dává vývojáři nového modelu značnou svobodu při navrhování API.
Flexibilita má i další aspekty. Například Handly téměř neomezuje strukturu modelu a může být použit jak pro modelování jazyků obecného určení, tak i pro jazyky zaměřené na konkrétní předměty. Při sestavování struktury zdrojového souboru Handly nepředepisuje žádnou konkrétní formu reprezentace AST a vlastně ani nevyžaduje samotnou existenci AST, tím pádem zajišťuje kompatibilitu s prakticky jakýmikoliv mechanismy syntaktické analýzy. Nakonec Handly podporuje plnou integraci s pracovním prostorem Eclipse, ale také může pracovat přímo s souborovými systémy, díky integraci s (EFS).
Aktuální verze byla vydána v prosinci 2016. Přestože projekt je nyní ve stádiu inkubace a API ještě není definitivně stanoveno, Handly se již používá ve dvou velkých komerčních produktech, které se odvážily stát se „brzkými adoptery“ a zatím nelitují.
Jak již bylo zmíněno, jedním z těchto produktů jsou 1C:Enterprise Development Tools, kde se Handly od samého začátku používá k modelování prvků vysoce úrovňové struktury jazyků 1C:Enterprise, jako je vestavěný programovací jazyk a jazyk dotazů. Druhý produkt je méně znám široké veřejnosti. Je to , integrované prostředí pro návrh procesorů cíleného zaměření (application-specific instruction-set processor, ASIP), používané jak uvnitř samotné české společnosti Codasip, tak jejími klienty, mezi kterými jsou , , , Codasip používá Handly v produkci od roku 2015, počínaje verzí Handly 0.2. Poslední verze Codasip Studio aktuálně využívá verzi 0.5, která byla uvedena na trh v červnu 2016. Ondřej Ilčík, vedoucí vývoje IDE v Codasip, je v kontaktu s projektem a poskytuje velmi důležitou zpětnou vazbu jako "externí adaptér". Dokonce se mu podařilo najít trochu volného času, aby se přímo podílel na vývoji projektu, a to implementací vrstvy UI (~ 4000 řádků kódu) pro jeden z příkladů Handly, model Java. Podrobnější informace "z první ruky" o používání Handly adaptérům lze získat na stránce projektu.
Doufáme, že po vydání verze 1.0 s garancí stability API a po ukončení inkubační fáze se Handly dočká nových adaptérů. Zatím projekt pokračuje ve stabilizaci a dalším vylepšování API, vydávající dva "velké" releasy ročně – v červnu (ve stejný den jako současný release Eclipse) a v prosinci, čímž zajišťuje předvídatelný harmonogram, na který se mohou adapteri spolehnout. Dále lze zmínit, že míra "chybných hlášení" projektu zůstává na stabilně nízké úrovni a Handly od prvních verzí spolehlivě funguje v produktech raných adapterů. Pro další seznámení s Eclipse Handly lze využít a .
Zdroj: habr.com
