Eclipse som teknologiplattform for 1C:Enterprise Development Tools

Kanskje, Eclipse trenger ikke lengre noen spesiell presentasjon. Mange er kjent med Eclipse takket være Eclipse Java development tools (JDT). Det er nettopp denne populære open-source Java IDE som de fleste utviklere assosierer med ordet “Eclipse”. Men Eclipse er også en utvidbar plattform for integrering av utviklingsverktøy (Eclipse Platform), samt en rekke IDE-er bygget på den, inkludert JDT. Eclipse er også Eclipse Project, et toppnivåprosjekt som koordinerer utviklingen av Eclipse Platform og JDT, samt Eclipse SDK – det leverte resultatet av denne utviklingen. Til slutt er Eclipse også en open-source Foundation med et stort fellesskap av prosjekter, hvor ikke alle er skrevet i Java eller er relatert til utviklingsverktøy (for eksempel prosjekter Eclipse IoT og Eclipse Science). Verdenen av Eclipse er svært mangfoldig.

I denne artikkelen, som er av generell karakter, vil vi prøve å se på noen grunnleggende aspekter av Eclipse-arkitekturen som en plattform for bygging av integrerte utviklingsverktøy og gi en innledende forståelse av komponentene i Eclipse som utgjør grunnlaget for den teknologiske plattformen for «den nye Konfiguratoren» 1C: Enterprise, 1C:Enterprise Development Tools. Naturligvis vil en slik gjennomgang uunngåelig være delvis overfladisk og ganske begrenset, også fordi vi ikke bare retter oss mot Eclipse-utviklere som målgruppe. Vi håper imidlertid at selv erfarne Eclipse-utviklere vil kunne finne interessant informasjon i artikkelen. For eksempel vil vi fortelle om ett av «Eclipse-hemmelighetene», et relativt nytt og lite kjent prosjekt Eclipse Handly, som ble grunnlagt og støttet av firmaet 1C.

Innledning til Eclipse-arkitektur

La oss først se på noen generelle aspekter av Eclipse-arkitekturen med eksempelet Eclipse Java development tools (JDT). Valget av JDT som eksempel er ikke tilfeldig. Det er det første integrerte utviklingsmiljøet som kom til Eclipse. De andre *DT-prosjektene i Eclipse, som Eclipse C/C++ Development Tooling (CDT), ble laget senere og lånte både de grunnleggende arkitektoniske prinsippene og enkelte fragmenter av kildekoden fra JDT. Grunnlagene for arkitekturen som er lagt i JDT, er fortsatt relevante for nesten enhver IDE bygget på Eclipse Platform, inkludert 1C:Enterprise Development Tools.

Først og fremst må det påpekes at Eclipse har en ganske klar arkitektonisk oppdeling, med separasjon av språk-uavhengig funksjonalitet fra funksjonalitet designet for å støtte spesifikke programmeringsspråk, og separasjon av UI-uavhengige "kjernen" (core) komponenter fra komponenter som er relatert til støtte for brukergrensesnittet.

Slik definerer Eclipse Platform en felles, språk-uavhengig infrastruktur, mens Java utviklingsverktøy legger til en fullverdig Java IDE til Eclipse. Både Eclipse Platform og JDT består av flere komponenter, hver av dem knyttet enten til det UI-uavhengige "kjernen" eller til UI-laget (figur 1).

Figur 1. Eclipse Platform og JDT

La oss liste opp hovedkomponentene i Eclipse Platform:

• Runtime — Definerer plugin-infrastrukturen. Eclipse har en modulær arkitektur. I realiteten er Eclipse en samling av "utvidelsespunkter" og "utvidelser".
• Workspace — Håndterer ett eller flere prosjekter. Et prosjekt består av mapper og filer som vises direkte i filsystemet.
• Standard Widget Toolkit (SWT) — Tilbyr grunnleggende brukergrensesnittelementer integrert med operativsystemet.
• JFace — Tilbyr en serie UI-rammeverk bygget over SWT.
• Workbench — Definerer UI-paradigmet for Eclipse: redaktører, visninger, perspektiver.

