Eclipse kui tehnoloogia platvorm 1C:Enterprise arendustööriistade jaoks

Ilmselt, Eclipse ei vaja enam erilist tutvustamist. Paljud tunnevad Eclipse'i tänu Eclipse Java arendusvahenditele (JDT). Just see populaarne avatud lähtekoodiga Java IDE seostatakse enamus arendajatega sõnaga “Eclipse”. Kuid Eclipse on ka laiendatav platvorm arendusvahendite integreerimiseks (Eclipse Platform) ning mitmed IDE-d, mis on väljatöötatud selle baasil, sealhulgas JDT. Eclipse on ka Eclipse Project, tippprojekt, mis koordineerib Eclipse Platform ja JDT arendust ning Eclipse SDK – selle arenduse tulemus. Lõpuks on Eclipse avatud allikas sihtasutus, millel on tohutu projektide kogukond, kusjuures mitte kõik need projektid ei ole kirjutatud Java's ega seotud arendusvahenditega (nt projektid Eclipse IoT ja Eclipse Science). Eclipse'i maailm on väga mitmekesine.

Käesolevas artiklis, mis on iseloomult ülevaatlik, proovime arutada mõningaid põhialuseid Eclipse'i arhitekturist kui platvormist integreeritud arendusvahendite loomiseks ja anda esmase ülevaate Eclipse'i komponentidest, mis moodustavad tehnoloogilise platvormi aluse “uuele Konfiguratorile” 1C: Ettevõtte, 1C:Enterprise Development Tools. Loomulikult on selline käsitlus paratamatult osaliselt pinnapealne ja üsna piiratud, sealhulgas seetõttu, et suunatakse mitte ainult Eclipse arendajatele kui sihtrühmale. Siiski loodame, et isegi kogenud Eclipse arendajad suudavad artiklist leida huvitavat teavet. Näiteks räägime ühest “Eclipse'i saladusest”, suhteliselt uuest ja veel vähe tuntud projektist Eclipse Handly, mis on loodud ja toetatud firma 1C.

Sissejuhatus Eclipse'i arhitektuuri

Arutame alguses mõned üldised aspektid Eclipse'i arhitektuurist näitena Eclipse Java arendusvahendid (JDT). JDT valik näitena ei ole juhuslik. See on esimene integreeritud arendus keskkond, mis ilmus Eclipse'is. Teised *DT Eclipse projektid, nagu näiteks Eclipse C/C++ Development Tooling (CDT), loodi hiljem ja laenasid nii põhistruktuurid kui ka eraldi koodifragmente JDT-st. JDT-sse rajatud arhitektuuri alused kehtivad tänapäeval praktiliselt iga IDE puhul, mis on ehitatud Eclipse Platform'i peale, sealhulgas 1C:Enterprise Development Tools jaoks.

Eelkõige tasub märkida, et Eclipse'l on üsna selge arhitektuuriline kihistumine, kus eristatakse keelest sõltumatut funktsionaalsust konkreetsete programmeerimiskeelte toetamise funktsionaalsusest ning eristatakse UI-st sõltumatuid „tuum” komponente komponentidest, mis on seotud kasutajaliidese toe pakkumisega.

Nii määratleb Eclipse Platform üldise, keelest sõltumatu infrastruktuuri, samas kui Java arendustooted lisavad Eclipse'le täieõigusliku Java IDE. Nii Eclipse Platform kui ka JDT koosnevad mitmest komponendist, millest igaüks kuulub kas UI-st sõltumatu „tuuma” või UI kihisse (vt joonis 1).

Joonis 1. Eclipse Platform ja JDT

Loetleme Eclipse Platformi põhikomponendid:

• Runtime — Määratleb pistikprogrammide infrastruktuuri. Eclipse'l on moodulaarne arhitektuur. Põhimõtteliselt on Eclipse kogum „laiendamise punkte” ja „laiendusi”.
• Workspace — Haldab ühte või mitut projekti. Projekt koosneb kaustadest ja failidest, mis kuvatakse otse failisüsteemis.
• Standard Widget Toolkit (SWT) — Pakub baas kasutajaliidese elemente, mis on integreeritud operatsioonisüsteemiga.
• JFace — Pakub mitmeid UI raamistikke, mis on loodud SWT kõrgemale.
• Töölaud — Määratleb Eclipse'i UI paradigmad: redigeerijad, vaated, perspektiivid.

