Misschien, heeft al lang geen speciale introductie meer nodig. Veel mensen zijn bekend met Eclipse dankzij de Eclipse Java-ontwikkeltools (). Het is deze populaire open-source Java IDE die de meeste ontwikkelaars associëren met het woord “Eclipse”. Eclipse is echter zowel een uitbreidbaar platform voor het integreren van ontwikkelingstools (Eclipse Platform), als een aantal IDE's die op basis daarvan zijn gebouwd, waaronder JDT. Eclipse is zowel het Eclipse Project, het top-level project dat de ontwikkeling van het Eclipse Platform en de JDT coördineert, als de Eclipse SDK, het opgeleverde resultaat van die ontwikkeling. Ten slotte is Eclipse een open-source Foundation met een enorme gemeenschap van projecten, die niet allemaal in Java zijn geschreven of gerelateerd zijn aan ontwikkelingstools (bijvoorbeeld projecten и ). De wereld van Eclipse is zeer divers.
In dit artikel, dat een overzichtskarakter heeft, zullen we proberen enkele basisprincipes van de Eclipse-architectuur te bekijken als een platform voor het bouwen van geïntegreerde ontwikkelingstools en een eerste idee geven van de Eclipse-componenten die de basis vormen van de technologie. platform voor de “nieuwe Configurator” 1C: Enterprise. . Natuurlijk zal een dergelijke recensie onvermijdelijk grotendeels oppervlakkig en tamelijk beperkt zijn, ook omdat we ons niet alleen op Eclipse-ontwikkelaars als doelgroep richten. We hopen echter dat zelfs ervaren Eclipse-ontwikkelaars interessante informatie in het artikel kunnen vinden. We zullen het bijvoorbeeld hebben over een van de ‘geheimen van Eclipse’, een relatief nieuw en weinig bekend project , dat werd opgericht en ondersteund door 1C.
Inleiding tot Eclipse-architectuur
Laten we eerst kijken naar enkele algemene aspecten van de Eclipse-architectuur aan de hand van het voorbeeld (JDT). De keuze voor JDT als voorbeeld is niet toevallig. Dit is de eerste geïntegreerde ontwikkelomgeving die in Eclipse verschijnt. Andere *DT Eclipse-projecten, zoals Eclipse C/C++ Development Tooling (CDT), zijn later gemaakt en ontlenen zowel architecturale basisprincipes als individuele broncodefragmenten van JDT. De fundamenten van de architectuur vastgelegd in JDT zijn tot op de dag van vandaag relevant voor vrijwel elke IDE die bovenop het Eclipse Platform is gebouwd, inclusief 1C:Enterprise Development Tools.
Allereerst moet worden opgemerkt dat Eclipse wordt gekenmerkt door een vrij duidelijke architecturale gelaagdheid, met de scheiding tussen taalonafhankelijke functionaliteit en functionaliteit die is ontworpen om specifieke programmeertalen te ondersteunen, en de scheiding tussen UI-onafhankelijke ‘kern’-componenten en componenten die daarmee verband houden. met ondersteunende gebruikersinterface.
Het Eclipse Platform definieert dus een gemeenschappelijke, taalonafhankelijke infrastructuur, en de Java-ontwikkeltools voegen een volledig uitgeruste Java IDE toe aan Eclipse. Zowel het Eclipse Platform als de JDT bestaan uit verschillende componenten, die elk tot een UI-onafhankelijke ‘kern’ of een UI-laag behoren (Afbeelding 1).
Rijst. 1. Eclipse-platform en JDT
Laten we de belangrijkste componenten van het Eclipse-platform opsommen:
- Runtime — Definieert de plug-ininfrastructuur. Eclipse kenmerkt zich door een modulaire architectuur. In wezen is Eclipse een verzameling "extensiepunten" en "extensies".
- Werkruimte — Beheert één of meerdere projecten. Een project bestaat uit mappen en bestanden die rechtstreeks aan het bestandssysteem zijn toegewezen.
- Standaardwidgettoolkit (SWT) - Biedt basiselementen van de gebruikersinterface die zijn geïntegreerd met het besturingssysteem.
- JGezicht — Biedt een aantal UI-frameworks die bovenop SWT zijn gebouwd.
- Werkbank — Definieert het Eclipse UI-paradigma: editors, weergaven, perspectieven.
Het moet gezegd worden dat het Eclipse Platform ook veel andere nuttige componenten biedt voor het bouwen van geïntegreerde ontwikkeltools, waaronder Debug, Compare, Search en Team. Speciale vermelding verdient JFace Text - de basis voor het bouwen van "slimme editors" van de broncode. Helaas is zelfs een vluchtig onderzoek van deze componenten, evenals de componenten van de UI-laag, niet mogelijk binnen de reikwijdte van dit artikel, dus in de rest van deze sectie zullen we ons beperken tot een overzicht van de belangrijkste “kern”-componenten van het Eclipse-platform en JDT.
Kernruntime
De infrastructuur van de Eclipse-plug-in is gebaseerd op en verstrekt door het project . Elke Eclipse-plug-in is een OSGi-bundel. De OSGi-specificatie definieert met name mechanismen voor versiebeheer en het oplossen van afhankelijkheid. Naast deze standaardmechanismen introduceert Equinox het concept uitbreidingspunten. Elke plug-in kan zijn eigen uitbreidingspunten definiëren en ook extra functionaliteit (“extensies”) aan het systeem toevoegen met behulp van uitbreidingspunten die door dezelfde of andere plug-ins worden gedefinieerd. Elke gedetailleerde beschrijving van de OSGi- en Equinox-mechanismen valt buiten het bestek van dit artikel. Laten we alleen opmerken dat de modularisering in Eclipse totaal is (elk subsysteem, inclusief Runtime, bestaat uit een of meer plug-ins), en bijna alles in Eclipse is een uitbreiding. Bovendien waren deze principes al lang vóór de introductie van OSGi ingebed in de Eclipse-architectuur (destijds gebruikten ze hun eigen technologie, vergelijkbaar met OSGi).
Kernwerkruimte
Bijna elke geïntegreerde ontwikkelomgeving die bovenop het Eclipse Platform is gebouwd, werkt met Eclipse-werkruimte. Het is de werkruimte die doorgaans de broncode bevat van de applicatie die in de IDE is ontwikkeld. De werkruimte is rechtstreeks gekoppeld aan het bestandssysteem en bestaat uit projecten die mappen en bestanden bevatten. Deze projecten, mappen en bestanden worden aangeroepen bronnen werkruimte. De werkruimte-implementatie in Eclipse dient als cache in relatie tot het bestandssysteem, wat het mogelijk maakt om het doorlopen van de bronboom aanzienlijk te versnellen. Daarnaast biedt Workspace een aantal aanvullende diensten, waaronder и .
De component Core Resources (plug-in org.eclipse.core.resources) is verantwoordelijk voor de ondersteuning van de werkruimte en de bijbehorende bronnen. Deze component biedt met name programmatische toegang tot de werkruimte in het formulier hulpbronnen modellen. Om effectief met dit model te kunnen werken, hebben klanten een eenvoudige manier nodig om een link naar een bron te presenteren. In dit geval zou het wenselijk zijn om het object dat de status van de bron in het model rechtstreeks opslaat, te verbergen voor clienttoegang. Anders zou de cliënt, in het geval van bijvoorbeeld het verwijderen van een bestand, een object kunnen blijven vasthouden dat niet langer in het model staat, met de daaruit voortvloeiende problemen. Eclipse lost dit probleem op met behulp van iets genaamd handvat bron. Handle fungeert als sleutel (het kent alleen het pad naar de bron in de werkruimte) en controleert volledig de toegang tot het interne modelobject, dat rechtstreeks informatie opslaat over de status van de bron. Dit ontwerp is een variatie op het patroon .
Rijst. Figuur 2 illustreert het Handle/Body-idioom zoals toegepast op het resourcemodel. De IResource-interface vertegenwoordigt het handvat van een bron en is een API, in tegenstelling tot de klasse Resource, die deze interface implementeert, en de klasse ResourceInfo, die de hoofdtekst vertegenwoordigt, die geen API's zijn. We benadrukken dat handle alleen het pad naar de resource kent ten opzichte van de hoofdmap van de werkruimte en geen link naar resource-informatie bevat. Resource-info-objecten vormen een zogenaamde “elementenboom”. Deze datastructuur wordt volledig gematerialiseerd in het geheugen. Om de broninfo-instantie te vinden die overeenkomt met een handle, wordt de elementenboom doorlopen volgens het pad dat in die handle is opgeslagen.
Rijst. 2. IResource en ResourceInfo
Zoals we later zullen zien, wordt het basisontwerp van het resourcemodel (we zouden het handle-gebaseerd kunnen noemen) in Eclipse ook voor andere modellen gebruikt. Laten we voor nu enkele onderscheidende eigenschappen van dit ontwerp opsommen:
- Handle is een waardeobject. Waardeobjecten zijn onveranderlijke objecten waarvan de gelijkheid niet gebaseerd is op identiteit. Dergelijke voorwerpen kunnen veilig worden gebruikt als sleutel in gehashte containers. Meerdere exemplaren van handle kunnen naar dezelfde bron verwijzen. Om ze te vergelijken, moet je de equals(Object)-methode gebruiken.
- Handle definieert het gedrag van een bron, maar bevat geen informatie over de status van de bron (de enige gegevens die erin worden opgeslagen zijn de "sleutel", het pad naar de bron).
- Handle kan verwijzen naar een bron die nog niet bestaat (een bron die nog niet is gemaakt, of een bron die al is verwijderd). Het bestaan van een bron kan worden gecontroleerd met behulp van de methode IResource.exists().
- Sommige bewerkingen kunnen uitsluitend worden geïmplementeerd op basis van informatie die in de handle zelf is opgeslagen (zogenaamde alleen-handle-bewerkingen). Voorbeelden zijn IResource.getParent(), getFullPath(), enz. De hulpbron hoeft niet te bestaan om een dergelijke operatie te laten slagen. Bewerkingen waarvoor een resource nodig is om te slagen, genereren een CoreException als de resource niet bestaat.
Eclipse biedt een efficiënt mechanisme voor het melden van wijzigingen in de werkruimtebronnen (Afbeelding 3). Bronnen kunnen veranderen als gevolg van acties die worden uitgevoerd binnen de Eclipse IDE zelf of als gevolg van synchronisatie met het bestandssysteem. In beide gevallen krijgen klanten die zich abonneren op notificaties gedetailleerde informatie over de wijzigingen in de vorm van ‘resource delta’s’. Een delta beschrijft veranderingen tussen twee toestanden van de (sub)boom van een werkruimtebron en is zelf een boom, waarbij elk knooppunt een wijziging aan een bron beschrijft en een lijst met delta's op het volgende niveau bevat die wijzigingen aan onderliggende bronnen beschrijven.
Rijst. 3. IResourceChangeEvent en IResourceDelta
Het meldingsmechanisme op basis van resourcedelta’s heeft de volgende kenmerken:
- Een enkele verandering en vele veranderingen worden beschreven met behulp van dezelfde structuur, aangezien de delta is opgebouwd volgens het principe van recursieve compositie. Abonneeklanten kunnen meldingen over resourcewijzigingen verwerken met behulp van recursieve afdaling door een boom van delta's.
- De delta bevat volledige informatie over wijzigingen aan de bron, inclusief de verplaatsing ervan en/of wijzigingen in de “markeringen” die eraan zijn gekoppeld (compilatiefouten worden bijvoorbeeld weergegeven als markeringen).
- Omdat bronreferenties via de handle worden gemaakt, kan delta uiteraard naar een externe bron verwijzen.
Zoals we binnenkort zullen zien, zijn de belangrijkste componenten van het ontwerp van het mechanisme voor het melden van wijzigingen in het resourcemodel ook relevant voor andere op handvaten gebaseerde modellen.
JDT-kern
Het Eclipse-resourcemodel voor de werkruimte is een fundamenteel taalonafhankelijk model. De JDT Core-component (plugin org.eclipse.jdt.core) biedt een API voor het navigeren en analyseren van de werkruimtestructuur vanuit Java-perspectief, het zogenaamde “Java-model” (Java-model). Deze API is gedefinieerd in termen van Java-elementen, in tegenstelling tot de onderliggende resourcemodel-API, die is gedefinieerd in termen van mappen en bestanden. De belangrijkste interfaces van de Java-elementenboom worden getoond in Fig. 4.
Rijst. 4. Java-modelelementen
Het Java-model gebruikt hetzelfde handle/body-idioom als het resourcemodel (Afbeelding 5). IJavaElement is het handvat en JavaElementInfo speelt de rol van het lichaam. De IJavaElement-interface definieert een protocol dat gemeenschappelijk is voor alle Java-elementen. Sommige van de methoden zijn alleen-handvat: getElementName(), getParent(), enz. Het JavaElementInfo-object slaat de status van het overeenkomstige element op: de structuur en attributen ervan.
Rijst. 5. IJavaElement en JavaElementInfo
Het Java-model vertoont enkele verschillen in de implementatie van het basishandvat-/body-ontwerp vergeleken met het resourcemodel. Zoals hierboven opgemerkt, is in het bronnenmodel de elementenboom, waarvan de knooppunten broninfo-objecten zijn, volledig in het geheugen opgenomen. Maar het Java-model kan een aanzienlijk groter aantal elementen bevatten dan de resourceboom, omdat het ook de interne structuur van .java- en .class-bestanden vertegenwoordigt: typen, velden en methoden.
Om te voorkomen dat de hele boom met elementen in het geheugen volledig wordt gerealiseerd, gebruikt de implementatie van het Java-model een LRU-cache met elementinformatie van beperkte grootte, waarbij de sleutel handle IJavaElement is. elementinfo-objecten worden op aanvraag gemaakt terwijl door de elementenboom wordt genavigeerd. In dit geval worden de minst gebruikte items uit de cache verwijderd en blijft het geheugengebruik van het model beperkt tot de opgegeven cachegrootte. Dit is een ander voordeel van een op handvaten gebaseerd ontwerp, dat dergelijke implementatiedetails volledig verbergt voor de clientcode.
Het mechanisme voor het melden van wijzigingen in Java-elementen is in het algemeen vergelijkbaar met het mechanisme voor het volgen van wijzigingen in werkruimtebronnen zoals hierboven besproken. Een client die wijzigingen in het Java-model wil volgen, abonneert zich op meldingen, die worden weergegeven als een ElementChangedEvent-object dat een IJavaElementDelta bevat (Afbeelding 6).
Rijst. 6. ElementChangedEvent en IJavaElementDelta
Het Java-model bevat geen informatie over methode-body's of naamresolutie, dus voor gedetailleerde analyse van code geschreven in Java biedt JDT Core een aanvullend (niet-handle-gebaseerd) model: (abstracte syntaxisboom, AST). AST vertegenwoordigt het resultaat van het parseren van de brontekst. AST-knooppunten komen overeen met elementen van de structuur van de bronmodule (declaraties, operatoren, uitdrukkingen, enz.) en bevatten informatie over de coördinaten van het overeenkomstige element in de brontekst, evenals (als optie) informatie over naamresolutie in de vorm van links naar zogenaamde bindingen. Bindingen zijn objecten die benoemde entiteiten vertegenwoordigen, zoals typen, methoden en variabelen die bekend zijn bij de compiler. In tegenstelling tot AST-knooppunten, die een boom vormen, ondersteunen bindingen kruisverwijzingen en vormen ze doorgaans een grafiek. De abstracte klasse ASTNode is de gemeenschappelijke basisklasse voor alle AST-knooppunten. ASTNode-subklassen komen overeen met specifieke syntactische constructies van de Java-taal.
Omdat syntaxisbomen een aanzienlijke hoeveelheid geheugen kunnen verbruiken, slaat JDT slechts één AST op in de cache voor de actieve editor. In tegenstelling tot het Java-model wordt het AST doorgaans gezien als een 'tussenliggend', 'tijdelijk' model waarvan de leden niet mogen worden vermeld door klanten buiten de context van de operatie die tot de oprichting van de AST heeft geleid.
De genoemde drie modellen (Java-model, AST, bindingen) vormen samen de basis voor het bouwen van “intelligente ontwikkeltools” in JDT, waaronder een krachtige Java-editor met verschillende “helpers”, verschillende acties voor het verwerken van broncode (inclusief het organiseren van een lijst met importcodes) namen en opmaak volgens de aangepaste stijl), zoek- en refactoringtools. In dit geval speelt het Java-model een speciale rol, omdat het wordt gebruikt als basis voor een visuele weergave van de structuur van de applicatie die wordt ontwikkeld (bijvoorbeeld in Package Explorer, Outline, Search, Call Hierarchy en Typ Hiërarchie).
Eclipse-componenten gebruikt in 1C:Enterprise Developments Tools
In afb. Figuur 7 toont de Eclipse-componenten die de basis vormen van het technologieplatform voor 1C:Enterprise Development Tools.
Rijst. 7. Eclipse als platform voor 1C:Enterprise Development Tools
Eclipse-platform biedt basisinfrastructuur. In de vorige paragraaf hebben we enkele aspecten van deze infrastructuur bekeken.
(EMF) biedt een algemene manier om gestructureerde gegevens te modelleren. EMF is geïntegreerd met het Eclipse Platform, maar kan ook afzonderlijk worden gebruikt in reguliere Java-applicaties. Vaak zijn nieuwe Eclipse-ontwikkelaars al goed bekend met EMF, hoewel ze de fijne kneepjes van het Eclipse-platform nog niet volledig begrijpen. Een van de redenen voor zo'n welverdiende populariteit is het universele ontwerp, dat onder meer een uniforme API op metaniveau omvat, waarmee je in algemene zin met elk EMF-model kunt werken. De basisimplementaties voor modelobjecten geleverd door EMF en het subsysteem voor het genereren van modelcode op basis van het metamodel verhogen de ontwikkelingssnelheid aanzienlijk en verminderen het aantal fouten. EMF bevat ook mechanismen voor het serialiseren van modellen, het volgen van wijzigingen in het model en nog veel meer.
Zoals elk hulpmiddel voor echt algemene doeleinden is EMF geschikt voor het oplossen van een breed scala aan modelleringsproblemen, maar voor sommige klassen modellen (bijvoorbeeld de hierboven besproken op handvaten gebaseerde modellen) kunnen meer gespecialiseerde modelleringshulpmiddelen nodig zijn. Praten over EMF is een ondankbare taak, vooral binnen de beperkte grenzen van één artikel, aangezien dit het onderwerp is van een apart boek, en een nogal dik boek. Laten we alleen opmerken dat het hoogwaardige systeem van generalisaties dat ten grondslag ligt aan het EMF de geboorte mogelijk heeft gemaakt van een hele reeks projecten gewijd aan modellering, die zijn opgenomen in het topproject samen met het EMF zelf. Eén zo'n project is Eclipse Xtext.
biedt een infrastructuur voor "tekstmodellering". Xtext gebruikt voor het ontleden van de brontekst en EMF voor het weergeven van de resulterende ASG (abstracte semantische grafiek, die in wezen een combinatie is van AST en bindingen), ook wel het “semantische model” genoemd. De grammatica van de door Xtext gemodelleerde taal wordt beschreven in de eigen taal van Xtext. Hierdoor kunt u niet alleen een grammaticabeschrijving voor ANTLR genereren, maar ook een AST-serialisatiemechanisme verkrijgen (dat wil zeggen dat Xtext zowel een parser als een unparser biedt), een contexthint en een aantal andere taalcomponenten. Aan de andere kant is de grammaticataal die in Xtext wordt gebruikt minder flexibel dan bijvoorbeeld de grammaticataal die in ANTLR wordt gebruikt. Daarom is het soms nodig om de geïmplementeerde taal naar Xtext te “buigen”, wat meestal geen probleem is als we het hebben over een taal die helemaal opnieuw wordt ontwikkeld, maar onaanvaardbaar kan zijn voor talen met een reeds gevestigde syntaxis. Desondanks is Xtext momenteel de meest volwassen, veelzijdige en veelzijdige tool in Eclipse voor het bouwen van programmeertalen en ontwikkelingstools daarvoor. Het is met name een ideaal hulpmiddel voor rapid prototyping (domeinspecifieke taal, DSL). Naast de hierboven genoemde “taalkern” gebaseerd op ANTLR en EMF, biedt Xtext veel nuttige componenten op een hoger niveau, waaronder indexeringsmechanismen, incrementele constructie, een “slimme editor” en nog veel, veel meer, maar laat de handvat- gebaseerde taalmodellen. Net als EMF is Xtext een onderwerp dat een apart boek waard is, en we kunnen op dit moment nauwelijks in het kort over alle mogelijkheden ervan praten.
1C:Enterprise Development Tools maken actief gebruik van zowel EMF zelf als een aantal andere Eclipse Modeling-projecten. In het bijzonder is Xtext een van de fundamenten van ontwikkelingstools voor dergelijke 1C:Enterprise-talen als de ingebouwde programmeertaal en querytaal. Een andere basis voor deze ontwikkeltools is het Eclipse Handly-project, dat we in meer detail zullen bespreken (van de genoemde Eclipse-componenten is dit nog steeds de minst bekende).
, een deelproject van het topniveauproject Eclipse Technology, ontstond als resultaat van een eerste codebijdrage aan de Eclipse Foundation door 1C in 2014. Sindsdien is 1C de ontwikkeling van het project blijven ondersteunen: Handly committers zijn werknemers van het bedrijf. Het project is klein, maar bezet een vrij unieke niche binnen Eclipse: het belangrijkste doel is het ondersteunen van de ontwikkeling van op handvaten gebaseerde modellen.
De architectonische basisprincipes van op handvaten gebaseerde modellen, zoals het handvat/lichaam-idioom, zijn hierboven besproken, waarbij het resourcemodel en het Java-model als voorbeelden zijn gebruikt. Het merkte ook op dat zowel het resourcemodel als het Java-model belangrijke fundamenten zijn voor de Eclipse Java-ontwikkeltools (JDT). En aangezien bijna alle *DT Eclipse-projecten een architectuur hebben die lijkt op die van JDT, zou het niet erg overdreven zijn om te zeggen dat op handle gebaseerde modellen ten grondslag liggen aan veel, zo niet alle IDE's die bovenop het Eclipse-platform zijn gebouwd. De Eclipse C/C++ Development Tooling (CDT) heeft bijvoorbeeld een op handle gebaseerd C/C++-model dat dezelfde rol speelt in de CDT-architectuur als het Java-model in de JDT.
Vóór Handly bood Eclipse geen gespecialiseerde bibliotheken aan voor het bouwen van op handle gebaseerde taalmodellen. De modellen die momenteel bestaan, zijn voornamelijk gemaakt door de Java-modelcode rechtstreeks aan te passen (ook wel kopiëren/plakken genoemd), in gevallen waarin dit dit toelaat Eclipse publieke licentie (EPL). (Het is duidelijk dat dit meestal geen juridische kwestie is voor bijvoorbeeld Eclipse-projecten zelf, maar niet voor closed source-producten.) Naast het inherente lukraakheid introduceert deze techniek bekende problemen: codeduplicatie die wordt geïntroduceerd bij het aanpassen aan fouten, enz. Wat nog erger is, is dat de resulterende modellen ‘dingen op zichzelf’ blijven en geen voordeel halen uit het potentieel voor eenwording. Maar het isoleren van gemeenschappelijke concepten en protocollen voor op handvaten gebaseerde taalmodellen zou kunnen leiden tot het creëren van herbruikbare componenten om ermee te werken, vergelijkbaar met wat er gebeurde in het geval van EMF.
Het is niet zo dat Eclipse deze problemen niet begreep. Terug in 2005 , waarin de ervaring met de ontwikkeling van het CDT-prototype wordt samengevat, de noodzaak om een gemeenschappelijke infrastructuur voor taalmodellen te creëren, inclusief op handvaten gebaseerde modellen. Maar zoals vaak gebeurt, is de implementatie van deze ideeën vanwege taken met een hogere prioriteit nooit zover gekomen. Ondertussen is factorisatie van *DT-code nog steeds een van de onderontwikkelde onderwerpen in Eclipse.
In zekere zin is het Handly-project ontworpen om ongeveer dezelfde problemen op te lossen als EMF, maar dan voor op handvaten gebaseerde modellen, en in de eerste plaats taalmodellen (dat wil zeggen, die elementen van de structuur van een bepaalde programmeertaal vertegenwoordigen). De belangrijkste doelen die zijn gesteld bij het ontwerpen van Handly staan hieronder vermeld:
- Identificatie van de belangrijkste abstracties van het vakgebied.
- Het verminderen van de inspanning en het verbeteren van de kwaliteit van de implementatie van op handvaten gebaseerde taalmodellen door hergebruik van code.
- Het bieden van een uniforme API op metaniveau voor de resulterende modellen, waardoor het mogelijk wordt gemeenschappelijke IDE-componenten te creëren die werken met op taalhandvatten gebaseerde modellen.
- Flexibiliteit en schaalbaarheid.
- Integratie met Xtext (in een aparte laag).
Om gemeenschappelijke concepten en protocollen onder de aandacht te brengen, werden bestaande implementaties van op taalhandvatten gebaseerde modellen geanalyseerd. De belangrijkste interfaces en basisimplementaties van Handly worden getoond in Fig. 8.
Rijst. 8. Gemeenschappelijke interfaces en basisimplementaties van Handly-elementen
De IElement-interface vertegenwoordigt de handle van een element en is gemeenschappelijk voor elementen van alle op Handly gebaseerde modellen. De abstracte klasse Element implementeert het gegeneraliseerde handgreep-/lichaamsmechanisme (Fig. 9).
Rijst. 9. IElement en generieke handgreep/body-implementatie
Bovendien biedt Handly een algemeen mechanisme voor het melden van wijzigingen in modelelementen (Fig. 10). Zoals u kunt zien, is het in grote lijnen vergelijkbaar met de meldingsmechanismen die zijn geïmplementeerd in het resourcemodel en het Java-model, en wordt IElementDelta gebruikt om een uniforme weergave van informatie over elementwijzigingen te bieden.
Rijst. 10. Algemene interfaces en basisimplementaties van het Handly-meldingsmechanisme
Het hierboven besproken Handly-gedeelte (Fig. 9 en 10) kan worden gebruikt om vrijwel alle op handvaten gebaseerde modellen weer te geven. Voor het creëren taalkundig modellen biedt het project extra functionaliteit - in het bijzonder gemeenschappelijke interfaces en basisimplementaties voor elementen van de brontekststructuur, de zogenaamde bronelementen (Afb. 8). De ISourceFile-interface vertegenwoordigt een bronbestand en ISourceConstruct vertegenwoordigt een element binnen het bronbestand. De abstracte klassen SourceFile en SourceConstruct implementeren gegeneraliseerde mechanismen om het werken met bronbestanden en hun elementen te ondersteunen, bijvoorbeeld het werken met tekstbuffers, het binden aan de coördinaten van een element in de brontekst, het afstemmen van modellen met de huidige inhoud van een werkkopiebuffer , enz. Het implementeren van deze mechanismen is meestal een behoorlijke uitdaging, en Handly kan de inspanningen van het ontwikkelen van op handvaten gebaseerde taalmodellen aanzienlijk verminderen door basisimplementaties van hoge kwaliteit te bieden.
Naast de hierboven genoemde kernmechanismen biedt Handly een infrastructuur voor tekstbuffers en snapshots, ondersteuning voor integratie met broncode-editors (inclusief kant-en-klare integratie met de Xtext-editor), evenals enkele algemene UI-componenten die werken met broncode-editors.Handige modellen zoals een overzichtsframework. Om de mogelijkheden ervan te illustreren, biedt het project verschillende voorbeelden, waaronder een implementatie van het Java-model in Handly. (Vergeleken met de volledige implementatie van het Java-model in JDT is dit model opzettelijk enigszins vereenvoudigd voor meer duidelijkheid.)
Zoals eerder opgemerkt, lag en blijft de nadruk tijdens het initiële ontwerp en de daaropvolgende ontwikkeling van Handly op schaalbaarheid en flexibiliteit.
In principe schalen modellen met handgreep vrij goed “by design”. Met het handle/body-idioom kunt u bijvoorbeeld de hoeveelheid geheugen beperken die een model verbruikt. Maar er zijn ook nuances. Bij het testen van Handly op schaalbaarheid werd dus een probleem ontdekt bij de implementatie van het meldingsmechanisme: toen een groot aantal elementen werd gewijzigd, kostte het construeren van delta's te veel tijd. Het bleek dat hetzelfde probleem zich voordeed in het JDT Java-model, waarvan de bijbehorende code ooit was aangepast. We hebben de bug in Handly opgelost en een soortgelijke patch voor JDT voorbereid, die dankbaar werd ontvangen. Dit is slechts één voorbeeld waarbij het introduceren van Handly in bestaande modelimplementaties potentieel nuttig zou kunnen zijn, omdat in dit geval een dergelijke bug op slechts één plek kan worden opgelost.
Om de implementatie van Handly in bestaande modelimplementaties technisch haalbaar te maken, moet de bibliotheek over aanzienlijke flexibiliteit beschikken. Het grootste probleem is het behouden van achterwaartse compatibiliteit binnen het API-model. Dit probleem is opgelost in door de modelspecifieke API, gedefinieerd en volledig beheerd door de ontwikkelaar, duidelijk te scheiden van de uniforme API op metaniveau die door de bibliotheek wordt geleverd. Dit maakt het niet alleen technisch mogelijk om Handly in bestaande implementaties te implementeren, maar geeft de nieuwe modelontwikkelaar ook veel vrijheid bij het ontwerpen van de API.
Flexibiliteit kent ook andere aspecten. Handly legt bijvoorbeeld vrijwel geen beperkingen op aan de structuur van het model en kan worden gebruikt om zowel algemene als domeinspecifieke talen te modelleren. Bij het construeren van de structuur van het bronbestand schrijft Handly geen specifieke vorm van AST-representatie voor en vereist in principe zelfs niet eens de aanwezigheid van een AST zelf, waardoor compatibiliteit met vrijwel elk parseermechanisme wordt gegarandeerd. Ten slotte ondersteunt Handly volledige integratie met Eclipse-werkruimte, maar kan dankzij de integratie met bestandssystemen ook rechtstreeks met bestandssystemen werken (EFS).
Huidige versie kwam uit in december 2016. Ondanks het feit dat het project zich momenteel in een incubatiefase bevindt en de API nog niet definitief is opgelost, wordt Handly al gebruikt in twee grote commerciële producten die het risico namen om als ‘early adopters’ op te treden, en ik moet zeggen: heb er nog geen spijt van.
Zoals hierboven vermeld, is een van deze producten 1C:Enterprise Development Tools, waarbij Handly vanaf het allereerste begin wordt gebruikt om elementen van de structuur op hoog niveau van dergelijke 1C:Enterprise-talen te modelleren, zoals de ingebouwde programmeertaal en querytaal . Een ander product is minder bekend bij het grote publiek. Dit , een geïntegreerde ontwerpomgeving voor applicatiespecifieke instructiesetprocessor (ASIP), die zowel binnen het Tsjechische bedrijf Codasip zelf als door zijn klanten wordt gebruikt, waaronder , , , . Codasip gebruikt Handly in productie sinds 2015, te beginnen met versie Handly 0.2. De nieuwste release van Codasip Studio gebruikt versie 0.5, uitgebracht in juni 2016. Ondřej Ilčík, die leiding geeft aan de IDE-ontwikkeling bij Codasip, staat in contact met het project en geeft essentiële feedback namens de “derde adoptant”. Hij kon zelfs wat vrije tijd vinden om rechtstreeks deel te nemen aan de ontwikkeling van het project, door een UI-laag (~4000 regels code) te implementeren voor een van de Handly-voorbeelden, een Java-model. Meer gedetailleerde informatie uit de eerste hand over het gebruik van Handly door adoptanten vindt u op de pagina project.
We hopen dat Handly na de release van versie 1.0, met een garantie voor API-stabiliteit en het project dat de incubatiestatus verlaat, nieuwe gebruikers zal hebben. In de tussentijd gaat het project door met het testen en verder verbeteren van de API, waarbij twee "grote" releases per jaar worden uitgebracht - in juni (dezelfde datum als de gelijktijdige Eclipse-release) en december, wat een voorspelbaar schema oplevert waar gebruikers op kunnen vertrouwen. We kunnen er ook aan toevoegen dat het ‘bugpercentage’ van het project op een consistent laag niveau blijft en dat Handly sinds de allereerste versies betrouwbaar heeft gewerkt in de producten van early adopters. Om Eclipse Handly verder te verkennen, kunt u gebruiken и .
Bron: www.habr.com