Det må sies at Eclipse Platform også tilbyr mange andre nyttige komponenter for oppbyggingen av integrerte utviklingsverktøy, blant annet kan Debug, Compare, Search, og Team nevnes. Det bør også nevnes JFace Text – grunnlaget for å bygge "smarte redaktører" for kildekode. Dessverre er det ikke mulig å gi en overfladisk gjennomgang av disse komponentene, så vel som komponentene i UI-laget, innenfor rammen av denne artikkelen, derfor vil vi i denne delen begrense oss til en oversikt over de viktigste "kjerne" komponentene i Eclipse Platform og JDT.

Core Runtime

Eclipse-plugininfrastrukturen er basert på OSGi og leveres av prosjektet Eclipse Equinox. Hver Eclipse-plugin er en OSGi-bundle. OSGi-spesifikasjonen definerer blant annet versjonerings- og avhengighetsløsningsmekanismer. I tillegg til disse standardmekanismene, introduserer Equinox begrepet utvidelsesspunkterHver plug-in kan definere sine egne utvidelsespunkter, samt tilføre systemet ekstra funksjonalitet ("utvidelser"), ved å bruke utvidelsespunkter definert av denne eller andre plug-ins. En detaljert beskrivelse av OSGi og Equinox-mekanismene går utenfor rammen av denne artikkelen. Det er verdt å merke seg at modularisering i Eclipse er total (hvert subsystem, inkludert Runtime, består av én eller flere plug-ins), og praktisk talt alt i Eclipse er en utvidelse. Disse prinsippene ble forankret i Eclipse-arkitekturen lenge før implementeringen av OSGi (på det tidlige tidspunktet ble det brukt en egen teknologi, som i stor grad ligner OSGi).

Kjerne arbeidsområde

Nær sagt hver integrerte utviklingsmiljø bygget på Eclipse-plattformen arbeider med Eclipse arbeidsområde. Det er arbeidsområdet som vanligvis inneholder kilden til applikasjonen som utvikles i IDE. Arbeidsområdet samsvarer direkte med filsystemet og består av prosjekter som inneholder mapper og filer. Disse prosjektene, mappene og filene kalles ressurser arbeidsområdet. Implementeringen av arbeidsområdet i Eclipse fungerer som en type cache i forhold til filsystemet, noe som merkbart øker hastigheten ved gjennomgang av ressursens trestruktur. I tillegg tilbyr arbeidsområdet en rekke ekstra tjenester, inkludert mekanisme for varsling av endringer i ressurser og infrastruktur for inkrementelle byggere.

Core Resources-komponenten (plug-in org.eclipse.core.resources) er ansvarlig for å støtte arbeidsområdet og dets ressurser. Denne komponenten gir spesielt programmatisk tilgang til arbeidsområdet i form av ressursmodell. For effektivt arbeid med denne modellen trenger klientene en enkel måte å representere en referanse til en ressurs. I denne forbindelse ville det være ønskelig å skjule objektet som direkte lagrer ressursens tilstand i modellen fra klienttilgang. Ellers, for eksempel ved sletting av en fil, kunne klienten fortsatt holde på objektet som ikke lenger eksisterer i modellen, noe som ville medføre problemer. Eclipse løser dette problemet ved å bruke det såkalte håndtaket til ressursen. Håndtaket fungerer som en nøkkel (den kjenner bare stien til ressursen i arbeidsområdet) og kontrollerer fullstendig tilgangen til det interne objektet i modellen, som direkte lagrer informasjon om ressursens tilstand. Denne designen er en variasjon av mønsteret Håndtak/Kropp.

Figur 2 illustrerer idiomet Handle/Body i forhold til ressursmodellen. Grensesnittet IResource representerer handle for ressursen og fungerer som API, i motsetning til klassen Resource, som implementerer dette grensesnittet, samt klassen ResourceInfo, som representerer body og ikke er et API. Det er viktig å påpeke at handle bare kjenner banen til ressursen i forhold til roten av arbeidsområdet og ikke inneholder en lenke til resource info. Objekter av resource info danner såkalt 'elementtre' (element tree). Denne datastrukturen er helt materialisert i minnet. For å finne en instans av resource info som tilsvarer et bestemt handle, traverseres elementtreet i henhold til banen lagret i dette handle.

Figur 2. IResource og ResourceInfo

Som vi vil se senere, brukes det grunnleggende designet til ressursmodellen (som kan kalles handle-basert) i Eclipse og for andre modeller. La oss nå liste opp noen særegne egenskaper ved dette designet:

• Handle er et verdiobjekt (value object). Verdiobjekter er immutable objekter, hvor likhet ikke er basert på identitet. Slike objekter kan trygt brukes som nøkkel i hasherte containere. Flere instanser av handle kan referere til den samme ressursen. For å sammenligne dem, må metoden equals(Object) brukes.
• Handle definerer oppførselen til ressursen, men inneholder ingen informasjon om ressursens tilstand (de eneste dataene det lagrer er "nøkkelen", banen til ressursen).
• Handle kan referere til en ikke-eksisterende ressurs (enten en ressurs som ennå ikke er opprettet, eller en ressurs som allerede er slettet). Eksistensen av ressursen kan sjekkes ved hjelp av metoden IResource.exists().
• Noen operasjoner kan utelukkende implementeres basert på informasjonen som lagres i selve handle (såkalte handle-only operasjoner). Eksempler på dette er IResource.getParent(), getFullPath() osv. Ressursen trenger ikke nødvendigvis å eksistere for at en slik operasjon skal lykkes. Operasjoner som krever at ressursen eksisterer for å utføres, vil kaste et unntak (CoreException) hvis ressursen ikke eksisterer.

Eclipse tilbyr en effektiv mekanisme for varsling om endringer i workspace-ressurser (se figur 3). Ressurser kan endres både som følge av handlinger utført i Eclipse IDE selv, og som følge av synkronisering med filsystemet. I begge tilfeller får klientene som har meldt seg på varsler, detaljert informasjon om endringer i form av «ressursdelt» (resource delta). Deltat beskriver endringer mellom to tilstander av (under)treet med workspace-ressurser og er selv et tre, der hver node beskriver endringen av en viss ressurs og inneholder en liste over deltaktene på neste nivå, som beskriver endringer i underordnede ressurser.

Figur 3. IResourceChangeEvent og IResourceDelta

Den varslingmekanismen som er basert på ressursdelt, har følgende egenskaper:

• Enkeltendringer og flere endringer beskrives med samme struktur, siden deltaen bygges opp på prinsippet om rekursiv komposisjon. Klienter som abonnerer kan håndtere varsler om endringer i ressurser ved å bruke rekursiv nedstigning gjennom deltatreet.
• Deltaen inneholder fullstendig informasjon om endringen av ressursen, inkludert dens flytting og/eller endringer i tilknyttede «markører» (for eksempel representeres kompilasjonsfeil som markører).
• Siden henvisninger til ressursen gjøres via håndtak, kan deltaen naturlig henvise til en fjern ressurs.

Som vi snart vil se, er de viktigste komponentene i designet av varslingmekanismen for endring av ressursmodellen relevante også for andre håndteringsbaserte modeller.

JDT Core

Modellen for Eclipse workspace-ressurser er en grunnleggende språk-uavhengig modell. JDT Core-komponenten (plugin org.eclipse.jdt.core) tilbyr API for navigering og analyse av strukturen til workspace sett fra Java-perspektiv, den såkalte «Java-modellen» (Java model). Dette API-et er definert i termer av Java-elementer, i motsetning til det underliggende API-et for ressursmodellen, som er definert i termer av mapper og filer. De viktigste grensesnittene i treet av Java-elementer er avbildet i figur 4.

Figur 4. Elementene i Java-modellen

Java-modellen bruker den samme idiomen handle/body som ressursmodellen (figur 5). IJavaElement er håndtaket, mens JavaElementInfo fungerer som kroppen. Grensesnittet IJavaElement definerer et felles protokoll for alle Java-elementer. Noen av metodene er kun håndtak: getElementName(), getParent(), osv. JavaElementInfo-objektet lagrer tilstanden til det tilsvarende elementet: dets struktur og egenskaper.

Figur 5. IJavaElement og JavaElementInfo

Java-modellen har noen avvik i implementeringen av den grunnleggende handle/body-designen sammenlignet med ressursmodellen. Som nevnt tidligere, inneholder ressursmodellens elementtre, hvor nodene er objekter med ressursinformasjon, fullt ut i minnet. Men i Java-modellen kan det være betydelig flere elementer enn i ressurs-treet, ettersom den også representerer den interne strukturen av .java- og .class-filer: typer, felt og metoder.