Tasub mainida, et Eclipse Platform pakub ka palju teisi kasulikke komponente integreeritud arendusvahendite loomiseks, sealhulgas Debug, Compare, Search ja Team. Eraldi peaksite pöörama tähelepanu JFace Textile – alusele „nutikate redigeerijate” loomisel. Kahjuks ei ole sellel artiklil võimalust vaadata neid komponente, samuti UI-kihti, seetõttu piirame selle osa ülevaadet Eclipse Platformi ja JDT peamistest „tuuma” komponentidest.

Core Runtime

Eclipse'i pistikprogrammide infrastruktuur põhineb OSGi ja seda pakub projekt Eclipse Equinox.Iga Eclipse'i pistikprogramm on OSGi-bundle. OSGi spetsifikatsioon määratleb muuhulgas versioonimise ja sõltuvuste lahendamise mehhanisme. Lisaks nendele standardsetele mehhanismidele toob Equinox sisse mõiste laiendamise punkt. Iga plugin saab määrata oma laienduspunkte ja tuua süsteemi täiendavat funktsionaalsust ("laiendused"), kasutades selle sama või teiste pluginatega määratud laienduspunkte. Üksikasjalik OSGi ja Equinox mehhanismide kirjeldus ületab selle artikli ulatuse. Tuleb märkida, et Eclipse'i modulariseerimine on põhjalik (iga alamsüsteem, sealhulgas käitusaeg, koosneb ühest või mitmest pluginast) ning praktiliselt kõik Eclipse'is on laiendus. Need põhimõtted olid sisseehitatud Eclipse'i arhitektuuri juba ammu enne OSGi rakendamist (sel ajal kasutati oma tehnoloogiat, mis oli suurte sarnane OSGi-le).

Tuumiku tööruum

Praktiselt iga integreeritud arenduskeskkond, mis on loodud Eclipse'i platvormi põhjal, töötab Eclipse'i tööruumiga. Tööruum sisaldab tavaliselt IDE-s arendatava rakenduse lähtekoodi. Tööruum peegeldab otse failisüsteemi ja koosneb projektidest, mis sisaldavad kaustu ja faile. Need projektid, kaustad ja failid nimetatakse ressurssideks . Tööruumi rakendamine Eclipse'is toimib kui vahemälu failisüsteemi suhtes, mis võimaldab oluliselt kiirendada ressursside puu läbimist. Lisaks pakub tööruum mitmeid täiendavaid teenuseid, sealhulgas ressursside muutuste teavitamise mehhanismi ja inkrementaalsete koostajate infrastruktuuri.

Tööruumi ja selle ressursside eest vastutab komponent Core Resources (plugin org.eclipse.core.resources). Konkreetselt pakub see komponent programmilist juurdepääsu tööruumile kujul ressursside mudel. Selle mudeliga tõhusaks töötamiseks vajavad kliendid lihtsat viisi ressursi viite esitamiseks. Sel juhul oleks soovitav varjata objekt, mis otse hoiab ressursi olekut mudelis, kliendi juurdepääsu eest. Vastasel juhul, näiteks faili kustutamisel, võib klient jätkuvalt hoida objekti, mis ei ole enam mudelis olemas, tekitades sellega seotud probleeme. Eclipse lahendab selle ülesande, kasutades nn handle'i ressursi. Handle toimib võtmena (ta teab ainult teed ressursile tööruumis) ja kontrollib täielikult juurdepääsu mudeli sisemisele objekti, mis otse hoiab teavet ressursi oleku kohta. Antud disain on variatsioon mustrist Handle/Body.

Joonis 2 illustreerib Handle/Body idioomi ressursimudeli kontekstis. IResource liides esindab ressursi handle'it ja on API, erinevalt Resource klassist, mis rakendab seda liidest, ning ResourceInfo klassist, mis esindab body't ja ei ole API. Tõstame esile, et handle teab vaid tee ressursini võrreldes workspace'i juurega ega hoia endas viidet resource info'le. Resource info objektid moodustavad nn "elementide puu" (element tree). See andmestruktuur on täielikult mälus materialiseeritud. Korrektse resource info eksemplari leidmiseks, mis vastab mõnele handle'ile, käiakse element tree'd üle vastavalt sellele handle'ist salvestatud teele.

