Eclipse som teknologisk plattform för 1C:Enterprise Development Tools

Antagligen, Eclipse behöver inte längre någon särskild introduktion. Många känner till Eclipse tack vare Eclipse Java Development Tools (JDT). Just denna populära öppen källkods Java IDE förknippas av de flesta utvecklare med ordet “Eclipse”. Men Eclipse är också en utbyggbar plattform för integration av utvecklingsverktyg (Eclipse Platform), och en rad IDE:er som bygger på den, inklusive JDT. Eclipse omfattar också Eclipse Project, ett övergripande projekt som koordinerar utvecklingen av Eclipse Platform och JDT, samt Eclipse SDK – den levererade produkten av denna utveckling. Slutligen är Eclipse en öppen källkods-stiftelse med ett stort samhälle av projekt, av vilka många inte alls är skrivna i Java eller relaterar till utvecklingsverktyg (till exempel projekt Eclipse IoT och Eclipse Science). Världen av Eclipse är mycket mångsidig.

I denna artikel, som har en översiktlig karaktär, ska vi försöka utforska några grundläggande aspekter av Eclipse-arkitekturen som en plattform för utveckling av integrerade utvecklingsverktyg och ge en första förståelse av komponenterna i Eclipse som utgör fundamentet för den teknologiska plattformen för den "nya Konfiguratorn" 1C:Enterprise, 1C:Enterprise Utvecklingsverktyg. Naturligtvis kommer en sådan genomgång ofrånkomligen att vara ganska ytlig och begränsad, också därför att vi riktar oss till en publik som inte bara är utvecklare av Eclipse. Vi hoppas dock att även erfarna Eclipse-utvecklare kan hitta intressant information i artikeln. Till exempel kommer vi att berätta om en av "hemligheterna med Eclipse", ett relativt nytt och fortfarande lite känt projekt Eclipse Handly, som grundades och stöds av företaget 1C.

Introduktion till Eclipse-arkitekturen

Vi ska först titta på några allmänna aspekter av Eclipse-arkitekturen med hjälp av Eclipse Java Development Tools (JDT). Valet av just JDT som exempel är inte slumpmässigt. Detta var den första integrerade utvecklingsmiljön som dök upp i Eclipse. De andra *DT-projekten i Eclipse, såsom Eclipse C/C++ Development Tooling (CDT), skapades senare och lånade både grundläggande arkitekturprinciper och specifika kodfragment från JDT. De arkitektoniska grunderna som lagts i JDT är fortfarande aktuella för nästan alla IDE:er som byggts ovanpå Eclipse Platform, inklusive 1C:Enterprise Development Tools.

Först och främst bör det påpekas att Eclipse kännetecknas av en tydlig arkitektonisk uppdelning, där språkoberoende funktionalitet separeras från funktionaliteten avsedd för specifika programmeringsspråk, och där UI-oberoende "kärnkomponenter" separeras från komponenter relaterade till stödet för användargränssnittet.

Eclipse Plattformen definierar en gemensam, språkoberoende infrastruktur, medan Java utvecklingsverktyg tillför Eclipse en fullt funktionell Java IDE. Både Eclipse Plattformen och JDT består av flera komponenter, där var och en hör till antingen det UI-oberoende "kärnan" eller UI-lagret (se bild 1).

Bild 1. Eclipse Plattform och JDT

Låt oss lista de viktigaste komponenterna i Eclipse Plattformen:

• Körning — Definierar plugin-infrastrukturen. Eclipse kännetecknas av en modulär arkitektur. I grunden är Eclipse en samling av "utvidgningspunkter" och "utvidgningar".
• Arbetsyta — Hanterar ett eller flera projekt. Ett projekt består av mappar och filer som direkt återspeglas i filsystemet.
• Standard Widget Toolkit (SWT) — Tillhandahåller grunderna för användargränssnittet, integrerat med operativsystemet.
• JFace — Tillhandahåller ett antal UI-ramverk byggda ovanför SWT.
• Workbench — Definierar UI-paradigmen för Eclipse: redaktörer, vyer, perspektiv.