For å unngå full materialisering av hele elementtreet i minnet, bruker implementeringen av Java-modellen en begrenset LRU-cache for elementinformasjon, der nøkkelen er håndtaket IJavaElement. Elementinformasjonsobjektene opprettes etter behov når navigeringen i elementtreet skjer. De minst brukte elementene blir utvist fra cachen, og minneforbruket for modellen forblir innenfor den fastsatte cache-størrelsen. Dette er enda en fordel med handle-basert design, som fullstendig skjuler slike implementasjonsdetaljer fra klientkoden.

Mekanismen for varsling om endringer av Java-elementer er i store trekk lik den tidligere beskrevne mekanismen for sporing av endringer i ressursarbeidsområde. En klient som ønsker å overvåke endringer i Java-modellen, abonnerer på varsler som presenteres som et ElementChangedEvent-objekt som inneholder IJavaElementDelta (figur 6).

Figur 6. ElementChangedEvent og IJavaElementDelta

Java-modellen inneholder ikke informasjon om kroppene til metodene eller navneløsning, så for en detaljert analyse av kode skrevet i Java, tilbyr JDT Core en ekstra (ikke handle-basert) modell: abstrakt syntaks tre (abstrakt syntaksetre, AST). AST representerer resultatet av syntaktisk analyse av kildeteksten. Nodene i AST tilsvarer elementene i strukturen til den aktuelle modulen (erklæringer, operatorer, uttrykk osv.) og inneholder informasjon om koordinatene til det respektive elementet i kildeteksten, samt (som et alternativ) informasjon om navneoppløsning i form av referanser til det såkalte bindings. Bindings er objekter som representerer navngitte enheter, som typer, metoder, og variabler kjent for kompilatoren. I motsetning til nodene i AST, som danner et tre, støtter bindings kryssreferanser og danner generelt et graf. Den abstrakte klassen ASTNode er en felles baseklasse for alle noder i AST. Underklassene til ASTNode tilsvarer spesifikke syntaktiske konstruksjoner i Java-språket.

Siden syntaktiske trær kan bruke betydelig mengde minne, cacher JDT bare ett AST for den aktive redigereren. I motsetning til Java-modellen betraktes AST generelt som en «intermediær», «midlertidig» modell, der klientene ikke bør opprettholde referanser utenfor konteksten av operasjonen som førte til opprettelsen av AST.

De tre oppførte modellene (Java-modell, AST, bindings) utgjør sammen grunnlaget for utviklingen av «intelligente utviklingsverktøy» i JDT, hvorav et kraftig Java-redigeringsprogram med forskjellige «assistenter», ulike handlinger for behandling av kildekode (blant annet organisering av importliste over navn og formatering i henhold til den angitte stilen), og verktøy for søk og refaktorering. I denne forbindelse spiller Java-modellen en spesiell rolle, ettersom den brukes som grunnlag for visuell presentasjon av strukturen til den utviklede applikasjonen (for eksempel i Package Explorer, Outline, Search, Call Hierarchy, og Type Hierarchy).

Eclipse-komponenter som brukes i 1C:Enterprise Developments Tools

Fig. 7 viser Eclipse-komponentene som danner grunnlaget for den teknologiske plattformen for 1C:Enterprise Development Tools.

Fig. 7. Eclipse som plattform for 1C:Enterprise Development Tools

Eclipse-plattformen tilbyr grunnleggende infrastruktur. Vi har sett på noen aspekter av denne infrastrukturen i forrige avsnitt.

Eclipse Modeling Framework (EMF) gir vanlig verktøy for modellering av strukturerte data. EMF er integrert med Eclipse Platform, men kan også brukes selvstendig i vanlige Java-applikasjoner. Det er ganske vanlig at nybegynnere i Eclipse allerede er godt kjent med EMF, selv om de fortsatt ikke helt forstår nyansene i Eclipse Platform. En grunn til den velfortjente populariteten er det universelle designet, som blant annet inkluderer et forent API på meta-nivå som gjør det mulig å jobbe generelt med enhver EMF-modell. De grunnleggende implementeringene av EMF for modellobjekter og modellenes kodegenereringsundersystem basert på meta-modellen øker utviklingshastigheten betydelig og reduserer feil. EMF inneholder også mekanismer for serialisering av modeller, sporing av endringer i modellen, og mye mer.

