Sandsynligvis, behøver allerede ikke nogen særlig præsentation. Mange er bekendt med Eclipse takket være Eclipse Java development tools (). Det er netop denne populære open-source Java IDE, der forbindes af de fleste udviklere med ordet “Eclipse”. Men Eclipse er også en udvidelig platform til integration af udviklingsværktøjer (Eclipse Platform) og en række IDE'er, der er bygget på dens basis, herunder JDT. Eclipse er både Eclipse Project, et højt niveau projekt, der koordinerer udviklingen af Eclipse Platform og JDT, samt Eclipse SDK – resultatet af denne udvikling. Endelig er Eclipse en open-source Foundation med et stort samfund af projekter, som langt fra alle er skrevet i Java eller har noget at gøre med udviklingsværktøjer (for eksempel projekter og ). Verden af Eclipse er meget mangfoldig.
I denne artikel, der er overordnet af sin natur, vil vi forsøge at se på nogle grundlæggende aspekter af Eclipse's arkitektur som platform for at bygge integrerede udviklingsværktøjer og give en indledende præsentation af de komponenter, der udgør fundamentet for den teknologiske platform for ‘den nye Konfigurator’ 1C: Enterprise, . Selvfølgelig vil en sådan undersøgelse uundgåeligt være overfladisk og ret begrænset, blandt andet fordi vi sigter mod ikke kun Eclipse-udviklere som målgruppe. Vi håber dog, at selv erfarne Eclipse-udviklere vil finde interessant information i artiklen. For eksempel vil vi tale om en af ‘Eclipse's hemmeligheder’, et relativt nyt og endnu lidt kendt projekt, , som blev grundlagt og understøttet af firmaet 1C.
Introduktion til Eclipse-arkitektur
Lad os først se på nogle generelle aspekter af Eclipse's arkitektur med eksemplet (JDT). Valget af netop JDT som eksempel er ikke tilfældigt. Det er den første integrerede udviklingsmiljø, der kom til i Eclipse. De øvrige *DT projekter i Eclipse, såsom Eclipse C/C++ Development Tooling (CDT), blev skabt senere og lånte både grundlæggende arkitekturprincipper og enkelte fragmenter af kildekode fra JDT. De arkitektoniske grundlag, der er lagt i JDT, er stadig relevante i dag for næsten enhver IDE bygget oven på Eclipse Platform, herunder 1C:Enterprise Development Tools.
For Eclipse, it is important to note that there is a clear architectural layering, separating language-independent functionality from functionality meant to support specific programming languages, as well as separating UI-independent core components from components related to user interface support.
The Eclipse Platform defines a common, language-independent infrastructure, while Java development tools add a fully functional Java IDE to Eclipse. Both the Eclipse Platform and JDT consist of several components, each of which belongs either to the UI-independent core or to the UI layer (see Fig. 1).
Fig. 1. Eclipse Platform and JDT
Let’s list the main components of the Eclipse Platform:
- Runtime — Defines the plugin infrastructure. Eclipse features a modular architecture. Essentially, Eclipse is a collection of 'extension points' and 'extensions'.
- Workspace — Manages one or more projects. A project consists of folders and files that are directly reflected in the file system.
- Standard Widget Toolkit (SWT) — Provides basic user interface elements integrated with the operating system.
- JFace — Provides a range of UI frameworks built on top of SWT.
- Workbench — Defines the UI paradigm of Eclipse: editors, views, perspectives.
It should be noted that the Eclipse Platform also provides many other useful components for building integrated development tools, including Debug, Compare, Search, and Team. Additionally, JFace Text should be mentioned as the foundation for creating 'smart editors' for source code. Unfortunately, even a brief overview of these components, as well as of the UI layer components, is not feasible within this article, so in the remaining part of this section, we will limit ourselves to an overview of the main core components of the Eclipse Platform and JDT.
Core Runtime
The Eclipse plugin infrastructure is based on and is provided by the project . Each Eclipse plugin is an OSGi bundle. The OSGi specification defines, among other things, versioning and dependency resolution mechanisms. In addition to these standard mechanisms, Equinox introduces the concept of extension points. Hvert plugin kan definere sine egne udvidelsespunkter og tilføje yderligere funktionalitet til systemet ("udvidelser") ved hjælp af udvidelsespunkter, der er defineret af dette eller andre plugins. En detaljeret beskrivelse af OSGi- og Equinox-mekanismerne ligger uden for rammerne af denne artikel. Det er værd at bemærke, at modulariseringen i Eclipse er total (enhver delsystem, inklusive Runtime, består af et eller flere plugins), og praktisk talt alt i Eclipse er en udvidelse. Disse principper blev lagt ind i Eclipse-arkitekturen længe før OSGi blev implementeret (på det tidspunkt blev der anvendt en proprietær teknologi, der i mange henseender minder om OSGi).
Kernearbejdsområde
Næsten enhver integreret udviklingsmiljø, der er bygget på Eclipse Platform, arbejder med Eclipse arbejdsområde. Det er typisk arbejdsområdet, der indeholder kildekoden til den applikation, der udvikles i IDE. Arbejdsområdet afspejles direkte på filsystemet og består af projekter, som indeholder mapper og filer. Disse projekter, mapper og filer kaldes ressourcer arbejdsområde. Implementeringen af arbejdsområdet i Eclipse fungerer som en form for cache i forhold til filsystemet, hvilket markant kan fremskynde traversal af ressourcetræet. Derudover tilbyder arbejdsområdet en række yderligere tjenester, herunder og .
Core Resources-komponenten (plugin org.eclipse.core.resources) er ansvarlig for at understøtte arbejdsområdet og dets ressourcer. Denne komponent giver programmatisk adgang til arbejdsområdet i form af ressourcemodel. For effektivt at arbejde med denne model har klienter brug for en enkel måde at repræsentere linket til ressourcen. Det ville være ønskeligt at skjule objektet, der direkte gemmer ressourcens tilstand i modellen, for klientadgang. Ellers, i tilfælde af f.eks. sletning af en fil, kunne klienten fortsætte med at holde på et objekt, der ikke længere findes i modellen, hvilket ville skabe problemer. Eclipse løser denne opgave ved at bruge det såkaldte handle af ressourcen. Handle fungerer som en nøgle (den kender kun stien til ressourcen i arbejdsområdet) og kontrollerer fuldstændigt adgangen til det interne modelobjekt, der direkte gemmer oplysninger om ressourcens tilstand. Dette design er en variation af mønsteret .
Figur 2 illustrerer idiomet Handle/Body i relation til ressourcesmodellen. Interface IResource repræsenterer handle til ressourcen og fungerer som API, i modsætning til klassen Resource, der implementerer dette interface, samt klassen ResourceInfo, der repræsenterer body, som ikke er et API. Det er vigtigt at understrege, at handle kun kender stien til ressourcen i forhold til roden af arbejdsområdet og ikke indeholder et link til resource info. Objekterne for resource info danner det såkaldte 'elementtræ'. Denne datastruktur er fuldt materialiseret i hukommelsen. For at finde et instans af resource info, der svarer til et givent handle, traverseres elementtræet i henhold til stien, der er gemt i dette handle.
Figur 2. IResource og ResourceInfo
Som vi senere vil se, anvendes den grundlæggende design af ressourcesmodellen (vi kan kalde den handle-baseret) i Eclipse og for andre modeller. Men lad os først nævne nogle karakteristiske egenskaber ved dette design:
- Handle er et værdiobjekt (value object). Værdiobjekter er immutable objekter, hvis lighed ikke er baseret på identitet. Sådanne objekter kan sikkert anvendes som nøgler i hash-kontainere. Flere instanser af handle kan referere til den samme ressource. For at sammenligne dem skal metoden equals(Object) anvendes.
- Handle definerer ressourcens adfærd, men indeholder ikke information om ressourcens tilstand (de eneste data, den gemmer, er 'nøglen', stien til ressourcen).
- Handle kan referere til en ikke-eksisterende ressource (enten en ressource, der endnu ikke er oprettet, eller en ressource, der allerede er slettet). Eksistensen af ressourcen kan verificeres med metoden IResource.exists().
- Nogle operationer kan kun udføres ud fra informationen, der er gemt i selve handle (de såkaldte handle-only operationer). Eksempler inkluderer IResource.getParent(), getFullPath(), osv. Det er ikke nødvendigt, at ressourcen eksisterer for at en sådan operation kan udføres succesfuldt. Operationer, der kræver, at ressourcen eksisterer for at kunne fuldføres, kaster en undtagelse (CoreException), hvis ressourcen ikke eksisterer.
Eclipse tilbyder en effektiv mekanisme til notifikation om ændringer i workspace-ressourcer (se fig. 3). Ressourcer kan ændres som et resultat af handlinger udført i selve Eclipse IDE eller i forbindelse med synkronisering med filsystemet. I begge tilfælde gives der detaljeoplysninger om ændringerne til de kunder, der er tilmeldt notifikationerne, i form af "ressource-deltaer" (resource delta). Deltaet beskriver ændringerne mellem to tilstande (sub-)træet af workspace-ressourcer og er i sig selv et træ, hvor hver node beskriver ændringen af en given ressource og indeholder en liste over deltaer på næste niveau, der beskriver ændringer i de underordnede ressourcer.
Fig. 3. IResourceChangeEvent og IResourceDelta
Den notifikationsmekanisme, der er baseret på ressource-deltaer, har følgende karakteristika:
- En enkelt ændring og flere ændringer beskrives ved hjælp af den samme struktur, da deltaet bygges efter princippet om rekursiv sammensætning. Abonnenter kan håndtere notifikationer om ressourceændringer ved rekursivt at navigere i delta-træet.
- Deltaet indeholder fuld information om ændringen af ressourcen, herunder dens flytning og/eller ændringer af de tilknyttede "markører" (f.eks. præsenteres kompilationsfejl som markører).
- Da referencer til ressourcen laves gennem håndtag, kan deltaet naturligt referere til en fjernet ressource.
Som vi snart vil se, er de grundlæggende elementer i designet af notifikationsmekanismen for ændringer i ressourcemodellen relevante for andre håndtag-baserede modeller.
JDT Core
Eclipse workspace-ressourcemodellen er en grundlæggende sprog-uafhængig model. JDT Core-komponenten (plugin org.eclipse.jdt.core) leverer et API til navigation og analyse af strukturen i workspace fra et Java-perspektiv, som kaldes "Java-modellen" (Java model). Dette API er defineret i termer af Java-elementer, i modsætning til det underlæggende API for ressource-modellen, der er defineret i termer af mapper og filer. De vigtigste grænseflader i Java-elementtræet er vist i fig. 4.
Fig. 4. Elementer i Java-modellen
Java-modellen bruger den samme idiom handle/body som ressource-modellen (figur 5). IJavaElement er handle, mens JavaElementInfo fungerer som body. IJavaElement-interface definerer en protokol, der er fælles for alle Java-elementer. Nogle af dens metoder er kun handle: getElementName(), getParent() osv. JavaElementInfo-objektet gemmer tilstanden for det tilsvarende element: dets struktur og attributter.
Figur 5. IJavaElement og JavaElementInfo
Java-modellen har nogle forskelle i implementeringen af den grundlæggende handle/body-design sammenlignet med ressource-modellen. Som nævnt tidligere er elementtræet i ressource-modellen, hvis noder er resource info-objekter, fuldt indeholdt i hukommelsen. Men i Java-modellen kan der være betydeligt flere elementer end i ressource-træet, da den også repræsenterer den interne struktur af .java og .class filer: typer, felter og metoder.
For at undgå fuld materialisering af hele elementtræet i hukommelsen bruger implementeringen af Java-modellen en begrænset størrelse LRU-cache til elementinfo, hvor nøglen er handle IJavaElement. Elementinfo-objekter oprettes efter anmodning, mens navigationen gennem elementtræet finde sted. De sjældent brugte elementer udskiftes fra cachen, og hukommelsesforbruget for modellen forbliver begrænset til den angivne størrelsescache. Dette er endnu en fordel ved handle-baseret design, som fuldstændig skjuler sådanne implementeringsdetaljer fra klientkoden.
Mekanismen til notifikation om ændringer i Java-elementer ligner generelt den tidligere beskrevne mekanisme for at overvåge ændringer i arbejdsområdets ressourcer. En klient, der ønsker at overvåge ændringer i Java-modellen, abonnerer på notifikationer, der præsenteres som et ElementChangedEvent-objekt, som indeholder IJavaElementDelta (figur 6).
Figur 6. ElementChangedEvent og IJavaElementDelta
Java-modellen indeholder ikke information om metodekroppen eller navneopløsning, så for en detaljeret analyse af Java-kode tilbyder JDT Core en ekstra (ikke-handle-baseret) model: (abstrakt syntaks træ, AST). AST repræsenterer resultatet af syntaktisk analyse af den oprindelige tekst. Noderne i AST svarer til elementerne i strukturen af den oprindelige modul (erklæringer, operationer, udtryk osv.) og indeholder information om koordinaterne for det tilsvarende element i den oprindelige tekst, samt (valgfrit) information om navneopløsning i form af henvisninger til de såkaldte bindings. Bindings er objekter, der repræsenterer navngivne enheder som typer, metoder og variabler, der er kendt af compileren. I modsætning til noderne i AST, der danner et træ, understøtter bindings krydshenvisninger og danner generelt et graf. Abstrakt klasse ASTNode er den fælles basis klasse for alle noder i AST. Underklasser af ASTNode svarer til bestemte syntaktiske konstruktioner i Java-sproget.
Da syntaks træer kan forbruge betydelig hukommelse, cachen JDT kun et enkelt AST for den aktive editor. I modsætning til Java-modellen betragtes AST normalt som en "intermediær", "midlertidig" model, hvor klienter ikke bør holde henvisninger uden for konteksten af den operation, der førte til oprettelsen af AST.
De nævnte tre modeller (Java modellen, AST, bindings) er sammen grundlaget for opbygningen af "intelligente udviklingsværktøjer" i JDT, herunder en kraftfuld Java-editor med forskellige "assistenter", diverse handlinger til behandling af kildekode (herunder organisering af importlisten og formatering i overensstemmelse med den tilpassede stil), søge- og refaktoreringsværktøjer. Java-modellen spiller en særlig rolle, da den anvendes som grundlag for den visuelle repræsentation af strukturen af den udviklede applikation (for eksempel i Package Explorer, Outline, Search, Call Hierarchy og Type Hierarchy).
Eclipse-komponenter, der anvendes i 1C:Enterprise Developments Tools
Fig. 7 viser de Eclipse-komponenter, der danner grundlaget for den teknologiske platform for 1C:Enterprise Development Tools.
Fig. 7. Eclipse som platform for 1C:Enterprise Development Tools
Eclipse Platform giver den grundlæggende infrastruktur. Vi har gennemgået nogle aspekter af denne infrastruktur i den foregående sektion.
(EMF) leverer generelle værktøjer til modellering af strukturerede data. EMF er integreret med Eclipse Platform, men kan også bruges separat i almindelige Java-applikationer. Det er ret ofte, at nye Eclipse-udviklere allerede er godt bekendt med EMF, selvom de ikke helt har styr på nuancerne i Eclipse Platform. En af årsagerne til denne velfortjente popularitet er det universelle design, der inkluderer en ensartet API på meta-niveau, som muliggør generel interaktion med enhver EMF-model. De grundlæggende implementeringer, som EMF leverer til modelobjekter samt subsystemet til kodegenerering fra meta-modellen, øger væsentligt udviklingshastigheden og mindsker antallet af fejl. Desuden indeholder EMF mekanismer til serialisering af modeller, overvågning af ændringer i modellen og meget mere.
Som enhver virkelig alsidig værktøj passer EMF til et bredt spektrum af opgaver relateret til modellering, men nogle klasser af modeller (for eksempel de nævnte handle-baserede modeller) kan have brug for mere specialiserede modelleringsværktøjer. At tale om EMF er en utaknemlig opgave, især inden for rammerne af en enkelt artikel, da det er emnet for en separat bog, og en ret tyk en af slagsen. Lad os kun bemærke, at det kvalitetsbaserede system for generaliseringer, der ligger til grund for EMF, har gjort det muligt at skabe en række projekter dedikeret til modellering, som indgår i et overordnet projekt. sammen med selve EMF. Et af disse projekter er Eclipse Xtext.
leverer infrastrukturer til "tekstuel modellering". Xtext benytter til syntaktisk analyse af kildekoden og EMF til repræsentation af den resulterende ASG (abstract semantic graph, som grundlæggende er en kombination af AST og bindings), også kaldet «semantisk model». Grammatikken for det sprog, der modelleres med Xtext, beskrives på dets eget Xtext-sprog. Dette muliggør ikke kun genereringen af en grammatikbeskrivelse til ANTLR, men også en mekanisme til serialisering af AST (dvs. Xtext leverer både parser og unparser), kontekstuel hjælp og en række andre sprogkomponenter. På den anden side er det grammatikbeskrivende sprog, der anvendes i Xtext, mindre fleksibelt sammenlignet med f.eks. grammatikbeskrivelsessproget i ANTLR. Derfor må man nogle gange «tilpasse» det implementerede sprog til Xtext, hvilket normalt ikke er et problem, når det drejer sig om et nyudviklet sprog, men kan være uacceptabelt for sprog med allerede etableret syntaks. Ikke desto mindre er Xtext i øjeblikket det mest modne, funktionsrige og alsidige værktøj i Eclipse til opbygning af programmeringssprog og udviklingsværktøjer til dem. Især er det et ideelt værktøj til hurtig prototyping. (domain-specific language, DSL). Udover det ovennævnte «sprogkernen» baseret på ANTLR og EMF, tilbyder Xtext mange nyttige komponenter på højere niveau, herunder indekseringsmekanismer, inkrementel bygning, «smart editor» og meget, meget mere, men udelader sproghandlebaserede modeller. Ligesom EMF er Xtext et emne, der fortjener en særskilt bog, og vi vil næppe kunne nævne alle dets muligheder nu.
1C:Enterprise Development Tools benytter både EMF som sådan og en række andre Eclipse Modeling projekter. Især er Xtext en af grundstenene i udviklingsværktøjer til sprog som 1C:Enterprise, såsom det indbyggede programmeringssprog og forespørgselssproget. En anden grundpille i disse udviklingsværktøjer er projektet Eclipse Handly, som vi vil gå mere i dybden med (blandt de nævnte Eclipse-komponenter er det stadig det mindst kendte).
, underprojektet til det overordnede Eclipse Technology, blev til som følge af den indledende kodebidrag til Eclipse Foundation, udført af firmaet 1C i 2014. Siden da har firmaet 1C fortsat med at støtte udviklingen af projektet: committere Handly er medarbejdere i firmaet. Projektet er lille, men optager en tilstrækkelig unik niche i Eclipse: dens hovedmål er at støtte udviklingen af handle-baserede modeller.
De grundlæggende arkitektoniske principper for handle-baserede modeller, såsom handle/body idiomet, blev tidligere diskuteret ved eksemplet med ressource-modellen og Java-modellen. Det blev også bemærket, at både ressource-modellen og Java-modellen er vigtige fundamenter for Eclipse Java development tools (JDT). Og da næsten alle *DT Eclipse projekter har en arkitektur, der ligner JDT, ville det ikke være en overdrivelse at sige, at handle-baserede modeller ligger til grund for mange, hvis ikke alle IDE'er, bygget på Eclipse Platform. For eksempel indeholder Eclipse C/C++ Development Tooling (CDT) en handle-baseret model for C/C++, som i CDT's arkitektur spiller samme rolle som Java-modellen i JDT.
Før Handly blev lanceret, tilbød Eclipse ikke specialiserede biblioteker til opbygning af sprog-handle-baserede modeller. De nuværende modeller blev hovedsageligt skabt ved direkte tilpasning af Java-modellen (aka copy/paste), i de tilfælde, hvor det er tilladt Eclipse Public License (EPL). (Det er klart, at for eksempel projekter på selve Eclipse typisk ikke har juridiske problemer i den forbindelse, hvilket ikke gælder for produkter med lukket kildekode.) Ud over dens karakteristiske tilfældighed fører denne metode til velkendte problemer: kode-dublering, fejl indført ved tilpasning, osv. Hvad der er værre, de resulterende modeller forbliver 'en ting i sig selv' og udnytter ikke det eksisterende potentiale for ensretning. At identificere fælles begreber og protokoller for sprog-handle-baserede modeller kunne have ført til skabelsen af genanvendelige komponenter til at arbejde med dem, ligesom det skete i EMF.
Man kan ikke sige, at der ikke var en forståelse for disse problemer i Eclipse. Allerede i 2005 , generaliserende erfaringerne fra udviklingen af prototypen CDT, Nødvendigheden af at skabe en fælles infrastruktur for sprogmodeller, herunder handle-baserede modeller. Men som det ofte er tilfældet, blev der ikke tid til at realisere disse idéer på grund af mere prioriterede opgaver. I mellemtiden forbliver faktoriseringen af koden *DT-projekter en af de emner, der ikke er tilstrækkeligt bearbejdet i Eclipse.
På en vis måde er Handly-projektet designet til at tackle de samme opgaver som EMF, men for handle-baserede modeller, primært sprogmodeller (dvs. der repræsenterer elementer i strukturen af et programmeringssprog). Nedenfor er de vigtigste mål, der blev fastsat under designet af Handly:
- Identifikation af de centrale abstraktioner inden for domænet.
- Reduceret indsats og forbedret kvalitet af implementeringen af handle-baserede sprogmodeller gennem genbrug af kode.
- Tilvejebringelse af et standardiseret API til metaniveauet for de resulterende modeller, hvilket gør det muligt at skabe fælles IDE-komponenter, der arbejder med handle-baserede sprogmodeller.
- Fleksibilitet og skalerbarhed.
- Integration med Xtext (i et separat lag).
For at identificere fælles begreber og protokoller blev eksisterende implementeringer af handle-baserede sprogmodeller analyseret. De vigtigste interfaces og grundlæggende implementeringer, der tilbydes af Handly, vises på fig. 8.
Fig. 8. Fælles interfaces og grundlæggende implementeringer af Handly-elementer
IElement-interface repræsenterer et handle-element og er fælles for elementerne i alle modeller baseret på Handly. Den abstrakte klasse Element implementerer en generisk mekanisme for handle/body (fig. 9).
Fig. 9. IElement og generisk implementering af handle/body
Derudover tilbyder Handly en generisk mekanisme til notifikation om ændringer af model-elementer (fig. 10). Som man kan se, er det overordnet set analogt med de notifikationsmekanismer, der er implementeret i ressource-modellen og Java-modellen, og det bruger IElementDelta til en standardiseret repræsentation af oplysninger om ændringer i elementer.
Fig. 10. Fælles interfaces og grundlæggende implementeringer af Handly-notifikationsmekanismen
Den førnævnte del af Handly (fig. 9 og 10) kan anvendes til at repræsentere stort set alle handle-baserede modeller. For at skabe sprogmodeller tilbyder projektet yderligere funktionalitet - især fælles interfaces og grundlæggende implementeringer for elementer i strukturen af den originale tekst, de såkaldte source elements (fig. 8). Interface ISourceFile represents the source file, while ISourceConstruct represents an element within the source file. The abstract classes SourceFile and SourceConstruct implement generalized mechanisms to support working with source files and their elements, such as managing text buffers, binding to element coordinates in the original text, reconciling the model with the current content of the working copy buffer, and so on. Implementing these mechanisms is usually quite a complex task, and Handly can significantly reduce the development effort for language handle-based models by providing high-quality base implementations.
In addition to the key mechanisms mentioned above, Handly provides infrastructure for text buffers and snapshots, support for integration with source code editors (including out-of-the-box integration with the Xtext editor), as well as some common UI components that work with Handly-based models, such as the outline framework. To illustrate its capabilities, the project provides several examples, including a Java model implemented in Handly. (Compared to the complete implementation of the Java model in JDT, this model is intentionally simplified for clarity.)
As mentioned earlier, significant attention was paid during the initial design of Handly and its subsequent development to scalability and flexibility.
In principle, handle-based models are quite scalable by design. For instance, the handle/body idiom allows limiting the amount of memory consumed by the model. However, there are nuances. For example, during scalability tests of Handly, a problem was discovered in the notification mechanism implementation — when a large number of elements were changed, constructing deltas took too much time. It turned out that the same issue was present in the Java model JDT, from which the corresponding code was adapted. We fixed the bug in Handly and prepared a similar patch for JDT, which was gratefully accepted. This is just one example of how the implementation of Handly in existing model implementations could potentially be useful, as it would allow fixing such a bug in just one place.
For the integration of Handly into existing implementations to be technically feasible, the library must possess significant flexibility. The primary challenge is to maintain API backward compatibility for the model. This problem has been resolved in by clearly separating the 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 technical integration of Handly into existing implementations possible but also gives the developer of the new model considerable freedom in designing the API.
Flexibility has other aspects as well. For example, Handly imposes almost no restrictions on the structure of the model and can be used for both general-purpose language modeling and domain-specific languages. When constructing the source file structure, Handly does not prescribe any specific form of AST representation and does not even 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 the integration with (EFS).
The current version 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 be 'early adopters', and it must be said, they do not regret it so far.
As noted earlier, 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 such languages as 1C:Enterprise, including the built-in programming language and query language. The other product is less known to the general public. It is , an integrated design environment for application-specific instruction-set processors (ASIP), used both within the Czech company Codasip itself and by its clients, including , , , . Codasip har anvendt Handly i produktion siden 2015, startende med version Handly 0.2. Den seneste version af Codasip Studio bruger version 0.5, der blev udgivet i juni 2016. Ondřej Ilčík, der leder udviklingen af IDE'en i Codasip, er i kontakt med projektet og sikrer ekstremt vigtig feedback fra en "third-party adapter". Han har endda fundet lidt tid til at deltage direkte i udviklingen af projektet ved at implementere UI-laget (~ 4000 linjer kode) til et af eksemplerne på Handly, Java-modellen. Flere detaljer "fra første hånd" om brugen af Handly af adapterne kan findes på siden. projekt.
Vi håber, at efter udgivelsen af version 1.0 med garanti for API-stabilitet og projektets afslutning af inkubationsfasen, vil Handly få nye adaptere. Indtil videre fortsætter projektet med at blive testet og forbedret yderligere, med to "store" udgivelser om året – i juni (på samme dato som den samtidige udgivelse af Eclipse) og i december, hvilket sikrer en forudsigelig tidsplan, som adapterne kan stole på. Det kan også tilføjes, at projektets "bug rate" forbliver stabilt lav, og Handly fungerer pålideligt i produkterne fra tidlige adaptere siden de første versioner. For yderligere information om Eclipse Handly kan man bruge og .
Kilde: habr.com