Det bör nämnas att Eclipse Plattformen också erbjuder många andra användbara komponenter för att bygga integrerade utvecklingsverktyg, bland vilka Debug, Compare, Search och Team kan nämnas. En särskild omtanke går till JFace Text – grunden för att bygga "smartare källkodredigerare". Tyvärr är det inte möjligt att ge en snabb översikt av dessa komponenter, liksom komponenterna i UI-lagret i denna artikel, så i den återstående delen av detta avsnitt kommer vi att begränsa oss till att ge en översikt över de viktigaste "kärnkomponenterna" i Eclipse Plattformen och JDT.

Kärn Körning

Eclipses plugin-infrastruktur är baserad på OSGi och tillhandahålls av projektet Eclipse Equinox. Varje Eclipse-plugin är en OSGi-bundle. OSGi-specifikationen definierar bland annat mekanismer för versionering och beroendeupplösning. Utöver dessa standardmekanismer introducerar Equinox begreppet utvidgningspunktVarje plugin kan definiera sina egna utvidgningspunkter och tillföra ytterligare funktionalitet till systemet ("utvidgningar"), genom att använda utvidgningspunkter som definieras av samma eller andra plugins. En detaljerad beskrivning av mekanismerna bakom OSGi och Equinox ligger utanför ramen för denna artikel. Det bör noteras att moduleringen i Eclipse är heltäckande (varje delsystem, inklusive Runtime, består av en eller flera plugins), och praktiskt taget allt i Eclipse är en utvidgning. Dessa principer var inbakade i Eclipse-arkitekturen långt innan OSGi infördes (vid den tidpunkten användes en egen teknologi, som till stor del liknar OSGi).

Core Workspace

Nästan varje integrerad utvecklingsmiljö baserad på Eclipse Platform arbetar med Eclipse workspace. Workspace innehåller vanligtvis källkoden för den applikation som utvecklas i IDE:n. Workspace speglar direkt filsystemet och består av projekt som innehåller mappar och filer. Dessa projekt, mappar och filer kallas resurser workspace. Implementeringen av workspace i Eclipse fungerar som en cache i förhållande till filsystemet, vilket avsevärt ökar hastigheten för traversering av resurs trädet. Dessutom tillhandahåller workspace en rad extra tjänster, inklusive mekanismen för notifiering av resursändringar och infrastrukturen för inkrementella byggare.

Komponenten Core Resources (plugin org.eclipse.core.resources) är ansvarig för att stödja workspace och dess resurser. Denna komponent ger i synnerhet programmatisk åtkomst till workspace i form av resursmodeller.För att arbeta effektivt med denna modell behöver kunderna ett enkelt sätt att representera en länk till en resurs. Det skulle vara önskvärt att objektet som lagrar resursens tillstånd direkt i modellen är dolt för kundåtkomst. Annars, vid till exempel borttagning av en fil, skulle klienten kunna fortsätta att hålla ett objekt som inte längre finns i modellen, vilket skulle leda till problem. Eclipse löser detta problem genom att använda något som kallas handle resursen. Handle fungerar som en nyckel (den vet endast sökvägen till resurserna i workspace) och kontrollerar helt och hållet åtkomsten till det interna modellobjektet, som direkt lagrar information om resursens tillstånd. Denna design är en variation av mönstret Handle/Body.

Figur 2 illustrerar idiomen Handle/Body i förhållande till resursmodellen. Gränssnittet IResource representerar handtaget för resursen och fungerar som ett API, till skillnad från klassen Resource som implementerar detta gränssnitt, samt klassen ResourceInfo som representerar kroppen, vilka inte är API:er. Det är värt att påpeka att handtaget endast känner till sökvägen till resursen relativt rötter i arbetsytan och inte innehåller en referens till resource info. Objekten resource info bildar det så kallade "elementträd". Denna dat Struktur är helt materialiserad i minnet. För att hitta en instans av resource info som motsvarar ett visst handtag, traverseras elementträdet enligt sökvägen som lagras i detta handtag.

Figur 2. IResource och ResourceInfo

Som vi kommer att se senare används den grundläggande designen av resursmodellen (som kan kallas handtagsbaserad) i Eclipse och för andra modeller. Låt oss nu lista några karakteristiska egenskaper hos denna design:

• Handtaget är en värdeobjekt (value object). Värdeobjekt är icke-mutanabla (immutable) objekt, vars likhet inte baseras på identitet. Sådana objekt kan användas säkert som nycklar i hashade containrar. Flera instanser av ett handtag kan referera till samma resurs. För att jämföra dem bör metoden equals(Object) användas.
• Handtaget definierar resurens beteende, men innehåller ingen information om resurens tillstånd (de enda uppgifter det lagrar är "nyckeln", sökvägen till resursen).
• Handtaget kan referera till en icke-existerande resurs (antingen en resurs som ännu inte har skapats eller en resurs som redan har tagits bort). Existensen av resursen kan kontrolleras med metoden IResource.exists().
• Vissa operationer kan utföras enbart baserat på informationen som lagras i själva handtaget (så kallade handtagsbara operationer). Exempel på detta inkluderar IResource.getParent(), getFullPath(), osv. Resursen behöver inte nödvändigtvis existera för att en sådan operation ska lyckas. Operationer som kräver att resursen existerar för att lyckas kastar ett undantag (CoreException) om resursen inte finns.

Eclipse tillhandahåller en effektiv mekanism för notifiering om förändringar i resurser i arbetsytan (se bild 3). Resurser kan förändras både genom åtgärder som utförs i Eclipse IDE och genom att synkronisera med filsystemet. I båda fallen får de registrerade klienterna detaljerad information om förändringarna i form av "resursdeltan" (resource delta). Deltat beskriver förändringarna mellan två tillstånd av (under-)trädet med resurser i arbetsytan och är självt ett träd där varje nod beskriver förändringen av en viss resurs och innehåller en lista med deltan på nästa nivå som beskriver förändringar i underordnade resurser.

Bild 3. IResourceChangeEvent och IResourceDelta

Den notifieringsmekanism som baseras på resursdeltan har följande egenskaper:

• En enskild förändring och flera förändringar beskrivs med samma struktur, eftersom deltastrukturen bygger på principen om rekursiv komposition. Klienter som registrerat sig kan bearbeta notifieringar om resursförändringar genom att rekursivt traversera delta-trädet.
• Deltat innehåller all information om resursändringen, inklusive dess flyttning och/eller ändring av tillhörande "markörer" (där markörer representerar till exempel kompilatorfel).
• Eftersom referenser till resurser görs via handles kan deltat naturligt referera till en borttagen resurs.

Som vi snart kommer att se är de grundläggande komponenterna i designen av notifieringsmekanismen för resursmodellens förändringar också relevanta för andra handle-baserade modeller.

JDT Core

Modellen för resurser i Eclipse-arbetsytan är en grundläggande språkoberoende model. Komponenten JDT Core (plugin org.eclipse.jdt.core) tillhandahåller ett API för navigering och analys av arbetsytans struktur ur ett Java-perspektiv, den så kallade "Java-modellen" (Java-modell). Detta API definieras i termer av Java-element, till skillnad från det underliggande API:t för resursmodellen, som definieras i termer av mappar och filer. De viktigaste gränssnitten för Java-elementens träd visas i bild 4.

Bild 4. Element i Java-modellen

Java-modellen använder samma idiom handle/body som resursmodellen (fig. 5). IJavaElement är handle, medan JavaElementInfo fungerar som body. Gränssnittet IJavaElement definierar ett protokoll som är gemensamt för alla Java-element. Vissa av dess metoder är endast handle: getElementName(), getParent() osv. JavaElementInfo-objektet lagrar tillståndet för det motsvarande elementet: dess struktur och attribut.

Fig. 5. IJavaElement och JavaElementInfo

Java-modellen har vissa skillnader i implementationen av den grundläggande handle/body-designen jämfört med resursmodellen. Som nämnts tidigare innehåller resursmodellens elementträd, vars noder är objekt med resursinformation, helt i minnet. Men i Java-modellen kan det finnas betydligt fler element än i resursträdet, eftersom den även representerar den interna strukturen av .java- och .class-filer: typer, fält och metoder.

För att undvika full materialisering av hela elementträdet i minnet använder implementationen av Java-modellen en begränsad LRU-cache för elementinfo, där nyckeln är handle IJavaElement. Elementinfo-objekt skapas vid behov när navigering genom elementträdet sker. De minst använda elementen trängs ut från cachen, och minnesanvändningen från modellen hålls inom den angivna storleken på cachen. Detta är ytterligare en fördel med handle-baserad design, som helt döljer sådana implementationsdetaljer från klientkoden.