Som ethvert virkelig universelt verktøy, er EMF egnet for en rekke oppgaver knyttet til modellering, men noen klasser av modeller (for eksempel de håndterte modellene nevnt tidligere) kan trenge mer spesialiserte verktøy for modellering. Å forklare EMF er en utakknemlig oppgave, særlig innen rammen av en enkelt artikkel, siden det er et emne for en egen bok, og en ganske tykk en. La oss bare merke oss at den kvalitetsmessige generaliseringssystemet som ligger til grunn for EMF har gjort det mulig å utvikle et helt spekter av prosjekter dedikert til modellering, som inngår i toppnivåprosjektet. Eclipse Modellering sammen med selve EMF. Et slikt prosjekt er Eclipse Xtext.

Eclipse Xtext gir infrastrukturen for 'tekstmodellering'. Xtext bruker ANTLR for syntactic analysis of the source text and EMF for representing the resulting ASG (abstract semantic graph, which is essentially a combination of AST and bindings), also known as the "semantic model." The grammar of the modeled language using Xtext is described in its own Xtext language. This allows not only generating a grammar description for ANTLR but also obtaining an AST serialization mechanism (i.e., Xtext provides both a parser and an unparser), context-aware suggestions, and a variety of other language components. On the other hand, the grammar description language used in Xtext is less flexible compared to, say, the grammar description language in ANTLR. Therefore, sometimes it is necessary to "bend" the implemented language to Xtext, which is usually not an issue if we are dealing with a newly developed language but may be unacceptable for languages with an established syntax. Nevertheless, Xtext is currently the most mature, functionally complete, and versatile tool in Eclipse for creating programming languages and development tools for them. It is particularly ideal for rapid prototyping. domain-specific languages (domain-specific language, DSL). In addition to the aforementioned “language core” based on ANTLR and EMF, Xtext offers a multitude of useful higher-level components, including indexing mechanisms, incremental building, a “smart editor,” and much, much more, but it leaves aside language handle-based models. Like EMF, Xtext is a subject worthy of a separate book, and we will hardly be able to even briefly touch on all its capabilities now.

1C:Enterprise Development Tools actively utilizes both EMF itself and a number of other Eclipse Modeling projects. In particular, Xtext is one of the foundations for development tools for such 1C:Enterprise languages as the embedded programming language and query language. Another foundation of these development tools is the Eclipse Handly project, which we will discuss in more detail (of the listed Eclipse components, it is currently the least known).

Eclipse Handly, prosjektet av toppnivået Eclipse Technology, oppstod som et resultat av den initiale bidraget av kode til Eclipse Foundation, utført av firmaet 1C i 2014. Siden den gang har firmaet 1C fortsatt å støtte utviklingen av prosjektet: committere Handly er ansatte i selskapet. Prosjektet er lite, men fyller en unik nisje i Eclipse: hovedmålet er å støtte utviklingen av handle-baserte modeller.

De grunnleggende arkitekturprinsippene for handle-baserte modeller, som idiomet handle/body, ble tidligere diskutert med eksempler fra ressursmodellen og Java-modellen. Det ble også bemerket at både ressursmodellen og Java-modellen er viktige fundamenter for Eclipse Java Development Tools (JDT). Siden nesten alle *DT-prosjekter i Eclipse har en arkitektur som ligner på JDT, er det ikke en overdrivelse å si at handle-baserte modeller ligger til grunn for mange, om ikke alle IDE-er bygget på Eclipse-plattformen. For eksempel har Eclipse C/C++ Development Tooling (CDT) en handle-basert modell for C/C++, som spiller samme rolle i CDT-arkitekturen som Java-modellen i JDT.

Før Handly ble introdusert, tilbød ikke Eclipse spesialiserte biblioteker for oppbygging av språklige handle-baserte modeller. De eksisterende modellene ble først og fremst laget ved direkte tilpasning av Java-modellen (a.k.a. copy/paste), i tilfeller der det er tillatt Eclipse Public License (EPL). (Det er klart at, for eksempel, for prosjekter i Eclipse selv, er dette vanligvis ikke et juridisk problem, noe som ikke kan sies om produkter med lukket kildekode.) I tillegg til det karakteristiske kaoset denne metoden fører med seg, medfører den velkjente problemer: duplisering av kode, feil som oppstår under tilpasning, osv. Hva som er verre, de resulterende modellene forblir 'ting i seg selv' og utnytter ikke det tilgjengelige potensialet for enhetlighet. Å utdra felles konsept og protokoller for språklige handle-baserte modeller kunne ha ført til opprettelsen av gjenbrukbare komponenter for arbeidet med dem, på samme måte som tilfelle med EMF.