Joonis 2. IResource ja ResourceInfo

Nagu me hiljem näeme, kasutatakse ressursimudeli põhistruktuuri (mida võib nimetada handle-põhiseks) ka Eclipse'is ja teiste mudelite puhul. Praegu toome välja mõned sellele disainile iseloomulikud omadused:

• Handle on väärtusobjekt (value object). Väärtusobjektid on immutable objektid, mille võrdsus ei põhine identiteedil. Selliseid objekte saab ohutult kasutada võtmetena hashitud konteinerites. Mitmed handle'i eksemplarid võivad viidata samale ressursile. Nende võrdlemiseks tuleb kasutada meetodit equals(Object).
• Handle määratleb ressursi käitumise, kuid ei hoia ressursi olekuteavet (ainukesed andmed, mida ta hoiab, on "võti", tee ressursini).
• Handle võib viidata mitteeksisteerivale ressursile (kas ressursile, mida veel ei ole loodud, või ressursile, mis on juba eemaldatud). Ressursi olemasolu saab kontrollida meetodi IResource.exists() abil.
• Mõned operatsioonid võivad põhineda ainult informatsioonil, mis on salvestatud ise handle'i (nn handle-only operatsioonid). Näiteks on IResource.getParent(), getFullPath jne. Ressurss ei pea tingimata eksisteerima sellise operatsiooni edukaks teostamiseks. Operatsioonid, milleks on vajalik ressursi olemasolu, viskavad erandi (CoreException), kui ressurs ei eksisteeri.

Eclipse pakub tõhusat mehhanismi workspace'i ressursside muudatuste teavitamiseks (vt joonis 3). Ressursse võib muuta nii Eclipse IDE enda tegevuste kaudu kui ka failisüsteemiga sünkroniseerimise käigus. Mõlemal juhul antakse teavitustele registreerunutele üksikasjalik teave muudatuste kohta "ressursi delta" vormis. Delta kirjeldab muutusi kahe oleku (al-)puu vahel ja on ise puu, mille iga sõlm kirjeldab mõne ressursi muudatust ja sisaldab loendit järgmise taseme deltadest, mis kirjeldavad alamressursside muudatusi.

Joonis 3. IResourceChangeEvent ja IResourceDelta

Ressursidelt poolt välja töötatud teavituste mehhanism omab järgmisi omadusi:

• Ühtne muudatus ja mitu muudatust kirjeldatakse sama struktuuri kaudu, kuna delta ehitatakse rekursiivse koostamise põhimõtte kohaselt. Klientide tellijad saavad hallata ressursimuudatuste teavitusi, järgides delta puu rekursiivset allakäiku.
• Delta sisaldab täielikku teavet ressursi muudatuse kohta, sealhulgas selle edasiviimist ja/või sellega seotud "markerite" muudatusi (millena esitatakse näiteks kompileerimise vead).
• Kuna viidatakse ressurssidele käsitsemise kaudu, saab delta loomulikult viidata eemalolevale ressursile.

Kuid nagu me peagi näeme, on ressursside mudeli muudatuste teavitamise mehhanismi peamised koostisosad asjakohased ka muude käsitsemise mehaanika mudelite jaoks.

JDT Core

Eclipse workspace'i ressursside mudel on põhiseadmeline keele- sõltumatu mudel. JDT Core komponent (plugin org.eclipse.jdt.core) pakub API-t workspace'i struktuuri navigatsiooniks ja analüüsiks Java perspektiivist, nii nimetatud "Java mudel" (Java model). See API on määratletud Java elementide terminoloogiaga, erinevalt ressursside mudeli põhisisust API-st, mis on määratletud kaustade ja failide mõistes. Java elementide puu põhiinterfacid on kujutatud joonisel 4.

Joonis 4. Java mudeli elemendid