Mekanismen för notifiering av ändringar i Java-element är i allmänhet liknande den mekanism för förändringsspårning som diskuterades ovan för resursarbetsytan. Klienten som önskar följa ändringar i Java-modellen prenumererar på notifieringar som presenteras i form av ett objekt ElementChangedEvent, som innehåller IJavaElementDelta (fig. 6).

Fig. 6. ElementChangedEvent och IJavaElementDelta

Java-modellen innehåller ingen information om kroppar för metoder eller namnutredning, så för en detaljerad analys av kod skriven i Java tillhandahåller JDT Core en ytterligare (icke-handle-baserad) modell: abstrakt syntaxträd (abstrakt syntaxträd, AST). AST representerar resultatet av syntaxanalysen av den ursprungliga texten. Noder i AST motsvarar elementen i strukturen för den ursprungliga modulen (deklarationer, operationer, uttryck osv.) och innehåller information om koordinaterna för det motsvarande elementet i den ursprungliga texten, samt (som valfritt) information om namnupplösning i form av länkar till så kallade bindings. Bindningar är objekt som representerar namngivna entiteter, såsom typer, metoder och variabler, som är kända för kompilatorn. Till skillnad från noderna i AST, som bildar ett träd, stöder bindningar korsreferenser och bildar i allmänhet en graf. Den abstrakta klassen ASTNode är en gemensam basklass för alla noder i AST. Underklasser av ASTNode motsvarar specifika syntaktiska konstruktioner i Java-språket.

Eftersom syntaktiska träd kan använda en betydande mängd minne, cachen JDT endast ett AST för den aktiva redigeraren. Till skillnad från Java-modellen betraktas AST vanligtvis som en "intermediär", "temporär" modell, vars element kunder inte bör behålla referenser till utanför kontexten för operationen som ledde till skapandet av AST.

De tre nämnda modellerna (Java-modell, AST, bindningar) utgör tillsammans grunden för att bygga "intelligenta utvecklingsverktyg" i JDT, inklusive en kraftfull Java-redigerare med olika "hjälpare", olika operationer för att bearbeta källkoden (som organisering av importlista för namn och formatering enligt den konfigurerade stilen), verktyg för sökning och refaktorisering. Här spelar Java-modellen en särskild roll, eftersom den används som grund för den visuella representationen av strukturen för den utvecklade applikationen (till exempel i Package Explorer, Outline, Search, Call Hierarchy och Type Hierarchy).

Eclipse-komponenterna som används i 1C:Enterprise Developments Tools

Figur 7 visar Eclipse-komponenterna som utgör grunden för den teknologiska plattformen för 1C:Enterprise Development Tools.

Figur 7. Eclipse som plattform för 1C:Enterprise Development Tools

Eclipse-plattformen tillhandahåller grundläggande infrastruktur. Vi har granskad några aspekter av denna infrastruktur i den föregående delen.

Eclipse Modeling Framework (EMF) tillhandahåller generella verktyg för modellering av strukturerad data. EMF är integrerat med Eclipse-plattformen, men kan också användas separat i vanliga Java-applikationer. Många nybörjare inom Eclipse-utveckling är redan väl bekanta med EMF, även om de kanske inte helt förstår detaljerna i Eclipse-plattformen. En av anledningarna till dess välförtjänta popularitet är den universella designen, som inkluderar en enhetlig meta-nivå-API som gör det möjligt att arbeta generellt med vilken EMF-modell som helst. De grundläggande implementationerna av EMF för modelobjekt och systemet för kodgenerering från meta-modellen ökar avsevärt utvecklingshastigheten och minskar mängden fel. EMF innehåller även mekanismer för serialisering av modeller, spårning av förändringar i modeller och mycket mer.

Som med alla verkligt universella verktyg är EMF lämpligt för att lösa ett brett spektrum av uppgifter relaterade till modellering, men vissa typer av modeller (som de hanterade modeller som diskuterats ovan) kan behöva mer specialiserade verktyg för modellering. Att prata om EMF är en otacksam uppgift, särskilt inom ramen för en enda artikel, eftersom det är ett ämne för en separat bok, och en ganska tjock sådan. Vi ska bara påpeka att det kvalitativa systemet för generaliseringar som ligger till grund för EMF har gjort det möjligt för en hel rad projekt, som ägnas åt modellering, att se dagens ljus och som ingår i det övergripande projektet. Eclipse Modellering tillsammans med själva EMF. Ett av dessa projekt är Eclipse Xtext.

