Verjetno, že dolgo časa ne potrebuje posebne predstavitve. Mnogi poznajo Eclipse zahvaljujoč orodjem za razvoj Java (). Ta priljubljena odprtokodna Java IDE večini razvijalcev asociira z besedo 'Eclipse'. Vendar pa je Eclipse tudi razširljiva platforma za integracijo razvojnih orodij (Eclipse Platform) in celoten nabor IDE, ki temeljijo nanjo, vključno z JDT. Eclipse je tudi Eclipse Project, projekt najvišje ravni, ki usklajuje razvoj Eclipse Platform in JDT, ter Eclipse SDK – dobavljeni rezultat te razvojne poti. Končno je Eclipse tudi odprtokodna fundacija z ogromno skupnostjo projektov, ki niso nujno napisani v Javi ali povezanih z razvojnimi orodji (na primer projekti in ). Svet Eclipse je zelo raznolik.
V tem članku, ki je po svoji naravi preglednega značaja, bomo poskušali obravnavati nekatere osnove arhitekture Eclipse kot platforme za izgradnjo integriranih razvojnih orodij ter dati začetno predstavo o komponentah Eclipse, ki tvorijo temelj tehnološke platforme za 'novi Konfigurator' 1C: Podjetje, . Seveda bo to razmišljanje neizbežno površinsko in precej omejeno, tudi zato, ker se ne osredotočamo le na razvijalce Eclipse kot ciljno publiko. Kljub temu upamo, da bodo tudi izkušeni razvijalci Eclipse našli v članku zanimive informacije. Na primer, povedali bomo o enem izmed 'skrivnosti Eclipse', v zvezi s sorazmerno novim in še slabo znanim projektom , ki ga je ustanovila in podpira podjetje 1C.
Uvod v arhitekturo Eclipse
Na začetku si oglejmo nekatere splošne vidike arhitekture Eclipse na primeru (JDT). Izbira prav JDT kot primera ni naključna. To je prva integrirana razvojna okolica, ki se je pojavila v Eclipse. Ostali *DT projekti Eclipse, kot je Eclipse C/C++ Development Tooling (CDT), so bili ustvarjeni kasneje in so prevzeli tako osnovne arhitekturne principe kot posamezne dele izvirne kode iz JDT. Osnove arhitekture, ki so bile zasnovane v JDT, so še danes relevantne za skoraj vsak IDE, zgrajen na podlagi Eclipse Platform, vključno z orodji za razvoj 1C:Podjetje.
Prvo je potrebno napomenuti da Eclipse karakteriše dovoljno jasno arhitektonsko razdvajanje, s odvojenom funkcionalnošću nezavisnom od jezika od funkcionalnosti namenjene podršci specifičnim programskim jezicima, kao i odvojenjem UI-nezavisnih 'jezgrenih' (core) komponenti od komponenti vezanih za podršku korisničkom interfejsu.
Tako Eclipse Platform definiše zajedničku, jeziku nezavisnu infrastrukturu, dok Java development tools dodaju Eclipse-u punu funkcionalnost Java IDE-a. Kako Eclipse Platform, tako i JDT se sastoji od više komponenti, od kojih se svaka odnosi na ili UI-nezavisno 'jezgro', ili na UI sloj (sl. 1).
Sl. 1. Eclipse Platform i JDT
Nabrajamo osnovne komponente Eclipse Platform:
- Runtime — Definiše infrastrukturu modula. Eclipse se odlikuje modularnom arhitekturom. U suštini, Eclipse je kolekcija 'tačaka proširenja' i 'proširenja'.
- Workspace — Upravljaju jednim ili više projekata. Projekat se sastoji od foldera i datoteka koje su direktno prikazane u datotečnom sistemu.
- Standard Widget Toolkit (SWT) — Pruža osnovne elemente korisničkog interfejsa, integrisane sa operativnim sistemom.
- JFace — Pruža niz UI frejmova koji su izgrađeni na SWT-u.
- Delovni prostor — Definiše UI paradigmu Eclipse-a: editori, prikazi, perspektive.
Treba napomenuti da Eclipse Platform pruža i mnoge druge korisne komponente za izgradnju integrisanih razvojnih alata, među kojima se mogu pomenuti Debug, Compare, Search i Team. Pojedinačno se mora spomenuti i JFace Text – osnova za izgradnju 'pametanih editora' izvornih kodova. Nažalost, čak ni površinski pregled ovih komponenti, kao i komponenti UI sloja, nije moguće obraditi u okviru ovog članka, stoga ćemo se u preostalom delu ovog poglavlja ograničiti na pregled osnovnih 'jezgrenih' komponenti Eclipse Platform i JDT.
Core Runtime
Infrastruktura modula Eclipse zasniva se na i obezbeđuje ga projekat . Svaki modul Eclipse-a je OSGi-bundl. OSGi specifikacija definiše, između ostalog, mehanizme verzioniranja i rešavanja zavisnosti. Pored ovih standardnih mehanizama, Equinox uvodi pojam tačke proširenja. Vsaka vtičnica lahko določi svoje točke razširitve in doda dodatno funkcionalnost v sistem («razširitve»), s pomočjo točk razširitve, ki jih določajo ta ali drugi vtičniki. Podrobnejši opis mehanizmov OSGi in Equinox presega obseg tega članka. Omeniti velja, da je modularizacija v Eclipse popolna (vsaka podsistem, vključno z Runtime, je sestavljena iz enega ali več vtičnikov), in skoraj vse v Eclipse je razširitev. Ti principi so bili vključeni v arhitekturo Eclipse še dolgo pred uvedbo OSGi (takrat je bila uporabljena lastniška tehnologija, ki je bila po mnogočem podobna OSGi).
Osrednji delovni prostor
Skoraj vsak integrirani razvojni okolje, zgrajeno na osnovi Eclipse Platform, deluje z Eclipse delovnim prostorom. Prav delovni prostor običajno vsebuje izvorno kodo aplikacije, ki se razvija v IDE. Delovni prostor se neposredno prikazuje na datotečni sistem in je sestavljen iz projektov, ki vsebujejo mape in datoteke. Ti projekti, mape in datoteke se imenujejo viri delovni prostor. Izvedba delovnega prostora v Eclipse služi kot nekakšna predpomnilnik v odnosu na datotečni sistem, kar omogoča znatno pospešitev prehoda po drevesu virov. Poleg tega delovni prostor nudi vrsto dodatnih storitev, vključno z in .
Za vzdrževanje delovnega prostora in njegovih virov je odgovorna komponenta Core Resources (vtičnik org.eclipse.core.resources). Ta komponenta predvsem nudi programski dostop do delovnega prostora v obliki modela virov. Za učinkovito delo s tem modelom potrebujejo stranke preprost način za predstavitev sklice na vir. Pri tem bi bilo zaželeno skriti objekt, ki neposredno hrani stanje vira v modelu, pred dostopom stranke. V nasprotnem primeru, na primer, ob brisanju datoteke, bi stranka še naprej lahko imela objekt, ki ga v modelu že ni, kar vodi do težav. Eclipse rešuje to nalogo s tako imenovanim handle vira. Handle deluje kot ključ (pozna le pot do vira v delovnem prostoru) in v celoti nadzira dostop do notranjega objekta modela, ki neposredno hrani informacije o stanju vira. Ta zasnova je različica vzorca .
Slika 2 ilustruje idiom Handle/Body u kontekstu modela resursa. Interfejs IResource predstavlja handle resursa i deluje kao API, dok klasa Resource implementira ovaj interfejs, zajedno sa klasom ResourceInfo koja predstavlja body, koja nije API. Važno je napomenuti da handle zna samo putanju do resursa u odnosu na koren workspace-a i ne sadrži referencu na resource info. Objekti resource info formiraju takozvano "drvo elemenata" (element tree). Ova struktura podataka je potpuno materializovana u memoriji. Da bismo pronašli instancu resource info koja odgovara određenom handle-u, element tree se pretražuje prema putanji koja se čuva u tom handle-u.
Slika 2. IResource i ResourceInfo
Kao što ćemo dalje videti, osnovni dizajn modela resursa (može se nazvati dizajnom zasnovanim na handle-u) koristi se u Eclipse-u i za druge modele. A sada ćemo navesti neka od karakterističnih svojstava ovog dizajna:
- Handle je objekat-vrednost (value object). Objekti-vrednosti su nemutable (immutable) objekti, čija jednakost nije zasnovana na identitetu. Ovi objekti mogu se sigurno koristiti kao ključevi u heširanim kontejnerima. Više instanci handle-a može se referencirati na isti resurs. Da bi ih uporedili, koristi se metoda equals(Object).
- Handle definiše ponašanje resursa, ali ne sadrži informacije o stanju resursa (jedini podaci koje čuva su "ključ", put do resursa).
- Handle može referencirati nepostojeći resurs (ili resurs koji još nije kreiran, ili resurs koji je već obrisan). Postojanje resursa može se proveriti metodom IResource.exists().
- Neke operacije mogu se realizovati isključivo na osnovu informacija koje se čuvaju u samom handle-u (takozvane handle-only operacije). Primeri uključuju IResource.getParent(), getFullPath(), itd. Resurs ne mora nužno postojati za uspešno izvršenje takve operacije. Operacije za koje je potrebno da resurs postoji za uspešno izvršenje bacaju izuzetak (CoreException) ako resurs ne postoji.
Eclipse nudi učinkovit mehanizam obaveštavanja o promenama resursa radnog prostora (sl. 3). Resursi se mogu menjati kako kao rezultat radnji u samoj Eclipse IDE, tako i kao rezultat sinhronizacije sa datotečkim sistemom. U oba slučaja klijentima koji su se pretplatili na obaveštenja pružaju se detaljne informacije o promenama u obliku «resursnih delta» (resource delta). Delta opisuje promene između dva stanja (pod-)stabla resursa radnog prostora i sama je stablo, pri čemu svaki čvor opisuje promenu određenog resursa i sadrži listu delta sledećeg nivoa, koja opisuje promene podređenih resursa.
Sl. 3. IResourceChangeEvent i IResourceDelta
Osnovane na resursnim delta, mehanizam obaveštavanja ima sledeće karakteristike:
- Jedna promena i više promena opisane su pomoću iste strukture, jer se delta gradi prema principu rekurzivne kompozicije. Klijenti-pretplatnici mogu obraditi obaveštenja o promenama resursa pomoću rekurzivnog spuštanja po stablu delta.
- Delta sadrži potpunu informaciju o promeni resursa, uključujući njegovo premještanje i/ili promenu povezanih «markera» (npr. greške u kompajliranju predstavljaju se kao markeri).
- Budući da se veze na resurs prave kroz handle, delta može prirodno upućivati na udaljeni resurs.
Kao što ćemo uskoro videti, osnovni sastavni delovi dizajna mehanizma obaveštavanja o promeni modela resursa relevantni su i za druge modele zasnovane na handle.
JDT Core
Model resursa Eclipse radnog prostora je temeljni model nezavistan od jezika. JDT Core komponenta (plugin org.eclipse.jdt.core) pruža API za navigaciju i analizu strukture radnog prostora sa stanovišta Jave, poznatu kao «model Jave» (Java model). Ovaj API je definisan u terminima Java elemenata, za razliku od nižerazine API-ja modela resursa, koji je definisan u terminima mapa i datoteka. Osnovni interfejsi stabla Java elemenata prikazani su na sl. 4.
Sl. 4. Elementi modela Jave
Java model uses the same handle/body idiom as the resource model (see Fig. 5). IJavaElement is the handle, and JavaElementInfo serves as the body. The IJavaElement interface defines a protocol that is common to all Java elements. Some of its methods are handle-only: getElementName(), getParent(), etc. The JavaElementInfo object stores the state of the corresponding element: its structure and attributes.
Fig. 5. IJavaElement and JavaElementInfo
The Java model has some differences in the implementation of the basic handle/body design compared to the resource model. As noted above, in the resource model, the element tree, whose nodes are resource info objects, is fully kept in memory. However, in the Java model, there can be significantly more elements than in the resource tree, as it also represents the internal structure of .java and .class files: types, fields, and methods.
To avoid fully materializing the entire element tree in memory, the Java model implementation uses a size-limited LRU cache for element info, where the key is the handle IJavaElement. Element info objects are created on demand as navigation through the element tree occurs. The least frequently used elements are evicted from the cache, keeping the memory consumption of the model limited to the specified cache size. This is another advantage of the handle-based design, which completely hides such implementation details from client code.
The notification mechanism for changes in Java elements is generally similar to the resource workspace change tracking mechanism discussed above. A client wanting to track changes in the Java model subscribes to notifications, which are presented as an ElementChangedEvent object that contains IJavaElementDelta (see Fig. 6).
Fig. 6. ElementChangedEvent and IJavaElementDelta
The Java model does not contain information about method bodies or name resolution, so for detailed analysis of Java code, JDT Core provides an additional (not handle-based) model: (abstract syntax tree, AST). The AST represents the result of parsing the source text. The nodes of the AST correspond to elements of the structure of the source module (declarations, operators, expressions, etc.) and contain information about the coordinates of the corresponding element in the source text, and optionally, information about name resolution in the form of references to so-called vezeBindings so objekti, ki predstavljajo poimenovane entitete, kot so tipi, metode in spremenljivke, znane prevajalniku. V nasprotju z vozlišči AST, ki tvorijo drevo, bindings podpirajo medsebojne povezave in na splošno tvorijo graf. Abstraktni razred ASTNode je skupni osnovni razred za vsa vozlišča AST. Podrazredi ASTNode ustrezajo določenim sintaktičnim konstrukcijam programskega jezika Java.
Ker sintaktična drevesa lahko porabijo znatno količino pomnilnika, JDT predpomni le eno AST za aktivni urejevalnik. V nasprotju z Java modelom se AST običajno obravnava kot 'vmesni', 'časovni' model, na katerega stranke ne bi smele obdržati povezav zunaj konteksta operacije, ki je povzročila ustvarjanje AST.
Naštete tri modele (Java model, AST, bindings) skupaj predstavljajo osnovo za gradnjo 'inteligentnih razvojnih orodij' v JDT, med katerimi je močan Java urejevalnik z različnimi 'pomočniki', različne akcije za obdelavo izvorne kode (med katerimi so organizacija seznama uvoza imen in formatiranje v skladu z nastavljeno stilom), orodja za iskanje in preoblikovanje. Pri tem ima Java model posebno vlogo, saj se uporablja kot osnova za vizualno predstavitev strukture razvijane aplikacije (npr. v Package Explorer, Outline, Search, Call Hierarchy in Type Hierarchy).
Komponente Eclipse, uporabljene v 1C:Enterprise Developments Tools
Na sl. 7 so prikazane komponente Eclipse, ki tvorijo temelj tehnološke platforme za 1C:Enterprise Development Tools.
Sl. 7. Eclipse kot platforma za 1C:Enterprise Development Tools
Eclipse Platform nudi osnovno infrastrukturo. Nekatere vidike te infrastrukture smo obravnavali v prejšnjem razdelku.
(EMF) zagotavlja splošna orodja za modeliranje strukturiranih podatkov. EMF je vgrajen v Eclipse Platformo, a se lahko uporablja tudi samostojno, v običajnih Java aplikacijah. Pogosto so začetniki Eclipse razvijalci že dobro seznanjeni z EMF, čeprav še niso popolnoma obvladali natančnosti Eclipse Platforme. Eden od razlogov za to zasluženo priljubljenost je univerzalna zasnova, ki vključuje tudi poenoten API meta-nivoja, ki omogoča splošno delo z vsakim EMF modelom. Osnovne implementacije EMF za modele objektov in podsystem za generacijo kode modela po meta-modelu bistveno povečujejo hitrost razvoja in zmanjšujejo število napak. EMF prav tako vsebuje mehanizme za serializacijo modelov, sledenje spremembam v modelu in še več.
Kot vsako resnično univerzalno orodje, EMF ustreza širokemu spektru nalog, povezanih z modeliranjem, vendar nekateri razredi modelov (na primer obravnavani zgoraj modeli, ki temeljijo na ročajih) morda potrebujejo bolj specializirana orodja za modeliranje. Govoriti o EMF je neprijetno delo, zlasti v omejenih okvirih enega članka, saj je to tematika, ki zahteva ločeno knjigo, in to kar debelo. Omeniti velja, da je kakovostni sistem generalizacij, ki je osnova EMF, omogočil pojav celotnega spektra projektov, posvečenih modeliranju, ki so vključeni v projekt višjega nivoja. poleg samega EMF. Eden od takih projektov je Eclipse Xtext.
zagotavlja infrastrukturo 'besedilnega modeliranja'. Xtext uporablja для синтаксического анализа исходного текста и EMF для представления результирующего ASG (abstract semantic graph, который по сути является комбинацией AST и привязок), называемого также «семантической моделью». Грамматика моделируемого с помощью Xtext языка описывается на собственном языке Xtext. Это позволяет не только генерировать описание грамматики для ANTLR, но и получать механизм сериализации AST (т.е. Xtext предоставляет и парсер, и анпарсер), контекстную подсказку и ряд других языковых компонентов. С другой стороны, язык описания грамматики, используемый в Xtext, менее гибок по сравнению, скажем, с языком описания грамматики в ANTLR. Поэтому иногда приходится «подгибать» под Xtext реализуемый язык, что обычно не является проблемой, если речь идет о разрабатываемом с нуля языке, но может быть неприемлемым для языков с уже сложившимся синтаксисом. Несмотря на это, Xtext является в настоящее время наиболее зрелым, функционально полным и универсальным инструментом в Eclipse для построения языков программирования и средств разработки для них. В частности, он является идеальным инструментом для быстрого прототипирования. (domain-specific language, DSL). Кроме упомянутого выше «языкового ядра» на основе ANTLR и EMF, Xtext предоставляет множество полезных компонентов более высокого уровня, включая механизмы индексации, инкрементального построения, «умный редактор» и многое другое, но оставляет за скобками языковые модели на основе обработчиков. Как и EMF, Xtext является предметом, достойным отдельной книги, и мы вряд ли сможем даже бегло рассказать сейчас обо всех его возможностях.
1С:Enterprise Development Tools активно используют как EMF, так и ряд других проектов Eclipse Modeling. В частности, Xtext является одной из основ средств разработки для таких языков 1С:Предприятие, как встроенный язык программирования и язык запросов. Другой основой этих средств разработки является проект Eclipse Handly, на котором мы остановимся более подробно (из перечисленных компонентов Eclipse он пока наименее известен).
, podprojekt visokog nivoa Eclipse Technology, nastao je kao rezultat inicijalne doprinose koda Eclipse Foundation, kojeg je izvršila kompanija 1C 2014. godine. Od tada, kompanija 1C nastavlja da podržava razvoj projekta: komitenti Handly su zaposleni u firmi. Projekat je mali, ali zauzima dovoljno jedinstvenu nišu u Eclipse-u: njegova glavna svrha je podrška razvoju modela zasnovanih na handle-u.
Osnovni arhitektonski principi modela zasnovanih na handle-u, kao što su idiom handle/body, razmatrani su ranije na primeru modela resursa i Java modela. Takođe je napomenuto da su i model resursa i model Java važni temelji za Eclipse Java development tools (JDT). S obzirom na to da gotovo svi *DT projekti Eclipse imaju arhitekturu sličnu JDT-u, ne bi bilo preterano reći da modeli zasnovani na handle-u leže u osnovi mnogih, ako ne i svih IDE-ova izgrađenih na Eclipse Platformi. Na primer, u Eclipse C/C++ Development Tooling (CDT) postoji model C/C++ zasnovan na handle-u, koji u arhitekturi CDT igra istu ulogu koju ima Java model u JDT-u.
Pre nego što je Handly nastao, Eclipse nije nudio specijalizovane biblioteke za izgradnju jezika zasnovanih na handle-u. Postojeći modeli su mahom kreirani direktnom adaptacijom koda Java modela (t. j. copy/paste), u slučajevima kada to omogućava Eclipse Public License (EPL). (Jasno je da, recimo, za projekte same Eclipse to obično nije pravni problem, što se ne može reći za proizvode sa zatvorenim izvorom.) Pored karakteristične nekonzistentnosti, takva metodologija dovodi do dobro poznatih problema: dupliciranja koda, grešaka unetih prilikom adaptacije, itd. Što je još gore, rezultantni modeli ostaju „stvar za sebe“ i ne koriste postojeći potencijal za unifikaciju. A izdvajanje zajedničkih pojmova i protokola za modele jezika zasnovane na handle-u moglo bi dovesti do stvaranja ponovo upotrebljivih komponenti za rad s njima, slično onome što se dogodilo sa EMF-om.
Ne može se reći da u Eclipse-u nije postojalo razumevanje ovih problema. Već 2005. godine , sažimajući iskustvo razvoja prototipa CDT-a, potreba ustvarjanja skupne infrastrukture za jezikovne modele, vključno z modeli, temelječimi na ročicah. Vendar pa, kot to pogosto biva, zaradi prioritetnejših nalog do realizacije teh idej nato nikoli ni prišlo. Medtem pa ostaja faktorizacija kode *DT-projektov še vedno ena izmed premalo obdelanih tem v Eclipse.
V nekem smislu je projekt Handly namenjen reševanju približno istih nalog kot EMF, vendar za modele, temelječih na ročicah, predvsem jezikovnih (tj. predstavljajo elemente strukture določenega programskega jezika). Spodaj so navedeni glavni cilji, ki so bili postavljeni pri načrtovanju Handly:
- Izločitev osnovnih abstrakcij predmetne področja.
- Zmanjšanje prizadevanj in povečanje kakovosti izvajanja jezikovnih modelov, temelječih na ročicah, z omogočanjem ponovne uporabe kode.
- Nudenje poenotene API meta-nivoja k rezultantnim modelom, kar omogoča ustvarjanje skupnih komponent IDE, ki delujejo z jezikovnimi modeli, temelječimi na ročicah.
- Prilagodljivost in skalabilnost.
- Integracija z Xtext (v ločenem sloju).
Za izločitev skupnih pojmov in protokolov so bile analizirane obstoječe realizacije jezikovnih modelov, temelječih na ročicah. Glavni vmesniki in osnovne realizacije, ki jih nudi Handly, so prikazane na sl. 8.
Sl. 8. Skupni vmesniki in osnovne realizacije elementov Handly
Vmesnik IElement predstavlja ročico elementa in je skupen za elemente vseh modelov, temelječih na Handly. Abstraktna klasa Element implementira poenoteni mehanizem ročica/telo (sl. 9).
Sl. 9. IElement in poenotena realizacija ročica/telo
Poleg tega Handly nudi poenoten mehanizem obveščanja o spremembi elementov modela (sl. 10). Kot je razvidno, je v splošnem podoben mehanizmom obveščanja, implementiranim v modelu virov in Java-modelu, ter uporablja IElementDelta za poenoteno predstavitev informacij o spremembi elementa.
Sl. 10. Skupni vmesniki in osnovne realizacije mehanizma obveščanja Handly
Obravnavani del Handly (sl. 9 in 10) se lahko uporablja za predstavitev praktično vseh modelov, temelječih na ročicah. Za ustvarjanje jezikovnih modelov projekt ponuja dodatne funkcionalnosti – zlasti skupne vmesnike in osnovne realizacije za elemente strukture izvornega besedila, tako imenovane izvorne elemente (sl. 8). Vmesnik ISourceFile predstavlja izvorno datoteko, medtem ko ISourceConstruct predstavlja element znotraj izvorne datoteke. Abstraktni razredi SourceFile in SourceConstruct implementirajo splošne mehanizme za podporo delu z izvorno datoteko in njenimi elementi, kot so upravljanje s tekstovnimi bufferji, povezovanje z koordinatami elementa v izvoru ter usklajevanje modela s trenutnim vsebinskim bufferjem delovne kopije itd. Izvajanje teh mehanizmov je običajno dovolj zapletena naloga, Handly pa lahko znatno skrajša napore pri razvoju jezikovnih modelov, temelječih na upravljanju, s kvalitativnimi osnovnimi implementacijami.
Poleg zgoraj naštetih osnovnih mehanizmov Handly nudi infrastrukturo za tekstovne bufferje in "posnetke" (snapshots), podporo za integracijo z urejevalniki izvorne kode (vključno z že implementirano "iz škatle" integracijo z urejevalnikom Xtext), ter nekatere splošne UI-komponente, ki delujejo z modeli, temelječimi na Handly, kot je okvir za outline. Da bi prikazali svoje zmožnosti, projekt nudi več primerov, vključno z implementacijo modela Java na Handly. (V primerjavi s popolno implementacijo Java-modela v JDT je ta model namenoma nekoliko poenostavljen za večjo preglednost.)
Kot je bilo že omenjeno, je bila pri začetnem oblikovanju Handly in nadaljnjem razvoju posvečena in se še naprej posveča resna pozornost skalabilnosti in prilagodljivosti.
Na splošno se modeli, temelječi na upravljanju, dobro skalirajo "po oblikovanju". Na primer, idiom handle/body omogoča omejitev količine pomnilnika, ki ga model porabi. Vendar pa obstajajo tudi posebnosti. Tako je pri testiranju Handly za skalabilnost bila odkrita težava v implementaciji mehanizma obveščanja – pri spreminjanju velikega števila elementov je gradnja deltat vzela preveč časa. Izkazalo se je, da je ista težava prisotna tudi v Java-modelu JDT, iz katerega je bil takrat prilagojen ustrezen koda. Popravili smo napako v Handly in pripravili podoben popravek za JDT, ki je bil s strani prejet s hvaležnostjo. To je le en primer, ko bi uvedba Handly v obstoječe implementacije modelov lahko bila potencialno koristna, saj bi v tem primeru to napako lahko popravili na enem mestu.
Da bi se implementacija Handly u postojeće modele učinila tehnički mogućom, biblioteka mora imati značajnu fleksibilnost. Glavni problem je očuvanje unazadne kompatibilnosti API-ja modela. Ovaj problem je rešen jasnim odvajanje specifičnog API-ja modela, kojeg definiše i u potpunosti kontroliše programer, od ujednačenog API-ja meta-nivoa, koji obezbeđuje biblioteka. To ne samo da čini tehničku implementaciju Handly mogućom u postojećim modelima, već takođe daje programeru novog modela značajnu slobodu u dizajnu API-ja.
Fleksibilnost ima i druge aspekte. Na primer, Handly gotovo da ne nameće ograničenja na strukturu modela i može se koristiti za modelovanje jezika opšte namene, kao i jezika specijalizovanih za određene domene. Prilikom izrade strukture izvornog fajla, Handly ne propisuje određeni oblik prikaza AST-a i u principu ne zahteva čak ni postojanje AST-a, čime se osigurava kompatibilnost s praktično svim mehanizmima sintaktičke analize. Na kraju, Handly podržava potpunu integraciju s Eclipse radnim prostorom, ali takođe može raditi i direktno s sistemima datoteka, zahvaljujući integraciji s (EFS).
Trenutna verzija objavljena je u decembru 2016. godine. Iako je projekat trenutno u fazi inkubacije i API još nije konačno utvrđen, Handly se već koristi u dva značajna komercijalna proizvoda koja su rizikovala da postanu 'rani usvajači', i, treba reći, za sada se ne žale zbog toga.
Kao što je ranije napomenuto, jedan od tih proizvoda je 1C:Enterprise Development Tools, gde se Handly od samog početka koristi za modelovanje elemenata visoko-nivoe strukture jezika kao što su ugrađeni programski jezik i jezik upita. Drugi proizvod je manje poznat široj javnosti. To je , integrisano okruženje za projektovanje procesora specifičnih za određene aplikacije (application-specific instruction-set processor, ASIP), koje se koristi kako unutar same češke kompanije Codasip, tako i od strane njenih klijenata, među kojima su , , , . Codasip uporablja Handly v produkciji od leta 2015, začelo se je z različico Handly 0.2. Zadnja na voljo različica Codasip Studio uporablja različico 0.5, izdano junija 2016. Ondřej Ilčík, ki vodi razvoj IDE pri Codasipu, ostaja v stiku s projektom in zagotavlja izjemno pomembne povratne informacije s strani "zunanjega adoperatorja". Uspešno je našel malo prostega časa, da se osebno vključi v razvoj projekta in implementira UI plast (~ 4000 vrstic kode) za enega od primerov Handly, model Java. Več informacij projekta.
Upamo, da bo po izdaji različice 1.0, ki bo zagotavljala stabilnost API, in zaključenju inkubacijskega obdobja, Handly pridobil nove adoperatorje. Projekt še naprej poteka in se dodatno razvija API ter izda dve "veliki" različici letno – junija (na isti datum, ko izide Eclipse) in decembra, kar zagotavlja predvidljiv urnik, na katerega se lahko adoperatorji zanesete. Mogoče je še dodati, da se "stopnja napak" pri projektu ohranja na stabilno nizki ravni, Handly pa od prvih različic zanesljivo deluje v izdelkih zgodnjih adoperatorjev. Za nadaljnje spoznavanje Eclipse Handly lahko uporabite in .
Izvor: habr.com