Java mudel kasutab sama handle/body idiomi nagu ressursside mudel (joonis 5). IJavaElement on handle ja JavaElementInfo mängib body rolli. IJavaElementliides määratleb protokolli, mis on ühine kõikidele Java elementidele. Mõned selle meetoditest on ainult handle'i põhised: getElementName(), getParent() jne. JavaElementInfo objekt salvestab vastava elemendi oleku: selle struktuuri ja atribuudid.

Joonis 5. IJavaElement ja JavaElementInfo

Java mudelil on mõned erinevused handle/body põhikujunduse rakenduses võrreldes ressursside mudeliga. Nagu eespool mainitud, on ressursside mudeli elementide puu, mille sõlmedeks on resource info objektid, täielikult mälus. Kuid Java mudelis võib elementide arv olla oluliselt suurem kui ressursside puus, kuna see hõlmab ka .java ja .class failide sisemist struktuuri: tüübid, väljad ja meetodid.

Kogu elementide puu täielik materialiseerimine mälus vältimiseks kasutab Java mudeli rakendus piiratud suurusega LRU-cache element info jaoks, kus võtmena on IJavaElement handle. Element info objekte luuakse nõudmisel, kui toimub navigatsioon elementide puus. Samuti tõrjutakse harva kasutatud elemendid vahelt, hoides mälutarbimist mudeli jaoks määratud kassa suurusega. See on veel üks eelis handle-põhisest disainist, mis varjab sellised rakenduse üksikasjad täielikult kliendikoodilt.

Java elementide muutmise teavitamise mehhanism on üldjoontes sarnane ülaltoodud ressursside tööruumi muutuste jälgimise mehhanismiga. Klient, kes soovib jälgida Java mudelis toimuvaid muudatusi, registreerib end teavituste saamiseks, mis esitatakse ElementChangedEvent objekti kujul, mis sisaldab IJavaElementDelta (joonis 6).

Joonis 6. ElementChangedEvent ja IJavaElementDelta

Java mudel ei sisalda teavet meetodite kehade või nimede lahendamise kohta, seetõttu pakub JDT Core täiendavat (mitte handle-põhist) mudelit Java-koodide üksikasjalikuks analüüsiks: abstraktne süntaksipuu (abstraktne süntaksipuu, AST). AST esindab algteksti süntaktilise analüüsi tulemust. AST sõlmed vastavad lähteaine struktuuri elementidele (deklareerimisele, operaatoritele, avald Pintusele jne) ning sisaldavad teavet vastava elemendi koordinaatide kohta algses tekstis, samuti (valikuliselt) teavet nimede lahendamise kohta, ese viidatud nii-öelda sidemed. Sidemed on objektid, mis esindavad nimetatud entiteete, nagu tüübid, meetodid ja muutujad, mille kohta kompilaatoril on teave. Erinevalt AST sõlmedest, mis moodustavad puu, toetavad sidemed ristviiteid ja tavaliselt moodustavad nad graafi. Abstraktne klass ASTNode on kõigi AST sõlmede ühine aluseks olev klass. ASTNode alamsõlmed vastavad keele Java süntaktilistele konstruktsioonidele.

Kuna süntaktilised puud võivad tarbida märkimisväärselt palju mälu, siis JDT vahemälustab ainult ühte AST-d aktiivse redaktori jaoks. Erinevalt Java mudelist, käsitletakse AST-d tavaliselt kui "vahe-", "ajutist" mudelit, mille elementidele ei tohiks kliendid viidata väljaspool konteksti, milles AST loodi.

Loetletud kolm mudelit (Java mudel, AST, sidemed) koos moodustavad aluse JDT-s "intelligentsete arendustööriistade" loomiseks, sealhulgas võimas Java redaktor koos mitmesuguste "abiainetega", erinevad allika töötlemise toimingud (sealhulgas nimede impordi nimekirja organiseerimine ja vormindamine vastavalt seadistatud stiilile), otsimise ja refaktoreerimise tööriistad. Samal ajal mängib Java mudel erilist rolli, kuna just seda kasutatakse arendatava rakenduse struktuuri visuaalse esitamise aluseks (nt Package Explorer, Outline, Search, Call Hierarchy ja Type Hierarchy).

Eclipse'i komponendid, mida kasutatakse 1C:Enterprise arendusvahendites