Eclipse Xtext tillhandahåller infrastrukturen för "textuell modellering". Xtext använder ANTLR för syntaktisk analys av källtext och EMF för att representera den resulterande ASG (abstract semantic graph, som i huvudsak är en kombination av AST och bindings), även kallad "semantisk modell". Grammatiken för det språk som modelleras med Xtext beskrivs på sitt eget Xtext-språk. Detta gör det möjligt att inte bara generera en grammatisk beskrivning för ANTLR, utan också att erhålla en mekanism för serialisering av AST (dvs. Xtext tillhandahåller både parser och unparser), kontextuell hjälp och en rad andra språkkomponenter. Å andra sidan är språket för grammatikbeskrivning som används i Xtext mindre flexibelt jämfört med språket för grammatikbeskrivning i ANTLR. Därför är det ibland nödvändigt att "böja" det implementerade språket till Xtext, vilket vanligtvis inte är ett problem om det handlar om ett nyutvecklat språk, men kan vara oacceptabelt för språk med redan etablerad syntax. Trots detta är Xtext för närvarande det mest mogna, funktionellt kompletta och universella verktyget i Eclipse för att bygga programmeringsspråk och verktyg för dem. Särskilt är det ett perfekt verktyg för snabb prototypframställning. domänspecifika språk (domain-specific language, DSL). Förutom det nämnda "språkets kärna" baserad på ANTLR och EMF, erbjuder Xtext många användbara komponenter av högre nivå, inklusive indexeringsmekanismer, inkrementell byggnation, "smart redigerare" och mycket, mycket mer, men lämnar språkbaserade handle-baserade modeller utanför. Precis som EMF är Xtext ett ämne värt en egen bok, och vi kommer knappast att kunna berättar om alla dess möjligheter ens kort.

1C:Enterprise Development Tools använder både EMF i sig och en rad andra projekt inom Eclipse Modeling. Särskilt är Xtext en av grundpelarna i utvecklingsverktygen för sådana språk inom 1C: Företag, såsom det inbyggda programmeringsspråket och frågespråket. En annan grund för dessa utvecklingsverktyg är projektet Eclipse Handly, som vi kommer att gå mer på djupet med (av de nämnda komponenterna inom Eclipse är det hittills den minst kända).

Eclipse Handly, ett underprojekt till det överordnade projektet Eclipse Technology, skapades som ett resultat av det initiala kodbidraget till Eclipse Foundation från företaget 1C år 2014. Sedan dess har företaget 1C fortsatt att stödja utvecklingen av projektet: committers på Handly är anställda hos företaget. Projektet är litet, men upptar en ganska unik nisch inom Eclipse: dess huvudsakliga mål är att stödja utvecklingen av handle-baserade modeller.

De grundläggande arkitekturprinciperna för handle-baserade modeller, såsom handle/body-idiomet, har diskuterats ovan med exempel från resursmodellen och Java-modellen. Det noterades där att både resursmodellen och Java-modellen är viktiga grundstenar för Eclipse Java Development Tools (JDT). Eftersom nästan alla *DT-projekt i Eclipse har en arkitektur liknande JDT, är det ingen överdrift att säga att handle-baserade modeller ligger till grund för många, om inte alla, IDE:er byggda ovanpå Eclipse Platform. Till exempel innehåller Eclipse C/C++ Development Tooling (CDT) en handle-baserad modell för C/C++, som spelar samma roll i CDT:s arkitektur som Java-modellen gör i JDT.

Innan Handly lanserades erbjöd Eclipse inga specialiserade bibliotek för att bygga språkbaserade handle-modeller. De nuvarande modellerna skapades mestadels genom direkt anpassning av koden från Java-modellen (även känd som copy/paste), i de fall där det är tillåtet enligt Eclipse Public License (EPL). (Det är uppenbart att, till exempel, för Eclipses egna projekt vanligtvis inte är ett juridiskt problem, vilket inte kan sägas om produkter med stängd källkod.) Förutom den karaktäristiska bristen på systematik leder denna metodik till välkända problem: kodduplicering, fel som införts genom anpassningar, osv. Ännu värre, de resulterande modellerna förblir "en sak för sig" och utnyttjar inte den befintliga potentialen för enhetlighet. Att identifiera gemensamma begrepp och protokoll för språkbaserade handle-modeller skulle kunna leda till skapandet av återanvändbara komponenter för arbete med dem, på liknande sätt som det hände i fallet med EMF.