Det kan ikke sies at Eclipse ikke forsto disse problemene. Allerede i 2005 Martin Aeschlimann, oppsummerte erfaringene fra utviklingen av prototypen til CDT, argumenterte behovet for å skape en felles infrastruktur for språklige modeller, inkludert handle-baserte modeller. Men, som det ofte skjer, ble det ikke tatt tak i disse ideene på grunn av mer prioriterte oppgaver. I mellomtiden forblir faktoriseringen av koden for DT-prosjekter et av de fortsatt utilstrekkelig utrettede temaene i Eclipse.

I en viss forstand er prosjektet Handly ment å løse omtrent de samme oppgavene som EMF, men for handle-baserte modeller, og først og fremst språklige (dvs. representerende elementene i strukturen til et programmeringsspråk). Nedenfor listes de viktigste målene som ble satt under utformingen av Handly:

• Identifisere de viktigste abstraksjonene innen emneområdet.
• Redusere innsats og forbedre kvaliteten på implementeringen av språklige handle-baserte modeller gjennom gjenbruk av kode.
• Tilby et enhetlig API på meta-nivå til de resulterende modellene, som gjør det mulig å lage generiske IDE-komponenter som arbeider med språklige handle-baserte modeller.
• Fleksibilitet og skalerbarhet.
• Integrasjon med Xtext (i et eget lag).

For å identifisere felles konsepter og protokoller ble eksisterende implementeringer av språklige handle-baserte modeller analysert. Hovedgrensesnittene og de grunnleggende implementeringene som tilbys av Handly, er vist i figur 8.

Figur 8. Felles grensesnitt og grunnleggende implementeringer av Handly-elementer

IElement-grensesnittet representerer handle-elementet og er felles for elementene i alle modeller basert på Handly. Den abstrakte klassen Element implementerer en generisk mekanisme for handle/body (figur 9).

Figur 9. IElement og den generiske implementeringen av handle/body

I tillegg tilbyr Handly en generisk mekanisme for varsling om endringer i modelelementer (figur 10). Som det kan sees, er det i grove trekk lik mekanismene for varsling som er implementert i ressursmodellen og Java-modellen, og bruker IElementDelta for enhetlig fremstilling av informasjon om endringen av elementet.

Figur 10. Felles grensesnitt og grunnleggende implementeringer av Handly-varsling

Den delen av Handly som er omtalt ovenfor (figur 9 og 10) kan brukes til å representere nesten alle handle-baserte modeller. For å lage språklige modeller tilbyr prosjektet ekstra funksjonalitet – spesielt felles grensesnitt og grunnleggende implementeringer for elementene i strukturen av kildekoden, såkalt source elements (figur 8). Grensesnittet ISourceFile representerer kildefilen, mens ISourceConstruct er et element innenfor kildefilen. De abstrakte klassene SourceFile og SourceConstruct implementerer generiske mekanismer for å støtte arbeidet med kildefiler og deres elementer, for eksempel arbeid med tekstbuffere, binding til koordinater for elementet i den opprinnelige teksten, samt sammenstilling av modellen med det nåværende innholdet i bufferets arbeidskopi, osv. Implementeringen av disse mekanismene er vanligvis en ganske kompleks oppgave, og Handly kan betydelig redusere utviklingsinnsatsen for språkmodeller basert på håndtak ved å tilby kvalitetsmessige grunnimplementeringer.

I tillegg til de nevnte grunnmekanismene tilbyr Handly infrastruktur for tekstbuffere og «snapshot»-funksjonalitet, støtte for integrasjon med kildekode-redaktører (inkludert en «out-of-the-box» integrasjon med Xtext-redaktøren), samt noen vanlige UI-komponenter som fungerer med modeller basert på Handly, slik som outline framework. For å illustrere sine muligheter tilbyr prosjektet flere eksempler, inkludert implementeringen av en Java-modell på Handly. (Sammenlignet med den fullstendige implementeringen av Java-modellen i JDT, er denne modellen bevisst noe forenklet for bedre oversiktlighet.)