Joonisel 7 on näidatud Eclipse'i komponente, mis moodustavad 1C:Enterprise Development Tools tehnoloogilise platvormi aluse.

Joonis 7. Eclipse platvorm 1C:Enterprise Development Tools jaoks

Eclipse platform pakub põhistruktuuri. Oleme käsitlenud mõningaid selle infrastruktuuri aspekte eelnevas jaotises.

Eclipse'i modelleerimisraamistik (EMF) pakub üldisi vahendeid struktureeritud andmete modelleerimiseks. EMF on integreeritud Eclipse Platformiga, kuid seda saab kasutada ka iseseisvalt tavalistes Java rakendustes. Algajad Eclipse arendajad on sageli EMF'ga juba hästi kursis, kuigi nad ei pruugi veel täielikult mõista Eclipse Platformi nüansse. Üks põhjusi, miks see on nii tuntud, on universaalne disain, mis hõlmab ka ühtset API meta-tasandil, mis võimaldab üldiselt töötada iga EMF mudeliga. EMF pakutavad baasteostused mudeliobjektide jaoks ja meta-mudeli põhine mudelikoode genereerimise alam-süsteem suurendavad märkimisväärselt arenduskiirust ja vähendavad vigade arvu. Samuti sisaldab EMF mehhanisme mudelite serialiseerimiseks, mudeli muudatuste jälgimiseks ja palju muud.

Nagu iga tõeliselt universaalne tööriist, sobib EMF laia valiku modelleerimisülesannete lahendamiseks, kuid mõned mudeliklassid (näiteks eespool käsitletud handle-põhised mudelid) võivad vajada spetsiifilisemaid modelleerimisvahendeid. Rääkida EMF'ist on tänamatu ettevõtmine, eriti ühe artikli piirides, kuna see on teema eraldi raamatu jaoks, ja üsna mahuka. Tõstame esile vaid seda, et EMF'i aluseks olev kvaliteetne üldistuste süsteem on võimaldanud luua terve hulga modelleerimisprojekte, mis kuuluvad ülemise taseme projekti. Eclipse Modelleerimine koos EMF'iga. Üks selline projekt on Eclipse Xtext.

Eclipse Xtext pakub 'teksti modelleerimise' infrastruktuuri. Xtext kasutab ANTLR süntaktilise analüüsi jaoks lähteteksti ja EMF-i tulemuse ASG (abstraktse semantilise graafiku, mis sisuliselt on AST ja bind’ide kombinatsioon), mida nimetatakse ka "semantilise mudelina". Xtext abil modelleeritud keele grammatika kirjeldatakse Xtexti omas keeles. See võimaldab mitte ainult genereerida grammatika kirjelduse ANTLR-ile, vaid ka saada AST serialiseerimise mehhanismi (st Xtext pakub nii parserit kui ka unparsereid), konteksti näpunäiteid ja mitmeid teisi keelekomponente. Teisest küljest on Xtextis kasutatav grammatika kirjeldamise keel vähem paindlik võrreldes näiteks ANTLR-i grammatika kirjeldamise keelega. Seetõttu tuleb mõnikord Xtextile külge „painutada” rakendatavat keelt, mis ei ole tavaliselt probleem, kui tegu on nullist arendatava keelega, kuid võib olla vastuvõetamatu juba väljakujunenud süntaksiga keelte puhul. Sellest hoolimata on Xtext praegu kõige küpsem, funktsionaalselt täielik ja universaalne tööriist Eclipse’is programmeerimiskeelte ja nende arendustööriistade loomise jaoks. Eelkõige on see ideaalne vahend kiireks prototüüpimiseks. ainepõhised keeled (domain-specific language, DSL). Peale eelpool mainitud ANTLR ja EMF põhist "keele tuuma" pakub Xtext palju kasulikke kõrgema taseme komponente, sealhulgas indekseerimise mehhanisme, inkrimenteerimise ehitust, "nutikat redigeerijat" ja palju, palju muud, kuid jätab kõrvale keele handle-põhised mudelid. Nagu EMF, on Xtext eraldi raamatu vääriline teema, ja me ei suuda isegi ülevaatlikult rääkida kõigist selle võimalustest.