Det går inte att säga att det i Eclipse inte funnits en förståelse för dessa problem. Redan 2005 Martin Aeschlimann, med en sammanfattning av erfarenheterna från utvecklingen av CDT-prototypen, argumenterade Behovet av att skapa en gemensam infrastruktur för språkmodeller, inklusive handle-baserade modeller. Men som det ofta är, på grund av mer prioriterade uppgifter, kom vi aldrig till genomförandet av dessa idéer. Under tiden kvarstår kodfaktoriseringen av *DT-projekt som en av de ämnen som inte är tillräckligt utforskade inom Eclipse.

På ett visst sätt syftar projektet Handly till att lösa ungefär samma uppgifter som EMF, men för handle-baserade modeller, främst språkliga (dvs. som representerar strukturelement av ett visst programmeringsspråk). Nedan listas de huvudsakliga målen som sattes vid utformningen av Handly:

• Uppdelning av de grundläggande abstraktionerna i ämnesområdet.
• Minska ansträngningarna och öka kvaliteten på implementeringen av språkliga handle-baserade modeller genom återanvändning av kod.
• Tillhandahålla ett enhetligt API på meta-nivå till de resulterande modellerna, vilket möjliggör skapandet av gemensamma IDE-komponenter som arbetar med språkliga handle-baserade modeller.
• Flexibilitet och skalbarhet.
• Integration med Xtext (i ett separat lager).

För att identifiera gemensamma begrepp och protokoll har befintliga implementationer av språkliga handle-baserade modeller analyserats. De grundläggande gränssnitten och de grundläggande implementationerna som tillhandahålls av Handly visas i figur 8.

Figur 8. Gemensamma gränssnitt och grundläggande implementationer av Handly-element.

Gränssnittet IElement representerar handtaget av ett element och är gemensamt för elementen i alla modeller baserade på Handly. Den abstrakta klassen Element implementerar den generiska mekanismen handle/body (figur 9).

Figur 9. IElement och generisk implementering av handle/body.

Dessutom tillhandahåller Handly en generell mekanism för notifiering av förändringar av modelelement (figur 10). Som man kan se är den i stora drag liknande notifieringsmekanismerna implementerade i resursmodellen och Java-modellen, och använder IElementDelta för en enhetlig presentation av information om förändringen av ett element.

Figur 10. Gemensamma gränssnitt och grundläggande implementationer av Handlys notifieringsmekanism.

Den del av Handly som diskuterats ovan (figur 9 och 10) kan användas för att representera praktiskt taget alla handle-baserade modeller. För att skapa språkliga modeller erbjuder projektet ytterligare funktionalitet - i synnerhet gemensamma gränssnitt och grundläggande implementationer för elementen i strukturen av den ursprungliga texten, de så kallade source elements. (fig. 8). Gränssnittet ISourceFile representerar en ursprungsfil, medan ISourceConstruct är ett element inom ursprungsfilen. Abstrakta klasserna SourceFile och SourceConstruct implementerar generiska mekanismer för att stödja arbetet med ursprungsfiler och deras element, till exempel arbete med textbuffertar, bindning till koordinater av elementet i den ursprungliga texten, samordning av modellen med det aktuella innehållet i arbetskopians buffert, etc. Implementeringen av dessa mekanismer är vanligtvis en ganska komplex uppgift, och Handly kan avsevärt minska utvecklingsinsatserna för språkmodeller baserade på handles genom att erbjuda kvalitativa grundimplementationer.

Förutom de grundläggande mekanismerna som nämnts ovan, erbjuder Handly infrastruktur för textbuffertar och snapshots, stöd för integration med källkodseditorer (inklusive den inbyggda integrationen med Xtext-editor), samt vissa allmänna UI-komponenter som arbetar med Handly-baserade modeller, såsom outline-ramverket. För att illustrera sina möjligheter tillhandahåller projektet flera exempel, inklusive en implementering av en Java-modell baserad på Handly. (Jämfört med den fullständiga implementeringen av Java-modellen i JDT, är denna modell avsiktligt något förenklad för större tydlighet.)

