Misschien, behoeft al lang geen speciale introductie meer. 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 ook een uitbreidbaar platform voor de integratie van ontwikkeltools (Eclipse Platform) en een aantal IDE's die op de basis ervan zijn gebouwd, waaronder JDT. Eclipse is tevens het Eclipse Project, een project op topniveau dat de ontwikkeling van het Eclipse Platform en JDT coördineert, en de Eclipse SDK, het opgeleverde resultaat van deze ontwikkeling. Ten slotte is Eclipse een open-source Foundation met een enorme community van projecten, waarvan niet alle in Java zijn geschreven of gerelateerd zijn aan ontwikkeltools (bijvoorbeeld de projecten и ). De wereld van Eclipse is zeer divers.
In dit artikel, dat een review-achtig karakter heeft, zullen we proberen enkele basisprincipes van de Eclipse-architectuur te onderzoeken als platform voor het bouwen van geïntegreerde ontwikkeltools en een eerste idee te geven van de Eclipse-componenten die de basis vormen van het technologische platform voor de "nieuwe Configurator" 1C: Enterprise, Natuurlijk zal zo'n review onvermijdelijk grotendeels oppervlakkig en beperkt zijn, onder meer omdat we ons niet alleen richten op Eclipse-ontwikkelaars. We hopen echter dat zelfs ervaren Eclipse-ontwikkelaars interessante informatie in het artikel kunnen vinden. Zo vertellen we u bijvoorbeeld over een van de "geheimen van Eclipse", een relatief nieuw en weinig bekend project. , die werd opgericht en gesteund door 1C.
Inleiding tot Eclipse-architectuur
Laten we eerst eens kijken naar enkele algemene aspecten van de Eclipse-architectuur aan de hand van een voorbeeld (JDT). De keuze voor JDT als voorbeeld is niet toevallig. Het is de eerste geïntegreerde ontwikkelomgeving die in Eclipse verscheen. Andere *DT Eclipse-projecten, zoals Eclipse C/C++ Development Tooling (CDT), werden later ontwikkeld en ontleenden zowel de belangrijkste architectuurprincipes als individuele fragmenten broncode aan JDT. De architectuurfundamenten die in JDT zijn vastgelegd, zijn vandaag de dag nog steeds relevant voor vrijwel elke IDE die op 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 een scheiding tussen taalonafhankelijke functionaliteit en functionaliteit die bedoeld is om specifieke programmeertalen te ondersteunen, en een scheiding tussen UI-onafhankelijke "kern"-componenten en componenten die verband houden met de ondersteuning van de gebruikersinterface.
Het Eclipse-platform definieert dus een gemeenschappelijke, taalonafhankelijke infrastructuur, en de Java-ontwikkeltools voegen een volledig functionele Java IDE toe aan Eclipse. Zowel het Eclipse-platform als de JDT bestaan uit verschillende componenten, die elk tot een gebruikersinterface-onafhankelijke "kern" of een gebruikersinterface-laag behoren (Figuur 1).
Figuur 1. Eclipse-platform en JDT
Laten we de belangrijkste onderdelen van het Eclipse-platform eens op een rijtje zetten:
- Runtime — Definieert de plugin-infrastructuur. Eclipse wordt gekenmerkt door een modulaire architectuur. In wezen is Eclipse een verzameling van "uitbreidingspunten" en "extensies".
- Werkruimte — Beheert een of meer projecten. Een project bestaat uit mappen en bestanden die rechtstreeks aan het bestandssysteem zijn toegewezen.
- Standaard Widget Toolkit (SWT) - Biedt basiselementen voor de gebruikersinterface die geïntegreerd zijn met het besturingssysteem.
- JGezicht — Biedt een aantal UI-frameworks die op SWT zijn gebouwd.
- Werkbank — Definieert het Eclipse UI-paradigma: editors, weergaven, perspectieven.
Opgemerkt dient te worden dat het Eclipse Platform ook vele andere nuttige componenten biedt voor het bouwen van geïntegreerde ontwikkeltools, waaronder Debug, Compare, Search en Team. JFace Text, de basis voor het bouwen van "slimme editors" van broncode, verdient een speciale vermelding. Helaas is zelfs een vluchtige beschouwing van deze componenten, evenals de UI-laagcomponent, niet mogelijk binnen het kader van dit artikel. Daarom beperken we ons in de rest van deze sectie tot een overzicht van de belangrijkste "kerncomponenten" van het Eclipse Platform en JDT.
Kern Runtime
De Eclipse-plugininfrastructuur is gebaseerd op en wordt geleverd door het project Elke Eclipse-plugin is een OSGi-bundel. De OSGi-specificatie definieert onder andere mechanismen voor versiebeheer en het oplossen van afhankelijkheden. Naast deze standaardmechanismen introduceert Equinox het concept van uitbreidingspuntenElke plugin kan zijn eigen extensiepunten definiëren en ook extra functionaliteit ("extensies") aan het systeem toevoegen met behulp van extensiepunten die door dezelfde of andere plugins zijn gedefinieerd. Een gedetailleerde beschrijving van de OSGi- en Equinox-mechanismen valt buiten het bestek van dit artikel. Laten we alleen opmerken dat de modularisatie in Eclipse volledig is (elk subsysteem, inclusief Runtime, bestaat uit een of meer plugins) en dat bijna alles in Eclipse een extensie is. Bovendien waren deze principes al lang vóór de introductie van OSGi in de Eclipse-architectuur ingebed (destijds werd er een eigen technologie gebruikt, die in veel opzichten vergelijkbaar was met OSGi).
Kernwerkruimte
Vrijwel elke geïntegreerde ontwikkelomgeving die op het Eclipse-platform is gebouwd, werkt met de Eclipse-werkruimte. Dit is de werkruimte die doorgaans de broncode bevat van de applicatie die in de IDE wordt ontwikkeld. De werkruimte is direct gekoppeld aan het bestandssysteem en bestaat uit projecten die mappen en bestanden bevatten. Deze projecten, mappen en bestanden worden bronnen Werkruimte. De Eclipse-werkruimte-implementatie fungeert als cache voor het bestandssysteem, wat zorgt voor een merkbare snelheidsverhoging bij het doorlopen van de resource tree. Daarnaast biedt de werkruimte een aantal extra services, waaronder и .
De Core Resources-component (plugin org.eclipse.core.resources) is verantwoordelijk voor de ondersteuning van de werkruimte en de bijbehorende resources. Deze component biedt met name programmatische toegang tot de werkruimte in de vorm van: hulpbronmodellenOm effectief met dit model te werken, hebben clients een eenvoudige manier nodig om een verwijzing naar een resource weer te geven. Tegelijkertijd zou het wenselijk zijn om het object dat de status van de resource in het model direct opslaat, te verbergen voor clienttoegang. Anders zou de client, bijvoorbeeld bij het verwijderen van een bestand, een object kunnen blijven vasthouden dat niet langer in het model staat, met alle problemen van dien. Eclipse lost dit probleem op met behulp van de zogenaamde handvat resource. De handle fungeert als sleutel (deze kent alleen het pad naar de resource in de werkruimte) en beheert de toegang tot het interne modelobject volledig, dat direct informatie over de status van de resource opslaat. Dit ontwerp is een variatie op het patroon .
Figuur 2 illustreert de Handle/Body-idioom toegepast op het resourcemodel. De IResource-interface vertegenwoordigt de handle van een resource en is een API, in tegenstelling tot de Resource-klasse, die deze interface implementeert, en de ResourceInfo-klasse, die de body vertegenwoordigt, die geen API's zijn. Merk op dat de handle alleen het pad naar de resource kent ten opzichte van de root van de werkruimte en geen verwijzing naar de resource-info bevat. Resource-info-objecten vormen een zogenaamde elementenboom. Deze datastructuur wordt volledig in het geheugen gematerialiseerd. Om een resource-info-instantie te vinden die overeenkomt met een handle, wordt de elementenboom doorlopen volgens het pad dat in de handle is opgeslagen.
Figuur 2. IResource en ResourceInfo
Zoals we later zullen zien, wordt het basisontwerp van het resourcemodel (we kunnen het handle-gebaseerd noemen) in Eclipse ook voor andere modellen gebruikt. Laten we nu enkele kenmerkende eigenschappen van dit ontwerp op een rijtje zetten:
- Een handle is een waardeobject. Waardeobjecten zijn onveranderlijke objecten waarvan de gelijkheid niet gebaseerd is op identiteit. Dergelijke objecten kunnen veilig worden gebruikt als sleutels in gehashte containers. Meerdere handle-instanties kunnen naar dezelfde resource verwijzen. Gebruik de equals(Object)-methode om ze te vergelijken.
- Handle definieert het gedrag van de resource, maar bevat geen informatie over de status van de resource (de enige gegevens die worden opgeslagen zijn de "sleutel", het pad naar de resource).
- Handle kan verwijzen naar een niet-bestaande resource (een resource die nog niet is aangemaakt of een resource die al is verwijderd). Het bestaan van een resource kan worden gecontroleerd met de methode IResource.exists().
- Sommige bewerkingen kunnen worden geïmplementeerd op basis van informatie die uitsluitend in de handle zelf is opgeslagen (zogenaamde handle-only-bewerkingen). Voorbeelden hiervan zijn IResource.getParent(), getFullPath(), enz. De resource hoeft niet per se te bestaan om een dergelijke bewerking te laten slagen. Bewerkingen waarvoor de resource wel moet bestaan, genereren een uitzondering (CoreException) als de resource niet bestaat.
Eclipse biedt een effectief mechanisme voor het melden van wijzigingen in werkruimtebronnen (Fig. 3). Bronnen kunnen veranderen als gevolg van acties die worden uitgevoerd in de Eclipse IDE zelf, en als gevolg van synchronisatie met het bestandssysteem. In beide gevallen ontvangen clients die zich abonneren op meldingen gedetailleerde informatie over wijzigingen in de vorm van "resourcedelta's". Een delta beschrijft wijzigingen tussen twee statussen van een (sub)boom van een werkruimtebron en is zelf een boom, waarvan elk knooppunt een wijziging in een bron beschrijft en een lijst met delta's van het volgende niveau bevat, die wijzigingen in onderliggende bronnen beschrijven.
Figuur 3. IResourceChangeEvent en IResourceDelta
Het op resource delta gebaseerde meldingsmechanisme heeft de volgende kenmerken:
- Een enkele wijziging en een reeks wijzigingen worden beschreven met dezelfde structuur, aangezien de delta is opgebouwd volgens het principe van recursieve compositie. Abonnee-clients kunnen meldingen van resourcewijzigingen verwerken door recursief de deltaboom af te dalen.
- De delta bevat volledige informatie over de resourcewijziging, inclusief de verplaatsing ervan en/of wijzigingen in de bijbehorende 'markeringen' (compilatiefouten worden bijvoorbeeld weergegeven als markeringen).
- Omdat er naar bronnen wordt verwezen via een handle, kan de delta op natuurlijke wijze naar een externe bron verwijzen.
Zoals we straks zullen zien, zijn de basisontwerpprincipes van het mechanisme voor meldingen bij wijzigingen in het resourcemodel ook relevant voor andere op handvaten gebaseerde modellen.
JDT-kern
Het Eclipse-werkruimteresourcemodel is een fundamenteel taalonafhankelijk model. De JDT Core-component (plugin org.eclipse.jdt.core) biedt een API voor het navigeren door en analyseren van de werkruimtestructuur vanuit een Java-perspectief, het zogenaamde "Java-model" (Java-modelDeze API is gedefinieerd in termen van Java-elementen, in tegenstelling tot de onderliggende resource model API, die is gedefinieerd in termen van mappen en bestanden. De belangrijkste interfaces van de Java-elementenboom worden weergegeven in Figuur 4.
Figuur 4. Elementen van het Java-model
Het Java-model gebruikt dezelfde handle/body-idioom als het resourcemodel (Figuur 5). IJavaElement is de handle en JavaElementInfo speelt de rol van de body. De IJavaElement-interface definieert een protocol dat gemeenschappelijk is voor alle Java-elementen. Sommige methoden zijn alleen handle-only: getElementName(), getParent(), enz. Het JavaElementInfo-object slaat de status van het corresponderende element op: de structuur en attributen.
Rijst. 5. IJavaElement en JavaElementInfo
Het Java-model vertoont enkele verschillen in de implementatie van het basisontwerp van de handle/body in vergelijking met het resourcemodel. Zoals hierboven vermeld, bevindt de elementenboom, waarvan de knooppunten resource-info-objecten zijn, zich volledig in het geheugen. Het Java-model kan echter 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 volledige elementenboom volledig in het geheugen wordt gematerialiseerd, gebruikt de Java-modelimplementatie een LRU-elementinfocache met beperkte omvang, waarbij de sleutel de IJavaElement-handle is. Elementinfo-objecten worden op aanvraag aangemaakt terwijl er door de elementenboom wordt genavigeerd. In dit geval worden de minst gebruikte elementen uit de cache verwijderd en blijft het geheugengebruik van het model beperkt tot de opgegeven cachegrootte. Dit is een ander voordeel van het handle-gebaseerde ontwerp, dat dergelijke implementatiedetails volledig verbergt voor de clientcode.
Het mechanisme voor het melden van wijzigingen in Java-elementen is over het algemeen vergelijkbaar met het mechanisme voor het volgen van wijzigingen in werkruimtebronnen dat hierboven is besproken. Een client die wijzigingen in een Java-model wil volgen, abonneert zich op meldingen die worden gepresenteerd als een ElementChangedEvent-object dat IJavaElementDelta bevat (Fig. 6).
Rijst. 6. ElementChangedEvent en IJavaElementDelta
Het Java-model bevat geen informatie over methodelichamen of naamomzetting. Voor een gedetailleerde analyse van code die in Java is geschreven, biedt JDT Core daarom een aanvullend (niet op handvaten gebaseerd) model: (abstracte syntaxisboom, AST). AST vertegenwoordigt het resultaat van de syntactische analyse van de brontekst. AST-knooppunten corresponderen met de elementen van de bronmodulestructuur (declaraties, operatoren, expressies, enz.) en bevatten informatie over de coördinaten van het corresponderende element in de brontekst, evenals (optioneel) informatie over naamresolutie in de vorm van verwijzingen naar zogenaamde bindingenBindingen 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, zijn bindingen kruisverwijzingen en vormen ze over het algemeen een grafiek. De abstracte klasse ASTNode is de gemeenschappelijke basisklasse voor alle AST-knooppunten. ASTNode-subklassen corresponderen met specifieke syntactische constructies van de Java-taal.
Omdat syntaxisbomen aanzienlijke hoeveelheden geheugen kunnen verbruiken, cachet JDT slechts één AST voor de actieve editor. In tegenstelling tot het Java-model wordt de AST doorgaans gezien als een "intermediair", "tijdelijk" model waarvan de elementen niet door clients bewaard mogen worden buiten de context van de bewerking die de AST heeft geproduceerd.
De drie hierboven genoemde modellen (Java-model, AST, bindingen) vormen samen de basis voor het bouwen van "intelligente ontwikkeltools" in JDT, waaronder een krachtige Java-editor met diverse "helpers", diverse acties voor het verwerken van broncode (waaronder het organiseren van de lijst met importnamen en het opmaken ervan volgens de geconfigureerde stijl), zoek- en refactoringtools. Tegelijkertijd speelt het Java-model een bijzondere rol, omdat het wordt gebruikt als basis voor de visuele weergave van de structuur van de te ontwikkelen applicatie (bijvoorbeeld in Package Explorer, Outline, Search, Call Hierarchy en Type Hierarchy).
Eclipse-componenten gebruikt in 1C: Enterprise Developments Tools
Figuur 7 toont de Eclipse-componenten die de basis vormen van het technologische platform voor 1C:Enterprise Development Tools.
Figuur 7. Eclipse als platform voor 1C: Enterprise Development Tools
Eclipse-platform Biedt de basisinfrastructuur. We hebben enkele aspecten van deze infrastructuur in de vorige sectie besproken.
(EMF) biedt algemene tools voor het modelleren van gestructureerde data. EMF is geïntegreerd met het Eclipse-platform, maar kan ook afzonderlijk worden gebruikt in reguliere Java-applicaties. Beginnende Eclipse-ontwikkelaars zijn vaak al bekend met EMF, hoewel ze de complexiteit van het Eclipse-platform nog niet volledig begrijpen. Een van de redenen voor deze welverdiende populariteit is het universele ontwerp, dat onder andere een uniforme meta-level API omvat die gegeneraliseerd werken met elk EMF-model mogelijk maakt. De basisimplementaties voor modelobjecten en het subsysteem voor het genereren van modelcode vanuit het metamodel, geleverd door EMF, verhogen de ontwikkelsnelheid 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 elke echt universele tool is EMF geschikt voor het oplossen van een breed scala aan modelleringsproblemen, maar sommige modelklassen (bijvoorbeeld de hierboven besproken handle-gebaseerde modellen) vereisen mogelijk meer gespecialiseerde modelleringstools. Het bespreken van EMF is een ondankbare taak, vooral binnen de beperkte reikwijdte van één artikel, aangezien dit het onderwerp is van een apart boek, en een vrij dik boek. Laten we even opmerken dat het hoogwaardige systeem van generalisaties dat aan EMF ten grondslag ligt, heeft geleid tot de ontwikkeling van een hele reeks projecten die zich richten op modellering, en die zijn opgenomen in het project op het hoogste niveau. samen met EMF zelf. Een voorbeeld van zo'n project is Eclipse Xtext.
biedt een infrastructuur voor 'tekstmodellering'. Xtext gebruikt voor syntactische analyse 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 een "semantisch model" genoemd. De grammatica van de taal die met Xtext gemodelleerd is, wordt beschreven in de eigen Xtext-taal. Dit maakt het niet alleen mogelijk om een grammaticabeschrijving voor ANTLR te genereren, maar ook om een AST-serialisatiemechanisme te verkrijgen (d.w.z. Xtext biedt zowel een parser als een unparser), een contextuele hint en een aantal andere taalcomponenten. Aan de andere kant is de grammaticabeschrijvingstaal die in Xtext wordt gebruikt minder flexibel in vergelijking met bijvoorbeeld de grammaticabeschrijvingstaal in ANTLR. Daarom is het soms nodig om de geïmplementeerde taal aan te passen aan Xtext, wat meestal geen probleem is als we het hebben over een taal die vanaf nul wordt ontwikkeld, maar onacceptabel kan zijn voor talen met een reeds gevestigde syntaxis. Desondanks is Xtext momenteel de meest volwassen, feature-complete en veelzijdige tool in Eclipse voor het bouwen van programmeertalen en ontwikkeltools daarvoor. Het is met name een ideaal hulpmiddel voor rapid prototyping. (domeinspecifieke taal, DSL). Naast de bovengenoemde "taalkern" gebaseerd op ANTLR en EMF, biedt Xtext vele nuttige componenten op hoger niveau, waaronder indexeringsmechanismen, incrementele opbouw, een "slimme editor" en nog veel meer, maar laat taalhandvatgebaseerde modellen buiten beschouwing. Net als EMF is Xtext een onderwerp dat een apart boek waard is, en we kunnen nu nauwelijks alle mogelijkheden ervan kort beschrijven.
1C:Enterprise Development Tools maken actief gebruik van zowel EMF zelf als een aantal andere Eclipse Modeling-projecten. Xtext is met name een van de fundamenten van ontwikkeltools voor 1C:Enterprise-talen zoals de ingebouwde programmeertaal en querytaal. Een ander fundament van deze ontwikkeltools is het Eclipse Handly-project, dat we in meer detail zullen bespreken (van de genoemde Eclipse-componenten is dit tot nu toe de minst bekende).
, een subproject van het top-level Eclipse Technology project, ontstond uit een eerste codebijdrage aan de Eclipse Foundation door 1C in 2014. Sindsdien heeft 1C de ontwikkeling van het project ondersteund: Handly committers zijn medewerkers van XNUMXC. Het project is klein, maar neemt een vrij unieke niche in Eclipse in: het hoofddoel is het ondersteunen van de ontwikkeling van handle-gebaseerde modellen.
De basisarchitectuurprincipes van handle-gebaseerde modellen, zoals de handle/body-idioom, zijn hierboven besproken aan de hand van het resourcemodel en het Java-model als voorbeelden. Er werd ook opgemerkt dat zowel het resourcemodel als het Java-model belangrijke fundamenten vormen voor de Eclipse Java Development Tools (JDT). Aangezien vrijwel alle *DT Eclipse-projecten een architectuur hebben die vergelijkbaar is met de JDT, is het niet overdreven om te stellen dat handle-gebaseerde modellen ten grondslag liggen aan veel, zo niet alle, IDE's die op het Eclipse-platform zijn gebouwd. De Eclipse C/C++ Development Tooling (CDT) heeft bijvoorbeeld een C/C++ handle-gebaseerd model dat dezelfde rol speelt in de CDT-architectuur als het Java-model in de JDT.
Vóór Handly bood Eclipse geen gespecialiseerde bibliotheken voor het bouwen van taalhandle-gebaseerde modellen. De bestaande modellen werden voornamelijk gecreëerd door de Java-modelcode rechtstreeks aan te passen (ook wel kopiëren/plakken genoemd). in gevallen waarin het dat toelaat Eclipse Public License (EPL). (Natuurlijk is dit voor Eclipse-projecten meestal geen juridisch probleem, wat niet het geval is voor closed source-producten.) Naast het inherente gebrek aan systeem leidt deze methode tot bekende problemen: codeduplicatie, fouten die tijdens de aanpassing worden geïntroduceerd, enzovoort. Sterker nog, de resulterende modellen blijven "op zichzelf staande dingen" en benutten het bestaande potentieel voor unificatie niet. Het identificeren van gemeenschappelijke concepten en protocollen voor op taalhandvatten gebaseerde modellen zou echter kunnen leiden tot de ontwikkeling van herbruikbare componenten om ermee te werken, vergelijkbaar met wat er gebeurde in het geval van EMF.
Het is niet dat Eclipse deze problemen niet begreep. In 2005, een samenvatting van de ervaring met de ontwikkeling van het CDT-prototype, De noodzaak om een gemeenschappelijke infrastructuur voor taalmodellen te creëren, inclusief handle-gebaseerde modellen. Maar zoals vaak gebeurt, was er door taken met een hogere prioriteit geen tijd om deze ideeën te implementeren. Ondertussen blijft factorisatie van *DT-projectcode een van de onvoldoende ontwikkelde onderwerpen in Eclipse.
In zekere zin is het Handly-project ontworpen om ongeveer dezelfde problemen op te lossen als EMF, maar dan voor handle-gebaseerde modellen, en voornamelijk taalmodellen (d.w.z. die elementen van de structuur van een programmeertaal representeren). De belangrijkste doelen die tijdens het ontwerp van Handly zijn gesteld, worden hieronder vermeld:
- Identificatie van de belangrijkste abstracties van het vakgebied.
- Verminder de inspanning en verbeter de kwaliteit van de implementatie van op taalhandvatten gebaseerde modellen door hergebruik van code.
- Biedt een uniforme meta-API voor de resulterende modellen, waardoor het mogelijk wordt om gemeenschappelijke IDE-componenten te maken die werken met taalhandvatten-gebaseerde modellen.
- Flexibiliteit en schaalbaarheid.
- Integratie met Xtext (in een aparte laag).
Om gemeenschappelijke concepten en protocollen te identificeren, werden bestaande implementaties van handle-gebaseerde taalmodellen geanalyseerd. De belangrijkste interfaces en basisimplementaties van Handly worden weergegeven in Figuur 8.
Figuur 8. Algemene 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 Element-klasse implementeert het gegeneraliseerde handle/body-mechanisme (Figuur 9).
Figuur 9. IElement en generieke implementatie van handle/body
Bovendien biedt Handly een algemeen mechanisme voor het melden van wijzigingen in modelelementen (Figuur 10). Zoals u kunt zien, is dit grotendeels vergelijkbaar met de meldingsmechanismen die zijn geïmplementeerd in het resourcemodel en het Java-model, en gebruikt het IElementDelta om de informatie over elementwijzigingen te verenigen.
Figuur 10. Algemene interfaces en basisimplementaties van het Handly-meldingsmechanisme
Het hierboven besproken Handly-onderdeel (Fig. 9 en 10) kan worden gebruikt om vrijwel elk op handgrepen gebaseerd model te representeren. Om taalkundig modellen biedt het project aanvullende functionaliteit - in het bijzonder gemeenschappelijke interfaces en basisimplementaties voor elementen van de brontekststructuur, de zogenaamde bronelementen (Fig. 8). De ISourceFile-interface vertegenwoordigt een bronbestand en ISourceConstruct vertegenwoordigt een element binnen een bronbestand. De abstracte klassen SourceFile en SourceConstruct implementeren gegeneraliseerde mechanismen ter ondersteuning van het werken met bronbestanden en hun elementen, zoals het werken met tekstbuffers, het binden aan de coördinaten van een element in de brontekst, het afstemmen van het model op de huidige inhoud van de werkkopiebuffer, enz. Het implementeren van deze mechanismen is meestal een vrij complexe taak, en Handly kan de inspanning voor het ontwikkelen van op taalhandvatten gebaseerde modellen aanzienlijk verminderen door hoogwaardige basisimplementaties te bieden.
Naast de hierboven genoemde kernmechanismen biedt Handly een tekstbuffer en snapshot-infrastructuur, ondersteuning voor integratie met broncode-editors (inclusief kant-en-klare integratie met de Xtext-editor) en enkele veelgebruikte UI-componenten die werken met op Handly gebaseerde modellen, zoals het outline-framework. Het project biedt verschillende voorbeelden om de mogelijkheden te illustreren, waaronder een implementatie van het Java-model in Handly. (Vergeleken met de volledige implementatie van het Java-model in JDT is dit model met opzet enigszins vereenvoudigd voor de duidelijkheid.)
Zoals eerder opgemerkt, waren en blijven schaalbaarheid en flexibiliteit belangrijke aandachtspunten bij het oorspronkelijke ontwerp en de daaropvolgende ontwikkeling van Handly.
In principe schalen handle-gebaseerde modellen vrij goed "by design". De handle/body-idioom stelt je bijvoorbeeld in staat om de hoeveelheid geheugen die het model gebruikt te beperken. Maar er zijn nuances. Zo werd er bij het testen van Handly op schaalbaarheid een probleem gevonden in de implementatie van het notificatiemechanisme: bij het wijzigen van een groot aantal elementen duurde het bouwen van delta's te lang. Het bleek dat hetzelfde probleem zich voordeed in het JDT Java-model, waarvan de bijbehorende code ooit was aangepast. We hebben de fout in Handly verholpen en een vergelijkbare patch voor JDT voorbereid, die dankbaar werd aanvaard. Dit is slechts één voorbeeld van hoe de implementatie van Handly in bestaande modelimplementaties mogelijk nuttig kan zijn, omdat in dit geval een dergelijke fout slechts op één plek kan worden opgelost.
Om Handly technisch haalbaar te maken voor integratie in bestaande modelimplementaties, moet de bibliotheek zeer flexibel zijn. De grootste uitdaging is het handhaven van achterwaartse compatibiliteit binnen de model-API. Deze taak is opgelost in Door de modelspecifieke API, gedefinieerd en volledig beheerd door de ontwikkelaar, duidelijk te scheiden van de uniforme meta-level API die door de bibliotheek wordt geleverd. Dit maakt het niet alleen technisch mogelijk om Handly in bestaande implementaties te integreren, maar geeft de ontwikkelaar van een nieuw model ook aanzienlijke vrijheid in API-ontwerp.
Flexibiliteit heeft ook andere aspecten. Zo stelt Handly vrijwel geen beperkingen aan de modelstructuur en kan het worden gebruikt om zowel algemene als domeinspecifieke talen te modelleren. Bij het samenstellen van de structuur van het bronbestand schrijft Handly geen specifieke vorm van AST-representatie voor en vereist het in principe zelfs geen aanwezigheid van een AST, waardoor compatibiliteit met vrijwel elk syntactisch analysemechanisme is gegarandeerd. Ten slotte ondersteunt Handly volledige integratie met de Eclipse-werkruimte, maar kan het ook rechtstreeks met bestandssystemen werken dankzij de integratie met (EFS).
Huidige versie werd uitgebracht in december 2016. Ondanks het feit dat het project zich momenteel in een incubatiefase bevindt en de API nog niet definitief is vastgesteld, wordt Handly al gebruikt in twee grote commerciële producten die het risico hebben genomen om als "early adopters" op te treden, en, het moet gezegd worden, ze hebben daar nog steeds geen spijt van.
Zoals hierboven vermeld, is een van deze producten 1C:Enterprise Development Tools, waarbij Handly vanaf het begin is gebruikt om de elementen van de high-level structuur van 1C:Enterprise-talen zoals de ingebouwde programmeertaal en de querytaal te modelleren. Het andere product is minder bekend bij het grote publiek. , een geïntegreerde ontwerpomgeving voor applicatiespecifieke instructiesetprocessoren (ASIP), die zowel binnen het Tsjechische bedrijf Codasip zelf als door zijn klanten wordt gebruikt, waaronder , , , Codasip gebruikt Handly al sinds 2015 in productie, te beginnen met Handly 0.2. De nieuwste versie van Codasip Studio maakt gebruik van versie 0.5, uitgebracht in juni 2016. Ondřej Ilčík, die de IDE-ontwikkeling bij Codasip leidt, heeft contact gehad met het project en cruciale feedback gegeven als een "third-party adopter". Hij vond zelfs wat vrije tijd om rechtstreeks aan het project bij te dragen door de UI-laag (~4000 regels code) te implementeren voor een van de Handly-voorbeelden, een Java-model. Meer informatie uit de eerste hand over de implementatie van Handly is te vinden op de project.
We hopen dat Handly na de release van versie 1.0, met een garantie voor API-stabiliteit en het verlaten van de incubatiefase, nieuwe gebruikers zal vinden. In de tussentijd blijft het project de API testen en verder verbeteren, met twee "grote" releases per jaar - in juni (op dezelfde datum als de gelijktijdige release van Eclipse) en december, wat zorgt voor een voorspelbaar schema waarop gebruikers kunnen vertrouwen. Het project blijft bovendien een consistent laag "bugpercentage" en Handly werkt al sinds de allereerste versies betrouwbaar in de producten van early adopters. Voor meer informatie over Eclipse Handly kunt u terecht op и .
Bron: www.habr.com