1C:Enterprise Development Tools kasutavad aktiivselt nii EMF-i iseenesest kui ka mitmeid teisi Eclipse Modeling projekte. Eelkõige on Xtext üks 1C:Ettevõtte arenduskeelte, nagu sisseehitatud programmeerimiskeel ja päringukeel, arendusvahendite aluseid. Teine nende arendusvahendite alus on Eclipse Handly projekt, millele keskendume lähemalt (loetletud Eclipse'i komponentidest on see praegu kõige vähem tuntud).

Eclipse Handly, ülemprojekti Eclipse Technology alaprojekt, sai alguse koodide algsest sisendamisest Eclipse Foundationi, mille viis ellu ettevõte 1C 2014. aastal. Sellest ajast alates jätkab ettevõte 1C projekti arendamise toetamisega: committer'id Handly on ettevõtte töötajad. Projekt on väike, kuid omab üsna unikaalset niši Eclipse'is: selle peamine eesmärk on toetada handle-põhiste mudelite arendamist.

Handle-põhiste mudelite põhistruktuuri põhimõtted, nagu handle/body idiom, on juba varem käsitletud ressursside mudeli ja Java mudeli näitel. Samuti on märgitud, et nii ressursside mudel kui ka Java mudel on olulised aluspõhjad Eclipse Java arendusvahendite (JDT) jaoks. Kuna praktiliselt kõik Eclipse'i *DT projektid järgivad sarnast arhitektuuri nagu JDT, ei ole liialdus öelda, et handle-põhised mudelid kujundavad paljude, kui mitte kõikide Eclipse Platformi peal ehitatud IDE-de aluse. Näiteks Eclipse C/C++ Development Tooling (CDT) sisaldab handle-põhist C/C++ mudelit, mis mängib CDT arhitektuuris sama rolli, mis Java mudel JDT-s.

Enne Handly ilmumist ei pakkunud Eclipse spetsialiseeritud raamatukogusid keeleliste handle-põhiste mudelite loomiseks. Praegu eksisteerivad mudelid on peamiselt loodud Java mudeli koodi otsese kohandamise (a.k.a. copy/paste) abil, neis olukordades, kus see on lubatud Eclipse'i avalik litsents (EPL). (Mõistetav, et näiteks Eclipse'i enda projektide puhul ei ole see tavaliselt õiguste poolest probleem, mida ei saa öelda suletud lähtekoodiga toodete kohta.) Lisaks sellele iseloomulikule süsteemituslikusele, toob selline meetod esile hästi tuntud probleemid: kopeerimise ja kohandamise käigus tekkinud koodi dubleerimine ning sellega seotud vead jne. Veelgi hullem, saadud mudelid jäävad "asjaks iseeneses" ning ei kasuta olemasolevat potentsiaali ühtsuse saavutamiseks. Ometi võiks ühiste mõistete ja protokollide esiletoomine handle-põhiste mudelite jaoks viia taaskasutatavate komponentide loomisele, nagu see juhtus EMF-i puhul.

Ei saa öelda, et Eclipse'is ei mõistetud neid probleeme. Juba 2005. aastal Martin Aeschlimann, kokkuvõttes CDT prototüübi arendamise kogemus, tõi välja argumendid üldise infrastruktuuri loomise vajadus keelemudelite jaoks, sealhulgas ka handle-põhiste mudelite jaoks. Kuid nagu tihti juhtub, jäi nende ideede elluviimise aeg kõrpriority ülesannete tõttu tulemata. Sellegipoolest jääb koodi faktoriseerimine *DT-projektide jaoks endiselt üheks piisavalt arendamata teemaks Eclipse'is.

Teatud mõttes on projekt Handly suunatud sarnastele ülesannetele nagu EMF, kuid handle-põhiste mudelite jaoks, eelkõige keelelistele (st, mis esindavad mõne programmeerimiskeele struktuuri elemente). Allpool on loetletud peamised eesmärgid, mis olid Handly kavandamisel.

• Peamiste teemaalaste abstraktsioonide esiletoomine.
• Keerukuse vähendamine ja keeleliste handle-põhiste mudelite realiseerimise kvaliteedi tõstmine koodi taaskasutamise kaudu.
• Ühtse API pakkumine meta-tasandil tulemusk mudelite jaoks, mis võimaldab luua ühised IDE komponendid, mis töötavad keeleliste handle-põhiste mudelitega.
• Paindlikkus ja skaleeritavus.
• Integratsioon Xtextiga (eraldises kihis).