Som nämnts tidigare har stort fokus lagts på skalbarhet och flexibilitet vid den initiala designen och den fortsatta utvecklingen av Handly.

I princip skalas handle-baserade modeller ganska väl "by design". Till exempel möjliggör idiomet handle/body att begränsa mängden minne som modellen använder. Men det finns också nyanser. Under tester av Handly för skalbarhet upptäcktes ett problem i implementeringen av notifieringsmekanismen – att bygga deltas tog för mycket tid vid ändring av ett stort antal element. Det visade sig att samma problem även fanns i Java-modellen JDT, från vilken den motsvarande koden en gång anpassades. Vi åtgärdade felet i Handly och förberedde en motsvarande patch för JDT, som mottogs med tacksamhet. Detta är bara ett exempel på när implementeringen av Handly i befintliga modellimplementationer skulle kunna vara potentiellt användbar, eftersom detta skulle ha möjliggjort att åtgärda felet på ett enda ställe.

För att göra integrationen av Handly tekniskt möjlig i befintliga implementationer av modeller måste biblioteket uppvisa betydande flexibilitet. Huvudproblemet är att bevara bakåtkompatibiliteten för modellens API. Denna uppgift har lösts i Handly 0.5 genom en tydlig separation av det modell-specifika API:t, som definieras och kontrolleras helt av utvecklaren, från det enhetliga meta-nivå API:t som tillhandahålls av biblioteket. Detta gör inte bara teknisk integration av Handly i befintliga implementationer möjlig, utan ger också utvecklaren av den nya modellen betydande frihet vid utformningen av API:t.

Flexibilitet har också andra aspekter. Till exempel ställer Handly nästan inga krav på modellens struktur och kan användas för både allmänna programmeringsspråk och domänspecifika språk. Vid bygget av grundfilens struktur föreskriver Handly ingen specifik form av AST-representation och kräver i princip inte ens förekomsten av AST, vilket säkerställer kompatibilitet med nästan alla syntaktiska analysmekanismer. Slutligen stöder Handly fullständig integration med Eclipse workspace, men kan också fungera direkt med filsystem, tack vare integrationen med Eclipse File System (EFS).

Den nuvarande versionen Handly 0.6 släpptes i december 2016. Trots att projektet för närvarande är i inkubationsfasen och API:t ännu inte är slutgiltigt fastställt, används Handly redan i två stora kommersiella produkter som vågat agera som "tidiga användare", och hittills har de inte ångrat detta.

Som nämnts tidigare är en av dessa produkter 1C:Enterprise Development Tools, där Handly används från början för att modellera elementen i den hög-nivå strukturen för språk som ingår i 1C:Enterprise, såsom det inbyggda programmeringsspråket och frågespråket. Den andra produkten är mindre känd för allmänheten. Det är Codasip Studio, en integrerad miljö för design av domänspecifika processorer (application-specific instruction-set processor, ASIP), som används både inom det tjeckiska företaget Codasip och av dess kunder, bland vilka AMD, AVG, Mobileye, Sigma Designs. Codasip använder Handly i produktion sedan 2015, med version Handly 0.2. Den senaste versionen av Codasip Studio använder version 0.5, som släpptes i juni 2016. Ondřej Ilčík, som leder utvecklingen av IDE på Codasip, är i kontakt med projektet och ger viktig feedback från externa användare. Han lyckades till och med hitta lite fritid för att direkt delta i projektutvecklingen genom att implementera ett användargränssnitt (ungefär 4000 rader kod) för ett av Handly-exemplen, en Java-modell. Mer information Framgångshistorier för projektet.

Vi hoppas att efter lanseringen av version 1.0 med garanti för API:ets stabilitet och projektets utträde ur inkubationsstaten, kommer Handly få nya användare. Tills dess fortsätter projektet att testa och förbättra API:t, med två stora versioner som släpps varje år – i juni (samma datum som den samtidiga utgivningen av Eclipse) och december, vilket ger ett förutsägbart schema som användare kan lita på. Dessutom är buggrate för projektet stadig och Handly har pålitligt fungerat i produkterna hos tidiga användare sedan de första versionerna. För vidare kännedom om Eclipse Handly kan du använda Kom igång-guide och Arkitektonisk översikt.

Källa: habr.com