Som nevnt tidligere, har betydelig oppmerksomhet blitt viet til både den innledende designen av Handly og dens videre utvikling, spesielt med hensyn til skalerbarhet og fleksibilitet.

I prinsippet skalerer modeller basert på håndtak ganske godt “by design”. For eksempel lar idiomen handle/body begrense mengden hukommelse modellen bruker. Men det er også nyanser. Under testing av Handly for skalerbarhet ble det oppdaget et problem med implementeringen av notifikasjonsmekanismen – når et stort antall elementer ble endret, tok det for lang tid å bygge deltas. Det viste seg at det samme problemet også var til stede i Java-modellen til JDT, fra hvilken den aktuelle koden en gang ble tilpasset. Vi rettet feilen i Handly og utarbeidet en lignende patch for JDT, som ble mottatt med takknemlighet. Dette er bare ett eksempel på hvordan implementeringen av Handly i eksisterende modellimplementeringer kunne vært potensielt nyttig, da en slik feil kunne blitt løst ett sted.

For the integration of Handly into existing model implementations to be technically feasible, the library must possess significant flexibility. The main challenge is to maintain API backward compatibility with the model. This task was solved by Handly 0.5 clear separation of model-specific API, defined and fully controlled by the developer, from the unified meta-level API provided by the library. This not only makes the integration of Handly into existing implementations technically feasible, but also grants the developer of the new model significant freedom in designing the API.

Flexibility has other aspects as well. For example, Handly imposes almost no restrictions on the model structure and can be used for both general-purpose language modeling and domain-specific languages. When building the source file structure, Handly does not prescribe any specific form of AST representation and does not require the presence of an AST, thereby ensuring compatibility with virtually any parsing mechanism. Finally, Handly supports full integration with the Eclipse workspace but can also work directly with file systems, thanks to integration with Eclipse File System (EFS).

The current version Handly 0.6 was released in December 2016. Although the project is currently in incubation and the API is not yet finalized, Handly is already used in two major commercial products that dared to act as 'early adopters', and so far, they do not regret it.

As mentioned above, one of these products is 1C:Enterprise Development Tools, where Handly has been used from the outset to model elements of the high-level structure of languages like 1C:Enterprise, such as the embedded programming language and query language. The other product is less known to the general public. It is Codasip Studio, an integrated environment for designing application-specific instruction-set processors (ASIPs), used both within the Czech company Codasip and by its clients, among whom are AMD, STDDEV, Mobileye, Sigma Designs. Codasip har brukt Handly i produksjon siden 2015, begynnende med versjon Handly 0.2. Den siste utgivelsen av Codasip Studio bruker versjon 0.5, som ble utgitt i juni 2016. Ondřej Ilčík, som leder utviklingen av IDE i Codasip, er i kontakt med prosjektet og gir viktig tilbakemelding fra «eksterne adopsjonsbrukere». Han har til og med klart å finne litt tid til å bidra direkte til prosjektutviklingen ved å implementere UI-laget (~ 4000 linjer med kode) for et av Handly-eksemplene, en Java-modell. Mer informasjon «fra førstehånd» om bruk av Handly av adopsjonsbrukere kan fås på siden Suksesshistorier project.

Vi håper at etter utgivelsen av versjon 1.0 med API-stabilitetsgaranti, og prosjektets utgang fra inkubasjonsstatus, vil Handly få flere adopsjonsbrukere. I mellomtiden fortsetter prosjektet med testing og videre forbedring av API-et, og utgir to «store» oppdateringer i året – i juni (samme dato som den samtidige utgivelsen av Eclipse) og desember, og sikrer en forutsigbar tidsplan som adopsjonsbrukere kan stole på. Det er også verdt å nevne at «bug rate»-indikatoren for prosjektet har forblitt på et stabilt lavt nivå, og Handly har pålitelig blitt brukt i produktene til tidlige adoptere siden de første versjonene. For mer informasjon om Eclipse Handly kan du bruke Kom i gang med opplæringsprogrammet og Arkitektonisk oversikt.

Kilde: habr.com