Ühiste mõistete ja protokollide esiletoomiseks analüüsiti olemasolevaid keelelisi handle-põhiseid mudelite realiseerimisi. Peamised liidesed ja baasseosed, mida Handly pakub, on esitatud joonisel 8.

Joonis 8. Ühised liidesed ja baasseosed Handly elementidest

IElement liides esindab elemendi handle'it ja on ühine kõigi Handly põhiste mudelite elementide jaoks. Abstraktne Element klass realiseerib üldise handle/body mehhanismi (joonis 9).

Joonis 9. IElement ja üldine handle/body realiseerimine

Lisaks pakub Handly üldist mehhanismi mudeli elementide muutmise teadete edastamiseks (joonis 10). Nagu näha, on see üldiselt sarnane muutuste teavitamise mehhanismidega, mis on realiseeritud ressursi mudelis ja Java mudelis, ning kasutab IElementDelta't teabe ühtseks esitamiseks elemendi muutusest.

Joonis 10. Ühised liidesed ja baasseosed Handly teavitamise mehhanismi jaoks

Eeltoodud Handly osa (joonis 9 ja 10) saab kasutada praktiliselt mis tahes handle-põhiste mudelite esindamiseks. Keelestruktuuride mudelite loomiseks pakub projekt täiendavat funktsionaalsust - eelkõige ühiseid liideseid ja baasseoseid lähtekoodi struktuuri elementide jaoks, nii nimetatud keelelistele mudelitele projekt pakub täiendavaid funktsioone - nimelt ühised liidesed ja baasseosed lähtekoodi struktuuri elementide jaoks, nii nimetatud source elements (kujund 8). ISourceFile liides esindab lähtefaili, samas kui ISourceConstruct on element lähtefailis. Abstraktsed klassid SourceFile ja SourceConstruct rakendavad üldiselt mehhanisme lähtefailide ja nende elementide töötamiseks, näiteks tekstibufferite haldamise, elemendi koordinaatide sidumise lähtekstis, mudeli ühtlustamise töökopi hetke sisuga jne. Nende mehhanismide rakendamine on tavaliselt piisavalt keeruline ülesanne ja Handly võib oluliselt vähendada keelepõhiste käsitlemismudelite arendamiseks vajalikku tööjõudu, pakkudes kvaliteetseid põhiraamistikke.

Peale ülaltoodud põhimehhanismide pakub Handly tekstibufferite ja „snapshot'ide” infrastruktuuri, toega lähtekoodi redigeerijate integreerimisele (sealhulgas rakendatud „kastist väljas” integreerimine Xtext redigeerijaga) ning mõned üldised UI-komponendid, mis töötavad Handly mudelitega, nagu outline framework. Oma võimaluste illustreerimiseks esitab projekt mitu näidet, sealhulgas Handly põhine Java mudel. (Võrreldes täisrakendusega Java mudel JDT-s, on see mudel äärmiselt lihtsustatud, et oleks kergem arusaada.)

Nagu eelnevalt mainitud, on Handly algse projekteerimise ja edasise arenduse käigus olnud tõsine tähelepanu pööratud skaleeritavusele ja paindlikkusele.

Põhimõtteliselt on handle-põhised mudelid “disaini” tõttu piisavalt hästi skaleeritavad. Näiteks handle/body idiom võimaldab piirata mudeli tarbitavat mälu. Kuid on ka nüansse. Näiteks Handsy skaleeritavuse testimisel avastati probleem teavitamismehhanismi rakenduses - suure hulga elementide muutmisel võttis delta genereerimine liiga palju aega. Selgus, et sama probleem esines ka Java mudelis JDT-s, millest vastav kood kunagi kohandati. Parandasime Handlys vea ja valmistasime sarnase patši JDT-le, mis võeti tänuga vastu. See on vaid üks näide, kus Handly rakendamine olemasolevates mudelite rakendustes võiks olla potentsiaalselt kasulik, kuna sellisel juhul oleks sellise vea parandamine võimalik vaid ühes kohas.

