Vjerojatno, već dugo ne treba posebno predstavljanje. Mnogi su poznati s Eclipse-om zahvaljujući Eclipse Java razvojnim alatima (). Ova popularna open-source Java IDE većini programera povezuje se sa riječju “Eclipse”. Međutim, Eclipse je i proširiva platforma za integraciju razvojnih alata (Eclipse Platform), kao i niz IDE-ova izgrađenih na temelju iste, uključujući i JDT. Eclipse obuhvaća i Eclipse Project, projekt na višem nivou koji koordinira razvoj Eclipse Platforme i JDT-a, kao i Eclipse SDK – isporučeni rezultat tog razvoja. Na kraju, Eclipse je i open-source Fondacija s ogromnom zajednicom projekata, od kojih mnogi nisu napisani na Javi ili nemaju veze s razvojnim alatima (na primjer, projekti i ). Svijet Eclipse-a je vrlo raznolik.
U ovom članku, koji je preglednog karaktera, pokušat ćemo razmotriti neke osnove arhitekture Eclipse kao platforme za izgradnju integriranih razvojnih alata i dati početnu predstavu o komponentama Eclipse-a koje čine temelj tehnološke platforme za „novi Konfigurator“ 1C: Poduzeće, . Naravno, takvo razmatranje neizbježno će biti u mnogim aspektima površno i prilično ograničeno, dijelom i zato što se ne usredotočujemo samo na Eclipse-programere kao ciljanu publiku. Ipak, nadamo se da će čak i iskusni Eclipse programeri moći pronaći zanimljive informacije u ovom članku. Na primjer, ispričat ćemo o jednom od „tajni Eclipse-a“, relativno novom i još slabo poznatom projektu , koji je osnovan i podržava tvrtka 1C.
Uvod u arhitekturu Eclipse
Najprije ćemo razmotriti neke opće aspekte arhitekture Eclipse-a na primjeru (JDT). Odabir JDT-a kao primjera nije slučajan. To je prva integrirana razvojna sredina koja se pojavila u Eclipse-u. Ostali *DT projekti Eclipse-a, poput Eclipse C/C++ Development Toolinga (CDT), stvoreni su kasnije i posudili su kako osnovne arhitektonske principe, tako i pojedine dijelove izvornog koda iz JDT-a. Osnove arhitekture postavljene u JDT-u relevantne su do danas za praktički sve IDE-e izgrađene na Eclipse Platformi, uključujući i 1C:Enterprise Development Tools.
Prvo treba napomenuti da se Eclipse odlikuje jasno definiranim arhitektonskim slojevanjem, s odvajanjem jeziku neovisne funkcionalnosti od funkcionalnosti namijenjene podršci određenim programskim jezicima, te odvajanjem UI-neovisnih „jezgrenih“ (core) komponenti od komponenti povezanih s podrškom korisničkom sučelju.
Eclipse Platform definira zajedničku, jeziku neovisnu infrastrukturu, dok alati za razvoj u Javi dodaju u Eclipse punu funkcionalnost Java IDE-a. I Eclipse Platform i JDT sastoje se od nekoliko komponenti, od kojih svaka pripada ili UI-neovisnom „jezgru“ ili UI sloju (sl. 1).
Sl. 1. Eclipse Platform i JDT
Nabrojimo glavne komponente Eclipse Platforme:
- Runtime — Definira infrastrukturu dodataka. Eclipse se odlikuje modularnom arhitekturom. U suštini, Eclipse je zbirka „točaka proširenja“ i „proširenja“.
- Workspace — Upravljanje jednim ili više projekata. Projekt se sastoji od mapa i datoteka koje se izravno prikazuju na datotečnom sustavu.
- Standard Widget Toolkit (SWT) — Pruža osnovne elemente korisničkog sučelja, integrirane s operativnim sustavom.
- JFace — Pruža niz UI okvira izgrađenih na temelju SWT-a.
- Radna površina — Definira UI paradigmu Eclipse-a: uređivače, prikaze, perspektive.
Treba napomenuti da Eclipse Platform nudi i mnogo drugih korisnih komponenti za izgradnju integriranih razvojnih alata, među kojima se ističu Debug, Compare, Search i Team. Također se mora spomenuti JFace Text – osnova za izgradnju „pametnih uređivača“ izvornog koda. Nažalost, čak je i površinski pregled ovih komponenti, kao i komponenti UI sloja, van okvira ovog članka, stoga ćemo se u preostalom dijelu ovog odjeljka ograničiti na pregled glavnih „jezgrenih“ komponenti Eclipse Platforme i JDT-a.
Core Runtime
Infrastruktura dodataka Eclipse temelji se na i pruža je projekt . Svaki dodatak Eclipse-a je OSGi paket. OSGi specifikacija definira, između ostalog, mehanizme verzioniranja i rješavanja ovisnosti. Pored ovih standardnih mehanizama, Equinox uvodi koncept točke proširenja. Svaki plugin može definirati svoje točke proširenja, kao i dodati dodatnu funkcionalnost u sustav («proširenja»), koristeći točke proširenja definirane tim ili drugim pluginima. Detaljno objašnjenje mehanizama OSGi i Equinoxa izlazi iz okvira ovog članka. Naglašavamo samo da modularizacija u Eclipseu ima sveobuhvatan karakter (svaka podsustav, uključujući Runtime, sastoji se od jednog ili više pluginova), i praktično sve u Eclipseu je proširenje. Ovi principi su ugrađeni u arhitekturu Eclipsea mnogo prije implementacije OSGi (tada se koristila vlastita tehnologija, koja je u mnogim aspektima slična OSGi).
Osnovni radni prostor
Gotovo svaki integrirani razvoJNI sustav temeljen na Eclipse platformi radi s Eclipse radnim prostorom. Upravo radni prostor obično sadrži izvorni kod razvijanog aplikacija u IDE-u. Radni prostor izravno se preslikava na datotečni sustav i sastoji se od projekata koji sadrže mape i datoteke. Ovi projekti, mape i datoteke nazivaju se resursima radni prostor. Implementacija radnog prostora u Eclipseu služi kao neka vrsta predmemorije u odnosu na datotečni sustav, što značajno ubrzava prolazak kroz stablo resursa. Osim toga, radni prostor pruža niz dodatnih usluga, uključujući i .
Za podršku radnom prostoru i njegovim resursima odgovorna je komponenta Core Resources (plugin org.eclipse.core.resources). Konkretno, ova komponenta pruža programski pristup radnom prostoru u obliku modela resursa. Za učinkovito rad s ovim modelom klijentima je potreban jednostavan način predstavljanja veze na resurs. Pri tome bi bilo poželjno sakriti objekt koji izravno pohranjuje stanje resursa u modelu od pristupa klijenta. Inače, u slučaju, na primjer, brisanja datoteke, klijent bi mogao nastaviti zadržavati objekt koji više nije prisutan u modelu, što bi moglo dovesti do problema. Eclipse rješava ovaj problem koristeći takozvani handle resursa. Handle djeluje kao ključ (on zna samo put do resursa u radnom prostoru) i potpuno kontrolira pristup unutarnjem modelskom objektu koji izravno pohranjuje informacije o stanju resursa. Ovaj dizajn predstavlja varijaciju obrasca .
Slika 2 ilustrira idiom Handle/Body u kontekstu modela resursa. Sučelje IResource predstavlja handle resursa i služi kao API, za razliku od klase Resource koja implementira ovo sučelje, kao i klase ResourceInfo koja predstavlja body, a nije API. Naglašavamo da handle poznaje samo put do resursa u odnosu na korijen workspace-a i ne sadrži referencu na resource info. Objekti resource info tvore takozvano „stablo elemenata“ (element tree). Ova struktura podataka je potpuno materijalizirana u memoriji. Kako bi se pronašao primjerak resource info koji odgovara određenom handle-u, element tree se pretražuje prema putu pohranjenom u tom handle-u.
Slika 2. IResource i ResourceInfo
Kako ćemo vidjeti kasnije, osnovni dizajn modela resursa (možemo ga nazvati dizajnom temeljenim na handle-ima) koristi se u Eclipse-u i za druge modele. A sada nabrojimo neka od karakterističnih svojstava ovog dizajna:
- Handle je objekt-vrijednost (value object). Objekti-vrijednosti su nemutabilni (immutable) objekti čija se jednakost ne temelji na identitetu. Takvi objekti mogu se sigurno koristiti kao ključevi u haširanim kontejnerima. Nekoliko instanci handle-a može referencirati na isti resurs. Za njihovo uspoređivanje treba koristiti metodu equals(Object).
- Handle definira ponašanje resursa, ali ne sadrži informacije o stanju resursa (jedini podaci koje pohranjuje su „ključ“, put do resursa).
- Handle može referencirati na nepostojeći resurs (ili resurs koji još nije stvoren, ili resurs koji je već uklonjen). Postojanje resursa može se provjeriti pomoću metode IResource.exists().
- Neke operacije mogu se implementirati isključivo na temelju informacija pohranjenih u samom handle-u (takozvane handle-only operacije). Primjeri su IResource.getParent(), getFullPath() i slično. Resurs ne mora nužno postojati za uspješno izvršenje takve operacije. Operacije za koje je za uspješno izvršenje potrebno da resurs postoji, bacaju iznimku (CoreException) ako resurs ne postoji.
Eclipse pruža učinkovit mehanizam obavještavanja o promjenama resursa radnog prostora (sl. 3). Resursi se mogu mijenjati bilo kao rezultat radnji unutar samog Eclipse IDE-a ili kao rezultat izvršavanja sinkronizacije s datotečnim sustavom. U oba slučaja, klijentima koji su se prijavili za obavijesti pruža se detaljna informacija o promjenama u obliku „resursnih delta“ (resource delta). Delta opisuje promjene između dva stanja (pod-)stabla resursa radnog prostora i sama je stablo, pri čemu svaki čvor opisuje promjenu nekog resursa i sadrži popis delta sljedeće razine koje opisuju promjene podređenih resursa.
sl. 3. IResourceChangeEvent i IResourceDelta
Mehanizam obavještavanja temeljen na resursnim deltatama ima sljedeće karakteristike:
- Jedna promjena i više promjena opisuju se pomoću iste strukture, budući da se delta gradi prema načelu rekurzivne kompozicije. Klijenti pretplatnici mogu obrađivati obavijesti o promjenama resursa pomoću rekurzivnog silaska kroz stablo delta.
- Delta sadrži potpune informacije o promjeni resursa, uključujući njegovo premještanje i/ili promjenu povezanih „oznake“ (kao što su markeri koji predstavljaju, na primjer, greške kompajliranja).
- Budući da se reference na resurs vrše putem handlea, delta može prirodno referirati na udaljeni resurs.
Kao što ćemo ubrzo vidjeti, osnovne komponente dizajna mehanizma obavještavanja o promjeni modela resursa relevantne su i za druge modele temeljene na handleu.
JDT Core
Model resursa Eclipse radnog prostora temeljna je jezično neovisna shema. Komponenta JDT Core (plugin org.eclipse.jdt.core) pruža API za navigaciju i analizu strukture radnog prostora s gledišta Jave, takozvani „model Jave“ (Java model). Ovaj API definiran je u terminima Java elemenata, za razliku od donjeg API-ja modela resursa, koji je definiran u terminima mapa i datoteka. Glavni sučelja stabla elemenata Jave prikazana su na sl. 4.
sl. 4. Elementi modela Jave
Java model koristi istu idiomu handle/body kao i model resursa (slika 5). IJavaElement je handle, dok JavaElementInfo igra ulogu body. Sučelje IJavaElement definira protokol zajednički za sve Java elemente. Neki od njegovih metoda su samo handle: getElementName(), getParent() i slično. Objekt JavaElementInfo pohranjuje stanje pripadajućeg elementa: njegovu strukturu i atribute.
Slika 5. IJavaElement i JavaElementInfo
Java model ima neka odstupanja u implementaciji osnovnog dizajna handle/body u usporedbi s modelom resursa. Kao što je ranije spomenuto, u modelu resursa tree elementa, čiji su čvorovi objekti resource info, potpuno se nalazi u memoriji. No u Java modelu može postojati značajno veći broj elemenata nego u treeu resursa, jer obuhvaća i unutarnju strukturu .java i .class datoteka: tipove, polja i metode.
Kako bi se izbjegla potpuna materializacija cijelog stabla elemenata u memoriji, implementacija Java modela koristi ograničen LRU cache element info, gdje je ključ handle IJavaElement. Objekti element info kreiraju se na zahtjev dok se navigira kroz stablo elemenata. Pri tome, najmanje često korišteni elementi se istiskuju iz cachea, a potrošnja memorije modela ostaje ograničena zadanim veličinom cachea. To je još jedna prednost handle-based dizajna, koji potpuno skriva takve detalje implementacije od klijentskog koda.
Mehanizam obavještavanja o promjenama elemenata Java u osnovi je sličan prethodno razmatranom mehanizmu praćenja promjena resursa radnog prostora. Klijent koji želi pratiti promjene u Java modelu pretplaćuje se na obavijesti koje se predstavljaju u obliku objekta ElementChangedEvent, koji sadrži IJavaElementDelta (slika 6).
Slika 6. ElementChangedEvent i IJavaElementDelta
Java model ne sadrži informacije o tijelu metoda ili razrješavanju imena, stoga za detaljnu analizu koda napisanog u Javi, JDT Core pruža dodatni (ne handle-based) model: (apstraktna sintaktička struktura, AST). AST predstavlja rezultat sintaktičke analize izvor teksta. Čvorovi AST-a odgovaraju elementima strukture izvor modula (deklaracijama, operatorima, izrazima itd.) i sadrže informacije o koordinatama odgovarajućeg elementa u izvoru, kao i (po izboru) informacije o razrješavanju imena u obliku referenci na takozvane povezivanja. Veze su objekti koji predstavljaju imenovane entitete, kao što su tipovi, metode i varijable poznate prevodilac. Za razliku od čvorova AST-a koji čine stablo, veze podržavaju međureferiranje i u općem slučaju čine graf. Apstraktna klasa ASTNode je zajednička osnovna klasa za sve čvorove AST-a. Podklase ASTNode odgovaraju određenim sintaktičkim konstrukcijama jezika Java.
Budući da sintaktička stabla mogu trošiti značajnu količinu memorije, JDT kešira samo jedno AST za aktivni uređivač. Za razliku od modela Java, AST se obično smatra 'intermedijarnim', 'privremenim' modelom, na čije elemente klijenti ne bi trebali zadržavati reference van konteksta operacije koja je dovela do stvaranja AST-a.
Tri navedena modela (Java model, AST, veze) zajedno čine osnovu za izgradnju 'inteligentnih razvojnog alata' u JDT, među kojima je moćan Java uređivač s raznim 'asistentima', različitim radnjama obrade izvor kod (među kojima su organizacija liste uvoznika imena i formatiranje prema podešenom stilu), alati za pretraživanje i refaktoring. Pritom, model Java igra posebnu ulogu jer se upravo on koristi kao osnova za vizualno predstavljanje strukture razvijanog aplikacije (npr. u Package Exploreru, Outline-u, Search-u, Call Hierarchy-u i Type Hierarchy-u).
Komponente Eclipse, korištene u 1C:Enterprise Development Tools
Na slici 7 prikazane su komponente Eclipse koje čine osnovu tehnološke platforme za 1C:Enterprise Development Tools.
Slika 7. Eclipse kao platforma za 1C:Enterprise Development Tools
Eclipse Platform osigurava osnovnu infrastrukturu. Razmotrili smo some aspekte ove infrastrukture u prethodnom poglavlju.
(EMF) pruža opće alate za modeliranje strukturiranih podataka. EMF je integriran s Eclipse Platform, ali se može koristiti i odvojeno, u uobičajenim Java aplikacijama. Često, početnici u Eclipse razvoju već su dobro upoznati s EMF-om, iako još uvijek ne razumiju sve nijanse Eclipse Platforme. Jedan od razloga njegove zaslužene popularnosti je univerzalni dizajn, koji uključuje, među ostalim, i unificirani API meta-nivoa, koji omogućava općenito rad s bilo kojim EMF modelom. EMF nudi osnovne implementacije za objekte modela i podsustav generacije koda modela prema meta-modelu, što značajno ubrzava razvoj i smanjuje broj grešaka. Također, EMF sadrži mehanizme za serijalizaciju modela, praćenje promjena u modelu i mnogo više.
Kao i svaki zaista univerzalni alat, EMF je prikladan za rješavanje širokog spektra zadataka vezanih uz modeliranje, ali neki tipovi modela (na primjer, modeli temeljenih na handle-u spomenuti gore) mogu zahtijevati specijaliziranije alate za modeliranje. Govoriti o EMF-u je zahvalan posao, posebno u ograničenim okvirima jednog članka, budući da je to tema opsežne knjige, i to prilično debele. Naglašavamo samo da je kvaliteta sustava generalizacija, koja leži u osnovi EMF-a, omogućila rađanje čitavog spektra projekata posvećenih modeliranju, koji su dio višeg projekta. uz sam EMF. Jedan od takvih projekata je Eclipse Xtext.
nudi infrastrukturu za 'tekstualno modeliranje'. Xtext koristi za sintaktičku analizu izvornog teksta i EMF za predstavljanje rezultantnog ASG (apstraktni semantički graf, koji je u suštini kombinacija AST-a i poveznica), također poznatog kao "semantički model". Gramatika modeliranog jezika pomoću Xtext-a opisuje se na vlastitom jeziku Xtext. To ne samo da omogućava generiranje opisa gramatike za ANTLR, već i dobivanje mehanizma za serijalizaciju AST-a (tj. Xtext pruža i parser i unparser), kontekstne savjete i niz drugih jezičnih komponenti. S druge strane, jezik za opis gramatike korišten u Xtext-u manje je fleksibilan u usporedbi, recimo, s jezikom za opis gramatike u ANTLR-u. Stoga ponekad treba "prilagoditi" jezik koji se implementira Xtext-u, što obično nije problem kada se radi o jeziku koji se razvija ispočetka, ali može biti neprihvatljivo za jezike s već uspostavljenom sintaksom. Unatoč tome, Xtext je trenutno najzreliji, funkcionalno najpotpuniji i najuniverzalniji alat u Eclipse-u za izradu programskih jezika i razvojnih alata za njih. Konkretno, predstavlja idealan alat za brzo prototipiranje. (domain-specific language, DSL). Osim gore spomenutog "jezičnog jezgra" temeljenog na ANTLR-u i EMF-u, Xtext nudi brojne korisne komponente višeg nivoa, uključujući mehanizme indeksiranja, inkrementalne izrade, "pametni uređivač", i još mnogo, mnogo toga, ali izostavlja jezične modele temeljene na rukovanju. Kao i EMF, Xtext je predmet koji zaslužuje posebnu knjigu, i malo je vjerojatno da ćemo moći čak i ukratko raspraviti o svim njegovim mogućnostima.
1C:Enterprise Development Tools aktivno koriste kako EMF sam po sebi, tako i niz drugih Eclipse Modeling projekata. Konkretno, Xtext je jedna od osnovnih komponenti alata za razvoj za jezike 1C:Preduzeće, poput ugrađenog programskog jezika i jezika upita. Druga osnova ovih razvojnih alata je projekt Eclipse Handly, o kojem ćemo detaljnije govoriti (od navedenih komponenti Eclipse-a, on trenutno nije najpoznatiji).
, potprojekt glavnog projekta Eclipse Technology, pojavilo se kao rezultat inicijalne doprinose koda u Eclipse Foundation, kojeg je izvršila tvrtka 1C 2014. godine. Od tada tvrtka 1C nastavlja podržavati razvoj projekta: committeri Handly su zaposlenici tvrtke. Projekt je mali, ali zauzima prilično jedinstvenu nišu unutar Eclipse-a: njegova glavna svrha je podržati razvoj modela temeljenih na rukohvatima.
Glavni arhitektonski principi modela temeljenih na rukohvatima, poput idioma rukohvat/tijelo, razmatrani su ranije na primjeru modela resursa i Java modela. Također je napomenuto da su i model resursa i Java model važne osnove za Eclipse Java razvojne alate (JDT). A budući da praktički svi *DT projekti Eclipse imaju arhitekturu sličnu JDT-u, ne bi bilo preuveličavanje reći da modeli temelji na rukohvatima leže u osnovi mnogih, ako ne i svih IDE-a, izgrađenih na Eclipse Platformi. Na primjer, u Eclipse C/C++ razvojnim alatima (CDT) postoji model temeljen na rukohvatima za C/C++, koji igra u arhitekturi CDT istu ulogu kao i Java model u JDT-u.
Prije pojave Handly, Eclipse nije nudio specijalizirane biblioteke za izradu jezika temeljenog na rukohvatima. Postojeći modeli stvoreni su uglavnom neposrednom prilagodbom koda Java modela (poznatog kao kopiraj/zalijepi), u slučajevima kada to dopušta Eclipse javna licenca (EPL). (Očigledno je da, recimo, za projekte samog Eclipse-a to obično nije pravni problem, što se ne može reći za proizvode s vlasničkim kodom.) Osim karakterističnog kaosa, ova metoda dovodi do dobro poznatih problema: dupliciranja koda, grešaka uvedenih tijekom prilagodbe, itd. Što je još gore, rezultantni modeli ostaju 'stvar u sebi' i ne koriste postojeći potencijal za unifikaciju. Ipak, isticanje zajedničkih pojmova i protokola za modele jezika temeljenog na rukohvatima moglo bi dovesti do stvaranja ponovo upotrebljivih komponenti za rad s njima, slično onome kako je to postignuto s EMF-om.
Ne može se reći da u Eclipse-u nije bilo razumijevanja ovih problema. Još 2005. godine , generalizirajući iskustvo razvoja prototipa CDT-a, potreba za stvaranjem zajedničke infrastrukture za jezične modele, uključujući i modele temeljene na handleu. No, kao što to obično biva, zbog prioritetnijih zadataka ove ideje nikada nisu realizirane. U međuvremenu, faktorizacija koda *DT-projekata i dalje ostaje jedna od nedovoljno obrađenih tema u Eclipseu.
U određenom smislu, projekt Handly ima za cilj rješavati otprilike iste probleme kao EMF, ali za modele temeljene na handleu, a prvenstveno jezične (tj. one koje predstavljaju elemente strukture nekog programskog jezika). U nastavku su navedeni osnovni ciljevi koji su postavljeni prilikom projektiranja Handlyja:
- Izdvajanje glavnih apstrakcija oblasti interesa.
- Smanjenje napora i poboljšanje kvalitete implementacije jezičnih modela temeljenih na handleu kroz ponovnu upotrebu koda.
- Pružanje unificiranog API-ja na meta-nivou za rezultantne modele, koji omogućuje stvaranje zajedničkih komponenti IDE-a koje rade s jezičnim modelima temeljenim na handleu.
- Fleksibilnost i skalabilnost.
- Integracija s Xtextom (u zasebnoj sloju).
Za identifikaciju zajedničkih pojmova i protokola analizirane su postojeće implementacije jezičnih modela temeljenih na handleu. Glavni su sučelja i osnovne implementacije koje pruža Handly, prikazani na slici 8.
Slika 8. Zajednička sučelja i osnovne implementacije elemenata Handly
Sučelje IElement predstavlja handle elementa i zajedničko je za elemente svih modela temeljenih na Handly. Apstraktna klasa Element implementira generički mehanizam handle/body (slika 9).
Slika 9. IElement i generička implementacija handle/body
Osim toga, Handly pruža generički mehanizam obavještavanja o promjenama elemenata modela (slika 10). Kao što se može vidjeti, u cjelini je sličan mehanizmima obavještavanja implementiranim u modelu resursa i Java modelu, te koristi IElementDelta za unificirano predstavljanje informacija o promjenama elementa.
Slika 10. Zajednička sučelja i osnovne implementacije mehanizma obavještavanja Handly
Gore opisani dio Handlyja (slike 9 i 10) može se koristiti za predstavljanje gotovo bilo kojih modela temeljenih na handleu. Za stvaranje jezičnih modela, projekt nudi dodatnu funkcionalnost – posebno, zajednička sučelja i osnovne implementacije za elemente strukture izvornog teksta, takozvane izvorne elemente (slika 8). Sučelje ISourceFile predstavlja izvorni datoteku, dok ISourceConstruct predstavlja element unutar izvorne datoteke. Apstraktne klase SourceFile i SourceConstruct implementiraju generičke mehanizme za podršku radu s izvorim datotekama i njihovim elementima, kao što su rad s tekstualnim međuspremnicima, vezivanje na koordinate elementa u izvornoj datoteci, usklađivanje modela s trenutnim sadržajem međuspremnika radne kopije, itd. Implementacija ovih mehanizama obično predstavlja dovoljno složen zadatak, a Handly može značajno smanjiti napore u razvoju jezičnih modela koji se temelje na handle-ima pružajući kvalitetne osnovne implementacije.
Osim osnovnih mehanizama navedenih gore, Handly nudi infrastrukturu za tekstualne međuspremnike i 'snapshot-ove', podršku za integraciju s urednicima izvorne kodove (uključujući ugrađenu integraciju s Xtext editorom), kao i neke opće UI komponente koje rade s modelima temeljenim na Handly-ju, poput outline framework-a. Za ilustraciju svojih mogućnosti, projekt pruža nekoliko primjera, uključujući implementaciju Java modela na Handly-ju. (U usporedbi s punom implementacijom Java modela u JDT-u, ovaj model je namjerno pojednostavljen radi veće preglednosti.)
Kao što je ranije napomenuto, ozbiljna pažnja prilikom inicijalnog dizajniranja Handly-ja i daljnjeg razvoja posvećena je i nastavlja se posvećivati skalabilnosti i fleksibilnosti.
U principu, modeli temeljen na handle-ima su prilično dobro skalabilni 'po dizajnu'. Na primjer, idiom handle/body omogućava ograničavanje količine memorije koju model koristi. Međutim, postoje i određene nijanse. Tako je prilikom ispitivanja Handly-a na skalabilnost otkriven problem u implementaciji mehanizma obavještavanja – pri promjeni velikog broja elemenata, izgradnja delta trajala je predugo. Ispostavilo se da isti problem postoji i u Java modelu JDT-a, iz kojeg je u svoje vrijeme adaptiran odgovarajući kod. Popravili smo grešku u Handly-ju i pripremili sličan patch za JDT, koji je s zahvalnošću prihvaćen. To je samo jedan od primjera gdje bi implementacija Handly-a u postojeće realizacije modela mogla biti potencijalno korisna, jer bi u tom slučaju takvu grešku bilo moguće ispraviti na samo jednom mjestu.
Kako bi se implementacija Handly u postojeće modele učinila tehnički mogućom, knjižnica mora imati značajnu fleksibilnost. Glavni problem je očuvanje unazadne kompatibilnosti API modela. Ovaj zadatak je rešen jasnim odvojenjem model-specifičnog API-ja, koji definiše i potpuno kontroliše programer, od unificiranog API-ja meta-nivoa koji pruža knjižnica. To ne samo da omogućava tehničku implementaciju Handly-a u postojeće realizacije, već također pruža programeru novog modela značajnu slobodu u dizajniranju API-ja.
Fleksibilnost ima i druge aspekte. Na primer, Handly gotovo ne postavlja ograničenja na strukturu modela i može se koristiti kako za modeliranje jezika opće namene, tako i za jezike usmerene na specifične domene. Pri izgradnji strukture izvornog fajla, Handly ne propisuje određeni oblik predstavljanja AST-a i u principu ne zahteva čak ni postojanje AST-a, čime osigurava kompatibilnost sa praktično bilo kojim mehanizmima sintaktičke analize. Na kraju, Handly podržava potpunu integraciju s Eclipse radnim okruženjem, ali također može raditi i direktno s datotečnim sistemima, zahvaljujući integraciji s (EFS).
Trenutna verzija objavljena je u decembru 2016. godine. Iako je projekat trenutno u fazi inkubacije i API još uvek nije konačno definisan, Handly se već koristi u dva velika komercijalna proizvoda koja su rizikovala da postanu „rani usvojitelji“, i moram reći, za sada nemaju razloga za žaljenje.
Kao što je ranije navedeno, jedan od tih proizvoda je 1C:Enterprise Development Tools, gde se Handly od samog početka koristi za modelovanje elemenata visokog nivoa strukture jezika 1C:Enterprise, 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 aplikacije (application-specific instruction-set processor, ASIP), korišćeno kako unutar same češke kompanije Codasip, tako i od strane njenih klijenata, među kojima su , , , Codasip koristi Handly u produkciji od 2015. godine, počevši od verzije Handly 0.2. Najnovija verzija Codasip Studija koristi verziju 0.5, objavljenu u lipnju 2016. godine. Ondřej Ilčík, koji vodi razvoj IDE-a u Codasipu, u kontaktu je s projektom, pružajući izuzetno važnu povratnu informaciju od strane "eksternog adutera". Čak je uspio pronaći malo slobodnog vremena da se izravno uključi u razvoj projekta, implementirajući UI sloj (~ 4000 linija koda) za jedan od primjera Handly, model Java. Detaljnije informacije "iz prve ruke" o korištenju Handly od strane adutera mogu se pronaći na stranici projekta.
Nadamo se da će nakon izdanja verzije 1.0 s jamstvom stabilnosti API-ja i izlaska projekta iz stanja inkubacije, Handly dobiti nove adutere. Za sada, projekt nastavlja s ispitivanjem i daljnjim unapređenjem API-ja, izdajući po dva "velika" izdanja godišnje – u lipnju (na isti datum kao i istovremeno izdanje Eclipse) i prosincu, osiguravajući predvidljiv raspored na koji se aduteri mogu osloniti. Također, važno je napomenuti da stopa grešaka projekta ostaje stabilno niska, a Handly od samih prvih verzija pouzdano radi u proizvodima ranih adutera. Za daljnje upoznavanje s Eclipse Handly možete koristiti i .
Izvor: habr.com
