Možno, už dávno nepotrebuje špeciálne predstavovanie. Mnoho ľudí pozná Eclipse vďaka vývojovým nástrojom Eclipse Java (). Práve toto populárne open-source Java IDE si väčšina vývojárov spája so slovom „Eclipse“. Eclipse je však rozšíriteľná platforma na integráciu vývojových nástrojov (Eclipse Platform) a množstvo IDE postavených na jej základe, vrátane JDT. Eclipse je projekt Eclipse, projekt najvyššej úrovne, ktorý koordinuje vývoj platformy Eclipse a JDT, ako aj Eclipse SDK, ktorý je výsledkom tohto vývoja. Nakoniec, Eclipse je open-source nadácia s obrovskou komunitou projektov, z ktorých nie všetky sú napísané v jazyku Java alebo súvisia s vývojovými nástrojmi (napríklad projekty и ). Svet Eclipse je veľmi rozmanitý.
V tomto článku, ktorý je svojou povahou prehľadný, sa pokúsime pozrieť na niektoré základy architektúry Eclipse ako platformy na vytváranie integrovaných vývojových nástrojov a poskytnúť úvodnú predstavu o komponentoch Eclipse, ktoré tvoria základ technológie. platforma pre „nový konfigurátor“ 1C: Enterprise. . Samozrejme, takáto recenzia bude nevyhnutne do značnej miery povrchná a dosť obmedzená, a to aj preto, že sa nezameriavame len na vývojárov Eclipse ako cieľové publikum. Dúfame však, že zaujímavé informácie v článku nájdu aj skúsení vývojári Eclipse. Napríklad budeme hovoriť o jednom z „tajomstiev Eclipse“, relatívne novom a málo známom projekte , ktorú založila a podporuje 1C.
Úvod do architektúry Eclipse
Najprv sa pozrime na niektoré všeobecné aspekty architektúry Eclipse pomocou príkladu (JDT). Výber JDT ako príkladu nie je náhodný. Toto je prvé integrované vývojové prostredie, ktoré sa objavilo v Eclipse. Ďalšie projekty *DT Eclipse, ako napríklad Eclipse C/C++ Development Tooling (CDT), boli vytvorené neskôr a prepožičali si základné architektonické princípy a jednotlivé fragmenty zdrojového kódu z JDT. Základy architektúry stanovené v JDT sú dodnes relevantné pre takmer každé IDE postavené na platforme Eclipse, vrátane 1C:Enterprise Development Tools.
V prvom rade je potrebné poznamenať, že Eclipse sa vyznačuje pomerne jasným architektonickým vrstvením, oddelením funkcií nezávislých od jazyka od funkcií určených na podporu špecifických programovacích jazykov a oddelením „jadrových“ komponentov nezávislých od používateľského rozhrania od komponentov súvisiacich s podporným užívateľským rozhraním.
Platforma Eclipse teda definuje spoločnú, jazykovo nezávislú infraštruktúru a vývojové nástroje Java pridávajú do Eclipse plnohodnotné Java IDE. Platforma Eclipse aj JDT pozostávajú z niekoľkých komponentov, z ktorých každý patrí buď do „jadra“ nezávislého od používateľského rozhrania alebo do vrstvy používateľského rozhrania (obrázok 1).
Ryža. 1. Eclipse Platform a JDT
Uveďme si hlavné komponenty platformy Eclipse:
- Runtime — Definuje infraštruktúru doplnkov. Eclipse sa vyznačuje modulárnou architektúrou. Eclipse je v podstate zbierka „bodov rozšírenia“ a „rozšírení“.
- Pracovný priestor — Riadi jeden alebo viac projektov. Projekt pozostáva z priečinkov a súborov, ktoré sú namapované priamo na súborový systém.
- Standard Widget Toolkit (SWT) - Poskytuje základné prvky používateľského rozhrania integrované s operačným systémom.
- JFace — Poskytuje množstvo rámcov používateľského rozhrania postavených na SWT.
- Workbench — Definuje paradigmu používateľského rozhrania Eclipse: editory, pohľady, perspektívy.
Je potrebné povedať, že platforma Eclipse poskytuje aj mnoho ďalších užitočných komponentov na budovanie integrovaných vývojových nástrojov vrátane Debug, Compare, Search a Team. Osobitne treba spomenúť JFace Text – základ pre vytváranie „inteligentných editorov“ zdrojového kódu. Žiaľ, ani zbežné preskúmanie týchto komponentov, ako aj komponentov vrstvy používateľského rozhrania, nie je možné v rámci tohto článku, takže v zostávajúcej časti tejto časti sa obmedzíme na prehľad hlavných „jadrových“ komponentov platformy Eclipse a JDT.
Core Runtime
Infraštruktúra doplnku Eclipse je založená na a poskytuje projekt . Každý doplnok Eclipse je balík OSGi. Špecifikácia OSGi definuje najmä mechanizmy na vytváranie verzií a riešenie závislostí. Okrem týchto štandardných mechanizmov Equinox predstavuje koncept expanzné body. Každý doplnok môže definovať svoje vlastné body rozšírenia a tiež zaviesť do systému ďalšie funkcie („rozšírenia“) pomocou bodov rozšírenia definovaných rovnakými alebo inými zásuvnými modulmi. Akýkoľvek podrobný popis mechanizmov OSGi a Equinox je nad rámec tohto článku. Všimnime si len, že modularizácia v Eclipse je úplná (akýkoľvek subsystém, vrátane Runtime, pozostáva z jedného alebo viacerých pluginov) a takmer všetko v Eclipse je rozšírenie. Navyše, tieto princípy boli zakotvené v architektúre Eclipse dávno pred zavedením OSGi (v tom čase používali vlastnú technológiu, veľmi podobnú OSGi).
Základný pracovný priestor
Takmer každé integrované vývojové prostredie postavené na platforme Eclipse funguje s pracovným priestorom Eclipse. Je to pracovný priestor, ktorý zvyčajne obsahuje zdrojový kód aplikácie vyvinutej v IDE. Pracovný priestor sa mapuje priamo do systému súborov a pozostáva z projektov, ktoré obsahujú priečinky a súbory. Tieto projekty, priečinky a súbory sa nazývajú zdrojov pracovnom priestore. Implementácia pracovného priestoru v Eclipse slúži ako vyrovnávacia pamäť vo vzťahu k súborovému systému, čo umožňuje výrazne urýchliť prechádzanie stromom zdrojov. Okrem toho pracovný priestor poskytuje množstvo doplnkových služieb, napr и .
Komponent Core Resources (org.eclipse.core.resources plugin) je zodpovedný za podporu pracovného priestoru a jeho zdrojov. Tento komponent poskytuje najmä programový prístup k pracovnému priestoru vo formulári zdrojových modelov. Na efektívnu prácu s týmto modelom potrebujú klienti jednoduchý spôsob, ako prezentovať odkaz na zdroj. V tomto prípade by bolo žiaduce skryť objekt, ktorý priamo ukladá stav zdroja v modeli, pred klientskym prístupom. V opačnom prípade, napríklad v prípade vymazania súboru, by klient mohol naďalej držať objekt, ktorý už nie je v modeli, s následnými problémami. Eclipse tento problém rieši pomocou tzv rukoväť zdroj. Handle funguje ako kľúč (pozná iba cestu k zdroju v pracovnom priestore) a úplne riadi prístup k objektu interného modelu, ktorý priamo ukladá informácie o stave zdroja. Tento dizajn je variáciou vzoru .
Ryža. Obrázok 2 ilustruje idióm Handle/Telo aplikovaný na model zdrojov. Rozhranie IResource predstavuje rukoväť prostriedku a je API, na rozdiel od triedy Resource, ktorá implementuje toto rozhranie, a triedy ResourceInfo, ktorá predstavuje telo, ktoré nie sú API. Zdôrazňujeme, že handle pozná iba cestu k prostriedku relatívne ku koreňu pracovného priestoru a neobsahuje prepojenie na informácie o zdroji. Objekty informácií o zdrojoch tvoria takzvaný „strom prvkov“. Táto dátová štruktúra je úplne zhmotnená v pamäti. Na nájdenie inštancie informácií o zdroji zodpovedajúcej handle sa strom elementov prejde podľa cesty uloženej v tomto handle.
Ryža. 2. IResource a ResourceInfo
Ako uvidíme neskôr, základný dizajn modelu zdrojov (môžeme ho nazvať založený na rukoväti) sa v Eclipse používa aj pre iné modely. Zatiaľ si uveďme niektoré z charakteristických vlastností tohto dizajnu:
- Rukoväť je hodnotový objekt. Hodnotové objekty sú nemenné objekty, ktorých rovnosť nie je založená na identite. Takéto predmety možno bezpečne použiť ako kľúč v hašovaných kontajneroch. Viaceré inštancie handle môžu odkazovať na rovnaký zdroj. Ak ich chcete porovnať, musíte použiť metódu equals(Object).
- Handle definuje správanie sa zdroja, ale neobsahuje informácie o stave zdroja (jediné dáta, ktoré ukladá, je „kľúč“, cesta k zdroju).
- Handle môže odkazovať na zdroj, ktorý neexistuje (buď zdroj, ktorý ešte nebol vytvorený, alebo zdroj, ktorý už bol odstránený). Existenciu zdroja je možné skontrolovať pomocou metódy IResource.exists().
- Niektoré operácie môžu byť implementované výlučne na základe informácií uložených v samotnej rukoväti (takzvané len manipulačné operácie). Príkladmi sú IResource.getParent(), getFullPath() atď. Aby takáto operácia bola úspešná, zdroj nemusí existovať. Operácie, ktoré si vyžadujú existenciu zdroja, aby uspeli, vyhodia CoreException, ak zdroj neexistuje.
Eclipse poskytuje efektívny mechanizmus na oznamovanie zmien zdrojov pracovného priestoru (obrázok 3). Zdroje sa môžu meniť buď v dôsledku akcií vykonaných v samotnom IDE Eclipse alebo v dôsledku synchronizácie so súborovým systémom. V oboch prípadoch klienti, ktorí sa prihlásia na odber upozornení, dostanú podrobné informácie o zmenách vo forme „rozdiely zdrojov“. Delta popisuje zmeny medzi dvoma stavmi zdrojového (pod)stromu pracovného priestoru a je sama osebe stromom, ktorého každý uzol popisuje zmenu zdroja a obsahuje zoznam rozdielov na ďalšej úrovni, ktoré popisujú zmeny podriadených zdrojov.
Ryža. 3. IResourceChangeEvent a IResourceDelta
Mechanizmus oznamovania založený na rozdieloch zdrojov má tieto charakteristiky:
- Jedna zmena a mnohé zmeny sú opísané pomocou rovnakej štruktúry, pretože delta je postavená na princípe rekurzívneho zloženia. Klienti predplatiteľov môžu spracovať oznámenia o zmene prostriedkov pomocou rekurzívneho zostupu cez strom delt.
- Delta obsahuje úplné informácie o zmenách zdroja vrátane jeho pohybu a/alebo zmien v „značkách“ s ním spojených (napríklad chyby kompilácie sú reprezentované ako značky).
- Keďže odkazy na prostriedky sa robia cez rukoväť, delta môže prirodzene odkazovať na vzdialený zdroj.
Ako čoskoro uvidíme, hlavné komponenty návrhu mechanizmu oznamovania zmeny modelu zdrojov sú relevantné aj pre iné modely založené na rukoväti.
Jadro JDT
Model zdrojov pracovného priestoru Eclipse je základným modelom bez jazykovej agnostiky. Komponent JDT Core (plugin org.eclipse.jdt.core) poskytuje API na navigáciu a analýzu štruktúry pracovného priestoru z pohľadu Java, takzvaný „Java model“ (Java model). Toto API je definované z hľadiska prvkov Java, na rozdiel od základného API modelu zdrojov, ktoré je definované z hľadiska priečinkov a súborov. Hlavné rozhrania stromu prvkov Java sú znázornené na obr. 4.
Ryža. 4. Prvky modelu Java
Model Java používa rovnaký výraz handle/body ako model zdrojov (obrázok 5). IJavaElement je rukoväť a JavaElementInfo hrá úlohu tela. Rozhranie IJavaElement definuje protokol spoločný pre všetky prvky Java. Niektoré z jeho metód sú iba na obsluhu: getElementName(), getParent() atď. Objekt JavaElementInfo ukladá stav zodpovedajúceho prvku: jeho štruktúru a atribúty.
Ryža. 5. IJavaElement a JavaElementInfo
Java model má určité rozdiely v implementácii základného dizajnu rukoväte/tela v porovnaní s modelom zdrojov. Ako je uvedené vyššie, v modeli zdrojov je strom elementov, ktorého uzly sú informačné objekty zdrojov, úplne obsiahnutý v pamäti. Ale Java model môže mať podstatne väčší počet prvkov ako zdrojový strom, pretože predstavuje aj vnútornú štruktúru súborov .java a .class: typy, polia a metódy.
Aby sa predišlo úplnému zhmotneniu celého stromu prvkov v pamäti, implementácia modelu Java používa obmedzenú veľkosť vyrovnávacej pamäte LRU informácií o prvku, kde kľúčom je handle IJavaElement. Informácie o prvkoch sa vytvárajú na požiadanie pri navigácii v strome prvkov. V tomto prípade sú z vyrovnávacej pamäte vyradené najmenej používané položky a spotreba pamäte modelu zostáva obmedzená na zadanú veľkosť vyrovnávacej pamäte. Toto je ďalšia výhoda dizajnu založeného na rukoväti, ktorý úplne skryje takéto detaily implementácie z kódu klienta.
Mechanizmus oznamovania zmien prvkov Java je vo všeobecnosti podobný mechanizmu sledovania zmien zdrojov pracovného priestoru, o ktorom sme hovorili vyššie. Klient, ktorý chce monitorovať zmeny v modeli Java, sa prihlási na odber upozornení, ktoré sú reprezentované ako objekt ElementChangedEvent, ktorý obsahuje IJavaElementDelta (obrázok 6).
Ryža. 6. ElementChangedEvent a IJavaElementDelta
Model Java neobsahuje informácie o telách metód ani o rozlíšení názvov, takže pre podrobnú analýzu kódu napísaného v jazyku Java poskytuje JDT Core ďalší model (nezaložený na rukoväti): (strom abstraktnej syntaxe, AST). AST predstavuje výsledok analýzy zdrojového textu. Uzly AST zodpovedajú prvkom štruktúry zdrojového modulu (deklarácie, operátory, výrazy atď.) a obsahujú informácie o súradniciach zodpovedajúceho prvku v zdrojovom texte, ako aj (voliteľne) informácie o rozlíšení názvu v formou odkazov na tzv väzby. Väzby sú objekty, ktoré predstavujú pomenované entity, ako sú typy, metódy a premenné, známe kompilátoru. Na rozdiel od uzlov AST, ktoré tvoria strom, väzby podporujú krížové odkazy a vo všeobecnosti tvoria graf. Abstraktná trieda ASTNode je spoločná základná trieda pre všetky uzly AST. Podtriedy ASTNode zodpovedajú špecifickým syntaktickým konštruktom jazyka Java.
Pretože stromy syntaxe môžu spotrebovať značné množstvo pamäte, JDT ukladá do vyrovnávacej pamäte iba jeden AST pre aktívny editor. Na rozdiel od modelu Java sa AST zvyčajne považuje za „stredný“, „dočasný“ model, na prvky ktorého by klienti nemali odkazovať mimo kontextu operácie, ktorá viedla k vytvoreniu AST.
Uvedené tri modely (Java model, AST, väzby) spolu tvoria základ pre budovanie „inteligentných vývojových nástrojov“ v JDT, vrátane výkonného Java editora s rôznymi „pomocníkmi“, rôznymi akciami na spracovanie zdrojového kódu (vrátane organizácie zoznamu importovaných názvy a formátovanie podľa prispôsobeného štýlu), nástroje na vyhľadávanie a refaktorovanie. V tomto prípade zohráva osobitnú úlohu Java model, pretože práve on sa používa ako základ pre vizuálnu reprezentáciu štruktúry vyvíjanej aplikácie (napríklad v Package Explorer, Outline, Search, Call Hierarchy a Hierarchia typov).
Komponenty Eclipse používané v nástrojoch 1C:Enterprise Developments Tools
Na obr. Obrázok 7 zobrazuje komponenty Eclipse, ktoré tvoria základ technologickej platformy pre 1C:Enterprise Development Tools.
Ryža. 7. Eclipse ako platforma pre 1C:Enterprise Development Tools
Platforma Eclipse poskytuje základnú infraštruktúru. Na niektoré aspekty tejto infraštruktúry sme sa pozreli v predchádzajúcej časti.
(EMF) poskytuje všeobecný prostriedok na modelovanie štruktúrovaných údajov. EMF je integrovaný s platformou Eclipse, ale dá sa použiť aj samostatne v bežných Java aplikáciách. Pomerne často sú noví vývojári Eclipse už dobre oboznámení s EMF, hoci ešte úplne nerozumejú zložitosti platformy Eclipse. Jedným z dôvodov takejto zaslúženej popularity je univerzálny dizajn, ktorý okrem iného zahŕňa jednotné metaúrovňové API, ktoré umožňuje pracovať s akýmkoľvek EMF modelom všeobecne. Základné implementácie pre modelové objekty poskytované EMF a subsystémom na generovanie kódu modelu na základe meta-modelu výrazne zvyšujú rýchlosť vývoja a znižujú počet chýb. EMF tiež obsahuje mechanizmy na serializáciu modelov, sledovanie zmien v modeli a oveľa viac.
Ako každý skutočne univerzálny nástroj, EMF je vhodný na riešenie širokej škály problémov modelovania, ale niektoré triedy modelov (napríklad modely založené na rukoväti diskutované vyššie) môžu vyžadovať špecializovanejšie modelovacie nástroje. Hovoriť o EMP je nevďačná úloha, najmä v rámci obmedzených hraníc jedného článku, pretože toto je téma na samostatnú a dosť obsiahlu knihu. Pripomeňme len, že kvalitný systém zovšeobecnení, z ktorých vychádza EMF, umožnil zrodenie celého radu projektov venovaných modelovaniu, ktoré sú zaradené do projektu najvyššej úrovne. spolu so samotným EMF. Jedným z takýchto projektov je Eclipse Xtext.
poskytuje infraštruktúru „textového modelovania“. Xtext používa na analýzu zdrojového textu a EMF na reprezentáciu výsledného ASG (abstraktný sémantický graf, ktorý je v podstate kombináciou AST a väzieb), nazývaný aj „sémantický model“. Gramatika jazyka modelovaného Xtextom je opísaná vo vlastnom jazyku Xtextu. To vám umožňuje nielen vygenerovať popis gramatiky pre ANTLR, ale aj získať mechanizmus serializácie AST (t. j. Xtext poskytuje parser aj unparser), kontextovú nápovedu a množstvo ďalších jazykových komponentov. Na druhej strane, gramatický jazyk používaný v Xtexte je menej flexibilný ako povedzme gramatický jazyk používaný v ANTLR. Preto je niekedy potrebné implementovaný jazyk „ohnúť“ na Xtext, čo zvyčajne nie je problém, ak hovoríme o jazyku vyvíjanom od nuly, ale môže byť neprijateľné pre jazyky s už zavedenou syntaxou. Napriek tomu je Xtext v súčasnosti najvyspelejším, najbohatším a najuniverzálnejším nástrojom v Eclipse na vytváranie programovacích jazykov a vývojových nástrojov pre ne. Ide najmä o ideálny nástroj na rýchle prototypovanie (jazyk špecifický pre doménu, DSL). Okrem vyššie uvedeného „jazykového jadra“ založeného na ANTLR a EMF poskytuje Xtext mnoho užitočných komponentov vyššej úrovne, vrátane mechanizmov indexovania, prírastkovej konštrukcie, „inteligentného editora“ a oveľa, oveľa viac, ale vynecháva rukoväte- založené jazykové modely. Podobne ako EMF, aj Xtext je téma hodná samostatnej knihy a o všetkých jeho schopnostiach sa teraz sotva môžeme stručne porozprávať.
Nástroje 1C:Enterprise Development Tools aktívne využívajú samotné EMF a množstvo ďalších projektov Eclipse Modeling. Najmä Xtext je jedným zo základov vývojových nástrojov pre také jazyky 1C:Enterprise ako vstavaný programovací jazyk a jazyk dotazov. Ďalším základom týchto vývojových nástrojov je projekt Eclipse Handly, ktorému sa budeme venovať podrobnejšie (z vymenovaných komponentov Eclipse je zatiaľ najmenej známy).
, podprojekt projektu najvyššej úrovne Eclipse Technology, vznikol ako výsledok počiatočného príspevku kódu do nadácie Eclipse, ktorý spoločnosť 1C urobila v roku 2014. Odvtedy 1C naďalej podporuje vývoj projektu: Handly Committers sú zamestnanci spoločnosti. Projekt je malý, ale v Eclipse zaberá pomerne jedinečnú medzeru: jeho hlavným cieľom je podporovať vývoj modelov na báze rukoväte.
Základné architektonické princípy modelov založených na rukoväti, ako je idióm rukoväť/telo, boli diskutované vyššie s použitím modelu zdrojov a modelu Java ako príkladov. Tiež poznamenal, že model zdrojov aj model Java sú dôležitými základmi pre vývojové nástroje Eclipse Java (JDT). A keďže takmer všetky projekty *DT Eclipse majú architektúru podobnú JDT, nebolo by veľkým preháňaním povedať, že modely založené na rukovätiach sú základom mnohých, ak nie všetkých IDE postavených na platforme Eclipse. Napríklad Eclipse C/C++ Development Tooling (CDT) má model C/C++ založený na rukoväti, ktorý hrá rovnakú úlohu v architektúre CDT ako model Java v JDT.
Pred Handlym Eclipse neponúkal špecializované knižnice na vytváranie jazykových modelov založených na rukoväti. Modely, ktoré v súčasnosti existujú, boli vytvorené hlavne priamou úpravou kódu modelu Java (aka kopírovať/prilepiť), v prípadoch, keď to umožňuje Eclipse Public License (EPL). (Je zrejmé, že to zvyčajne nie je právny problém, povedzme, pre samotné projekty Eclipse, ale nie pre produkty s uzavretým zdrojovým kódom.) Okrem svojej prirodzenej náhodnosti táto technika prináša aj dobre známe problémy: duplikáciu kódu, ktorú spôsobuje pri prispôsobovaní sa chybám, atď. Horšie je, že výsledné modely zostávajú „vecami samy osebe“ a nevyužívajú potenciál zjednotenia. Izolácia bežných konceptov a protokolov pre jazykové modely založené na rukoväti by však mohla viesť k vytvoreniu opakovane použiteľných komponentov na prácu s nimi, podobne ako sa to stalo v prípade EMF.
Nie je to tak, že by Eclipse týmto problémom nerozumel. Ešte v roku 2005 , zhŕňajúc skúsenosti s vývojom prototypu CDT, potreba vytvoriť spoločnú infraštruktúru pre jazykové modely vrátane modelov založených na rukoväti. Ale, ako sa často stáva, kvôli úlohám s vyššou prioritou sa implementácia týchto nápadov nikdy nedostala k tomu. Medzitým je faktorizácia kódu *DT stále jednou z málo rozvinutých tém v Eclipse.
V určitom zmysle je projekt Handly navrhnutý tak, aby riešil približne rovnaké problémy ako EMF, ale pre modely založené na rukoväti a predovšetkým jazykové (t. j. reprezentujúce prvky štruktúry nejakého programovacieho jazyka). Hlavné ciele stanovené pri navrhovaní Handly sú uvedené nižšie:
- Identifikácia hlavných abstrakcií predmetnej oblasti.
- Zníženie úsilia a zlepšenie kvality implementácie jazykových modelov založených na rukoväti prostredníctvom opätovného použitia kódu.
- Poskytnutie jednotného metaúrovňového API pre výsledné modely, čo umožňuje vytvárať spoločné komponenty IDE, ktoré pracujú s modelmi založenými na ovládaní jazyka.
- Flexibilita a škálovateľnosť.
- Integrácia s Xtextom (v samostatnej vrstve).
Aby sa zdôraznili spoločné koncepty a protokoly, analyzovali sa existujúce implementácie modelov založených na ovládaní jazyka. Hlavné rozhrania a základné implementácie poskytované spoločnosťou Handly sú znázornené na obr. 8.
Ryža. 8. Spoločné rozhrania a základné implementácie prvkov Handly
Rozhranie IElement predstavuje rukoväť prvku a je spoločné pre prvky všetkých modelov založených na Handly. Abstraktná trieda Element implementuje zovšeobecnený mechanizmus rukoväť/telo (obr. 9).
Ryža. 9. IElement a generická implementácia rukoväte/tela
Okrem toho Handly poskytuje zovšeobecnený mechanizmus na oznamovanie zmien prvkov modelu (obr. 10). Ako vidíte, je to v podstate podobné oznamovacím mechanizmom implementovaným v modeli zdrojov a modeli Java a používa IElementDelta na poskytovanie jednotnej reprezentácie informácií o zmenách prvkov.
Ryža. 10. Všeobecné rozhrania a základné implementácie oznamovacieho mechanizmu Handly
Časť Handly diskutovaná vyššie (obr. 9 a 10) môže byť použitá na reprezentáciu takmer všetkých modelov založených na rukoväti. Na tvorenie lingvistické modelov, projekt ponúka doplnkovú funkcionalitu - najmä bežné rozhrania a základné implementácie pre prvky štruktúry zdrojového textu, tzv. zdrojové prvky (obr. 8). Rozhranie ISourceFile predstavuje zdrojový súbor a ISourceConstruct predstavuje prvok v zdrojovom súbore. Abstraktné triedy SourceFile a SourceConstruct implementujú zovšeobecnené mechanizmy na podporu práce so zdrojovými súbormi a ich prvkami, napríklad prácu s textovými vyrovnávacími pamäťami, viazanie na súradnice prvku v zdrojovom texte, zosúladenie modelov s aktuálnym obsahom vyrovnávacej pamäte pracovnej kópie. , atď. Implementácia týchto mechanizmov je zvyčajne dosť náročná a Handly môže výrazne znížiť námahu pri vývoji jazykových modelov založených na rukoväti poskytnutím vysokokvalitných základných implementácií.
Okrem základných mechanizmov uvedených vyššie poskytuje Handly infraštruktúru pre textové vyrovnávacie pamäte a snímky, podporu integrácie s editormi zdrojového kódu (vrátane integrácie s editorom Xtext), ako aj niektoré bežné komponenty používateľského rozhrania, ktoré práca s editormi zdrojového kódu.Príručné modely, ako je napríklad rámec osnovy. Na ilustráciu svojich možností projekt poskytuje niekoľko príkladov, vrátane implementácie modelu Java v Handly. (V porovnaní s úplnou implementáciou modelu Java v JDT je tento model zámerne trochu zjednodušený kvôli väčšej prehľadnosti.)
Ako už bolo spomenuté vyššie, hlavným zameraním počas počiatočného návrhu a následného vývoja spoločnosti Handly bolo a naďalej bude škálovateľnosť a flexibilita.
V zásade sa modely na báze rukoväte celkom dobre škálujú „podľa návrhu“. Napríklad idióm rukoväť/telo vám umožňuje obmedziť množstvo pamäte spotrebovanej modelom. Ale sú tu aj nuansy. Pri testovaní Handly na škálovateľnosť sa teda objavil problém v implementácii notifikačného mechanizmu – pri zmene veľkého množstva prvkov zabralo zostrojenie delt príliš veľa času. Ukázalo sa, že rovnaký problém bol prítomný v modeli JDT Java, z ktorého bol kedysi prispôsobený zodpovedajúci kód. Opravili sme chybu v Handly a pripravili podobnú opravu pre JDT, ktorá bola vďačne prijatá. Toto je len jeden príklad, kedy by zavedenie Handly do existujúcich implementácií modelu mohlo byť potenciálne užitočné, pretože v tomto prípade by sa takáto chyba dala opraviť len na jednom mieste.
Aby bola implementácia Handly do existujúcich implementácií modelu technicky uskutočniteľná, knižnica musí mať značnú flexibilitu. Hlavným problémom je zachovať spätnú kompatibilitu naprieč modelom API. Tento problém bol vyriešený v r jasným oddelením API špecifického pre model, definovaného a plne kontrolovaného vývojárom, od zjednoteného metaúrovňového API, ktoré poskytuje knižnica. To nielenže umožňuje technicky implementovať Handly do existujúcich implementácií, ale tiež dáva vývojárovi nového modelu značnú slobodu pri navrhovaní API.
Flexibilita má aj iné aspekty. Napríklad Handly nekladie takmer žiadne obmedzenia na štruktúru modelu a možno ho použiť na modelovanie všeobecných aj doménovo špecifických jazykov. Pri konštrukcii štruktúry zdrojového súboru Handly nepredpisuje žiadnu konkrétnu formu reprezentácie AST a v zásade ani nevyžaduje prítomnosť samotného AST, čím zabezpečuje kompatibilitu s takmer akýmkoľvek mechanizmom analýzy. Nakoniec, Handly podporuje plnú integráciu s pracovným priestorom Eclipse, ale môže tiež pracovať priamo so súborovými systémami vďaka integrácii s (EFS).
Aktuálna verzia vyšiel v decembri 2016. Napriek tomu, že projekt je momentálne v štádiu inkubácie a API ešte nebolo definitívne opravené, Handly sa už používa v dvoch veľkých komerčných produktoch, ktoré na seba vzali riziko, že budú pôsobiť ako „early adopters“, a musím povedať, zatiaľ neľutujte.
Ako je uvedené vyššie, jedným z týchto produktov sú 1C:Enterprise Development Tools, kde sa Handly používa od samého začiatku na modelovanie prvkov vysokoúrovňovej štruktúry takýchto jazykov 1C:Enterprise ako vstavaného programovacieho jazyka a dotazovacieho jazyka. . Ďalší produkt je širokej verejnosti menej známy. Toto , integrované návrhové prostredie pre aplikačne špecifický inštrukčný procesor (ASIP), používané ako v rámci samotnej českej spoločnosti Codasip, tak aj u jej klientov, napr. , , , . Codasip používa Handly vo výrobe od roku 2015, počnúc verziou Handly 0.2. Najnovšie vydanie Codasip Studio používa verziu 0.5 vydanú v júni 2016. Ondřej Ilčík, ktorý vedie vývoj IDE v spoločnosti Codasip, je v kontakte s projektom a poskytuje dôležitú spätnú väzbu v mene „prijímateľa tretej strany“. Podarilo sa mu dokonca nájsť nejaký voľný čas na priamu účasť na vývoji projektu implementáciou vrstvy používateľského rozhrania (~ 4000 riadkov kódu) pre jeden z príkladov Handly, model Java. Podrobnejšie informácie z prvej ruky o používaní Handly osvojiteľmi nájdete na stránke projektu.
Dúfame, že po vydaní verzie 1.0 s garanciou stability API a opustení projektu z inkubačného stavu bude mať Handly nových osvojiteľov. Medzitým projekt pokračuje v testovaní a ďalšom zdokonaľovaní API, pričom vydáva dve „hlavné“ vydania ročne – v júni (rovnaký dátum ako simultánne vydanie Eclipse) a decembri, čo poskytuje predvídateľný harmonogram, na ktorý sa môžu používatelia spoľahnúť. Môžeme tiež dodať, že „miera chýb“ projektu zostáva na trvalo nízkej úrovni a Handly spoľahlivo funguje v produktoch prvých používateľov už od prvých verzií. Ak chcete ďalej preskúmať Eclipse Handly, môžete použiť и .
Zdroj: hab.com