Kuna Handly implementeerimine olemasolevates tehnilistes mudelites oleks tehniliselt võimalik, peab raamatukogu olema märkimisväärselt paindlik. Peamine probleem on säilitada API mudeli tagasipööratavus. See ülesanne on lahendatud Handly 0.5 spetsiaalselt mudeli API selge jaotumise kaudu, mida määratleb ja kontrollib täielikult arendaja, universaalse meta-tasandi API eristamise kaudu, mida raamatukogu pakub. See mitte ainult ei muuda Handly rakendamist olemasolevates implementatsioonides tehniliselt võimalikuks, vaid annab ka uue mudeli arendajale märkimisväärse vabaduse API projekteerimisel.

Paindlikkusel on ka muid aspekte. Näiteks ei sea Handly praktiliselt mingeid piiranguid mudeli struktuurile ning seda saab kasutada nii üldkeeleline mudeldamine kui ka valdkondade spetsiifilised keeled. Algfaili struktuuri loomisel ei kehtesta Handly mingit kindlat AST esitusvormi ja põhimõtteliselt ei nõua ta isegi AST olemasolu, tagades seeläbi ühilduvuse peaaegu kõikide süntakside analüüsi mehhanismidega. Lõpuks toetab Handly täielikku integratsiooni Eclipse tööruumiga, kuid võib töötada ka otse failisüsteemidega, tänu integratsioonile Eclipse File System (EFS).

Praegune versioon Handly 0.6 välja anti 2016. aasta detsembris. Kuigi projekt on praegu inkubeerimisfaasis ja API ei ole veel lõplikult kindlaks määratud, kasutatakse Handly juba kahes suures kaubanduslikus tootes, mis julgevad astuda „varajaste adopteerijate“ rolli, ning tuleb öelda, et nad ei kahetse.

Nagu eelnevalt mainitud, on üks neist toodetest – 1C:Enterprise Development Tools, kus Handly on algusest peale kasutusel kõrgetasemeliste struktuuride mudeldamiseks 1C:Ettevõte keelte, nagu sisseehitatud programmeerimiskeel ja päringukeel. Teine toode on üldiselt vähem tuntud. See on Codasip Studio, integreeritud keskkond probleemipõhiste protsessorite (application-specific instruction-set processor, ASIP) projekteerimiseks, mida kasutatakse nii Tšehhi ettevõttes Codasip kui ka selle klientide seas, keda on AMD, AVG, Mobileye, Sigma Designs. Codasip kasutab Handly't tootmises alates 2015. aastast, alustades versioonist Handly 0.2. Viimane praegune väljaanne Codasip Studio kasutab versiooni 0.5, mis ilmus 2016. aasta juunis. Ondřej Ilčík, kes juhib IDE arendust Codasipis, on projektiga kontaktis, esitades äärmiselt olulist tagasisidet „kolmanda osapoole adopteerijana“. Tal õnnestus isegi leida veidi vaba aega, et otseselt osaleda projekti arenduses, rakendades UI kihti (umbes 4000 rida koodi) ühe Handly näite, Java mudeli, jaoks. Rohkem üksikasju „esimese allika“ kohta Handly kasutamisest adopteerijate seas on saadaval lehelt Edukad lood projekti.

Loodame, et pärast versiooni 1.0 väljalaskmist, millega kaasneb API stabiilsuse garantii ja projekti inkubatsioonist väljaviimine, tuleb Handlyle juurde uusi adopteerijaid. Seni jätkab projekt API testimist ja edasist täiustamist, väljastades aastas kaks „suurte“ väljaannet – juunis (samal kuupäeval, mil toimub ka Eclipse'i samal ajal toimuva väljaande väljalaskmine) ja detsembris, tagades ennustatava ajakava, millele adopteerijad saavad toetuda. Võib lisada, et projekti „veavoolu“ näitaja püsib pidevalt madalal tasemel ja Handly töötab usaldusväärselt varajaste adopteerijate toodetes alates esimestest versioonidest. Edasi tutvumiseks Eclipse Handly'ga saab kasutada Alustamise juhend ja Arhitektuuri ülevaade.

Allikas: habr.com