Eclipse als technologische Plattform für 1C:Enterprise Development Tools

Wahrscheinlich, Eclipse verliert es nie an Bedeutung. Viele kennen Eclipse durch die Eclipse Java Entwicklungstools (JDT). Diese beliebte Open-Source Java IDE wird von den meisten Entwicklern mit dem Begriff „Eclipse“ assoziiert. Aber Eclipse ist auch eine erweiterbare Plattform für die Integration von Entwicklungswerkzeugen (Eclipse Platform) und eine Vielzahl von IDEs, die auf ihr basieren, einschließlich JDT. Eclipse umfasst auch das Eclipse Project, ein übergeordnetes Projekt, das die Entwicklung der Eclipse Platform und JDT koordiniert, sowie das Eclipse SDK – das Ergebnis dieser Entwicklung. Schließlich ist Eclipse eine Open-Source-Stiftung mit einer riesigen Gemeinschaft von Projekten, von denen viele nicht in Java geschrieben sind oder mit Entwicklungswerkzeugen in Beziehung stehen (zum Beispiel die Projekte Eclipse IoT und Eclipse Science). Die Welt von Eclipse ist äußerst vielfältig.

In diesem Artikel, der als Übersicht konzipiert ist, werden wir versuchen, einige grundlegende Aspekte der Architektur von Eclipse als Plattform für integrierte Entwicklungswerkzeuge zu betrachten und eine erste Vorstellung von den Komponenten von Eclipse zu vermitteln, die die Basis der technologischen Plattform für den „neuen Konfigurator“ 1C:Enterprise bilden, 1C:Enterprise Development Tools. Natürlich wird diese Betrachtung zwangsläufig in vielerlei Hinsicht oberflächlich und recht eingeschränkt sein, insbesondere da wir uns nicht nur auf Eclipse-Entwickler als Zielgruppe konzentrieren. Dennoch hoffen wir, dass selbst erfahrene Eclipse-Entwickler interessante Informationen in diesem Artikel finden werden. Zum Beispiel werden wir über eines der "Geheimnisse von Eclipse" berichten, ein relativ neues und bisher wenig bekanntes Projekt. Eclipse Handly, das von der Firma 1C gegründet und unterstützt wird.

Einführung in die Architektur von Eclipse

Zunächst betrachten wir einige allgemeine Aspekte der Architektur von Eclipse am Beispiel Eclipse Java Development Tools (JDT). Die Wahl von JDT als Beispiel ist nicht zufällig. Es war die erste integrierte Entwicklungsumgebung, die in Eclipse erschienen ist. Die anderen *DT-Projekte von Eclipse, wie Eclipse C/C++ Development Tooling (CDT), wurden später erstellt und übernahmen sowohl die grundlegenden Architekturprinzipien als auch einzelne Codefragmente aus JDT. Die architektonischen Grundlagen, die in JDT gelegt wurden, sind bis heute für nahezu jede IDE relevant, die auf der Eclipse-Plattform basiert, einschließlich 1C:Enterprise Development Tools.

Zunächst ist zu beachten, dass Eclipse eine klar definierte architektonische Schichtung aufweist, die die sprachunabhängige Funktionalität von der für bestimmte Programmiersprachen vorgesehenen Funktionalität trennt und die UI-unabhängigen ‚Kern‘ (Core)-Komponenten von den Komponenten trennt, die für die Unterstützung der Benutzeroberfläche zuständig sind.

So definiert die Eclipse-Plattform die allgemeine, sprachunabhängige Infrastruktur, während die Java-Entwicklungstools Eclipse eine voll funktionsfähige Java-IDE hinzufügen. Sowohl die Eclipse-Plattform als auch JDT bestehen aus mehreren Komponenten, von denen jede entweder zum UI-unabhängigen ‚Kern‘ oder zur UI-Schicht gehört (siehe Abb. 1).

Abb. 1. Eclipse-Plattform und JDT

Die Hauptkomponenten der Eclipse-Plattform sind:

• Runtime — Definiert die Plugin-Infrastruktur. Eclipse zeichnet sich durch eine modulare Architektur aus. Im Wesentlichen ist Eclipse eine Sammlung von ‚Erweiterungspunkten‘ und ‚Erweiterungen‘.
• Workspace — Verwaltet ein oder mehrere Projekte. Ein Projekt besteht aus Ordnern und Dateien, die direkt im Dateisystem angezeigt werden.
• Standard Widget Toolkit (SWT) — Bietet grundlegende Elemente der Benutzeroberfläche, die mit dem Betriebssystem integriert sind.
• JFace — Stellt eine Reihe von UI-Frameworks zur Verfügung, die auf SWT basieren.
• Workbench — Definiert das UI-Paradigma von Eclipse: Editoren, Ansichten, Perspektiven.

Es ist wichtig zu erwähnen, dass die Eclipse Platform auch viele andere nützliche Komponenten für den Aufbau integrierter Entwicklungswerkzeuge bietet, darunter Debug, Compare, Search und Team. Besonders hervorzuheben ist JFace Text – die Grundlage für die Entwicklung von «intelligenten Editor» für Quellcode. Leider ist es in diesem Artikel nicht möglich, auch nur einen flüchtigen Überblick über diese Komponenten sowie die UI-Schicht zu geben, sodass wir im verbleibenden Teil dieses Abschnitts auf eine Übersicht der wichtigsten „Kern“-Komponenten der Eclipse Platform und JDT beschränkt bleiben.

Core Runtime

Die Plugin-Infrastruktur von Eclipse basiert auf OSGi und wird vom Projekt bereitgestellt Eclipse Equinox. Jedes Eclipse-Plugin ist ein OSGi-Bundle. Die OSGi-Spezifikation definiert unter anderem Mechanismen zur Versionierung und zur Auflösung von Abhängigkeiten. Neben diesen standardmäßigen Mechanismen führt Equinox das Konzept ein von Erweiterungspunkten. Jedes Plugin kann seine eigenen Erweiterungspunkte definieren und zusätzliche Funktionalität („Erweiterungen“) in das System einbringen, indem es die von diesem oder anderen Plugins definierten Erweiterungspunkte nutzt. Eine detaillierte Beschreibung der Mechanismen von OSGi und Equinox würde den Rahmen dieses Artikels sprengen. Es sei jedoch erwähnt, dass die Modularisierung in Eclipse umfassend ist (jedes Teilsystem, einschließlich Runtime, besteht aus einem oder mehreren Plugins) und nahezu alles in Eclipse erweiterbar ist. Diese Prinzipien wurden bereits lange vor der Einführung von OSGi in die Architektur von Eclipse eingebaut (damals kam eine eigene Technologie zum Einsatz, die in vielen Aspekten OSGi ähnlich war).

Kernarbeitsbereich

So gut wie jede integrierte Entwicklungsumgebung, die auf der Eclipse-Plattform basiert, arbeitet mit dem Eclipse-Arbeitsbereich. Dieser Arbeitsbereich enthält in der Regel den Quellcode der in der IDE entwickelten Anwendung. Der Arbeitsbereich spiegelt direkt das Dateisystem wider und besteht aus Projekten, die Ordner und Dateien enthalten. Diese Projekte, Ordner und Dateien werden genannt Ressourcen Der Workspace in Eclipse fungiert als Cache für das Dateisystem und beschleunigt so das Durchsuchen des Ressourcenbaums erheblich. Darüber hinaus bietet der Workspace eine Reihe zusätzlicher Dienste, darunter einen Benachrichtigungsmechanismus für Änderungen an Ressourcen und eine Infrastruktur für inkrementelle Builder.

Die Komponente Core Resources (Plugin org.eclipse.core.resources) ist für die Unterstützung des Workspaces und seiner Ressourcen zuständig. Insbesondere bietet diese Komponente programmgesteuerten Zugriff auf den Workspace in Form von Ressourcenmodellen. Um effektiv mit diesem Modell zu arbeiten, benötigen die Clients einen einfachen Weg, um auf die Ressource zuzugreifen. Dabei wäre es wünschenswert, dass das Objekt, das den Zustand der Ressource im Modell speichert, vom clientseitigen Zugriff verborgen bleibt. Andernfalls könnte der Client, beispielsweise bei der Löschung einer Datei, weiterhin auf ein Objekt zugreifen, das im Modell nicht mehr vorhanden ist, was zu Problemen führen würde. Eclipse löst dieses Problem mithilfe des sogenannten Handles Der Handle fungiert als Schlüssel (er kennt nur den Pfad zur Ressource im Workspace) und kontrolliert vollständig den Zugriff auf das innere Objekt des Modells, das die Informationen über den Zustand der Ressource speichert. Dieses Design ist eine Variation des Musters Handle/Body.

Abbildung 2 veranschaulicht die Handle/Body-Idee im Kontext von Ressourcenmodellen. Die Schnittstelle IResource repräsentiert den Handle der Ressource und stellt die API dar, im Gegensatz zur Klasse Resource, die dieses Interface implementiert, sowie zur Klasse ResourceInfo, die den Body repräsentiert und keine API darstellt. Es ist wichtig zu betonen, dass der Handle nur den Pfad zur Ressource relativ zum Wurzelverzeichnis des Workspaces kennt und keinen Verweis auf die Ressource-Informationen enthält. Die Objekte der Ressource-Informationen bilden sozusagen einen 'Elementbaum'. Diese Datenstruktur ist vollständig im Speicher materialisiert. Um die Instanz der Ressource-Informationen zu finden, die einem bestimmten Handle entspricht, wird der Elementbaum gemäß dem in diesem Handle gespeicherten Pfad durchsucht.

Abbildung 2. IResource und ResourceInfo

Wie wir später sehen werden, wird das grundlegende Design des Ressourcenmodells (man könnte es als handle-basiert bezeichnen) auch in Eclipse und für andere Modelle verwendet. Lassen Sie uns vorerst einige charakteristische Eigenschaften dieses Designs aufzählen:

• Handle ist ein Wertobjekt (Value Object). Wertobjekte sind unveränderliche Objekte, deren Gleichheit nicht auf Identität basiert. Solche Objekte können sicher als Schlüssel in gehashten Containern verwendet werden. Mehrere Instanzen von Handle können auf dasselbe Ressourcenobjekt verweisen. Zum Vergleichen dieser Objekte sollte die Methode equals(Object) verwendet werden.
• Handle definiert das Verhalten der Ressource, enthält jedoch keine Informationen über den Zustand der Ressource (die einzigen Daten, die es speichert, sind der „Schlüssel“, der Pfad zur Ressource).
• Handle kann auf eine nicht existierende Ressource verweisen (entweder auf eine Ressource, die noch nicht erstellt wurde, oder auf eine Ressource, die bereits gelöscht wurde). Die Existenz einer Ressource kann mit der Methode IResource.exists() überprüft werden.
• Einige Operationen können ausschließlich auf der Information beruhen, die im Handle selbst gespeichert ist (sogenannte Handle-only-Operationen). Beispiele hierfür sind IResource.getParent(), getFullPath() usw. Die Ressource muss nicht existieren, um eine solche Operation erfolgreich auszuführen. Operationen, für die erforderlich ist, dass die Ressource existiert, werfen eine Ausnahme (CoreException), wenn die Ressource nicht existiert.

Eclipse bietet einen effektiven Mechanismus zur Benachrichtigung über Veränderungen an Workspace-Ressourcen (siehe Abb. 3). Ressourcen können sowohl durch Aktionen innerhalb der Eclipse IDE als auch durch die Synchronisierung mit dem Dateisystem verändert werden. In beiden Fällen erhalten die Kunden, die sich für Benachrichtigungen angemeldet haben, detaillierte Informationen über die Änderungen in Form von 'Ressourcendeltas' (resource delta). Die Delta beschreibt die Änderungen zwischen zwei Zuständen des (Unter-)Baums der Workspace-Ressourcen und selbst ist sie ein Baum, wobei jeder Knoten eine Änderung einer bestimmten Ressource beschreibt und eine Liste von Deltas auf der nächsten Ebene enthält, die die Änderungen der untergeordneten Ressourcen darstellen.

Abb. 3. IResourceChangeEvent und IResourceDelta

Der auf Ressourcendeltas basierende Benachrichtigungsmechanismus weist folgende Merkmale auf:

• Einzelne Änderungen und mehrere Änderungen werden durch dieselbe Struktur beschrieben, da die Delta nach dem Prinzip der rekursiven Komposition aufgebaut ist. Abonnierende Kunden können Benachrichtigungen über Änderungen an Ressourcen durch rekursives Absteigen im Delta-Baum verarbeiten.
• Die Delta enthält umfassende Informationen über die Änderung der Ressource, einschließlich ihrer Verschiebung und/oder der Änderung der damit verbundenen "Marker" (beispielsweise werden Kompilierungsfehler als Marker dargestellt).
• Da auf die Ressource über einen Handle verwiesen wird, kann das Delta auf natürliche Weise auf die entfernte Ressource verweisen.

Wie wir bald sehen werden, sind die grundlegenden Bestandteile des Designs des Benachrichtigungsmechanismus für Änderungen im Ressourcenmodell auch für andere handle-basierte Modelle relevant.

JDT Core

Das Ressourcenmodell des Eclipse-Arbeitsbereichs ist ein grundlegendes, sprachunabhängiges Modell. Die JDT Core-Komponente (Plugin org.eclipse.jdt.core) bietet eine API zur Navigation und Analyse der Struktur des Arbeitsbereichs aus der Sicht von Java, das sogenannte "Java-Modell" (Java-Modell). Diese API wird in Bezug auf Java-Elemente definiert, im Gegensatz zur zugrunde liegenden API des Ressourcenmodells, die in Bezug auf Ordner und Dateien definiert ist. Die Hauptschnittstellen des Java-Elementbaums sind in Abb. 4 dargestellt.

Abb. 4. Elemente des Java-Modells

Das Java-Modell verwendet dasselbe Handle/Body-Muster wie das Ressourcenmodell (Abb. 5). IJavaElement fungiert als Handle, während JavaElementInfo den Body repräsentiert. Das Interface IJavaElement definiert ein Protokoll, das für alle Java-Elemente gültig ist. Einige seiner Methoden sind nur für Handle verfügbar: getElementName(), getParent() usw. Das Objekt JavaElementInfo speichert den Zustand des entsprechenden Elements: seine Struktur und Attribute.

Abb. 5. IJavaElement und JavaElementInfo

Das Java-Modell weist einige Unterschiede in der Implementierung des grundlegenden Handle/Body-Designs im Vergleich zum Ressourcenmodell auf. Wie bereits erwähnt, befindet sich im Ressourcenmodell der Elementbaum, dessen Knoten Objekte von Resource Info sind, vollständig im Speicher. Im Java-Modell können jedoch erheblich mehr Elemente enthalten sein als im Ressourcenbaum, da auch die interne Struktur von .java- und .class-Dateien dargestellt wird: Typen, Felder und Methoden.

Um die vollständige Materialisierung des gesamten Elementbaums im Speicher zu vermeiden, verwendet die Java-Modellimplementation einen begrenzten LRU-Cache für Elementinformationen, wobei der Schlüssel ein Handle von IJavaElement ist. Die Objekte der Elementinformationen werden auf Anfrage erstellt, während die Navigation im Elementbaum erfolgt. Dabei werden die am wenigsten häufig verwendeten Elemente aus dem Cache verdrängt, wodurch der Speicherverbrauch des Modells auf die festgelegte Cache-Größe begrenzt bleibt. Dies ist ein weiterer Vorteil des handle-basierten Designs, das solche Implementierungsdetails vollständig vom Client-Code verbirgt.

Der Benachrichtungsmechanismus für Änderungen an Java-Elementen ähnelt im Allgemeinen dem oben beschriebenen Mechanismus zur Verfolgung von Änderungen an Ressourcen im Arbeitsbereich. Ein Client, der Änderungen im Java-Modell verfolgen möchte, abonniert Benachrichtigungen, die in Form eines Objekts vom Typ ElementChangedEvent dargestellt werden, das ein IJavaElementDelta enthält (siehe Abb. 6).

Abb. 6. ElementChangedEvent und IJavaElementDelta

Das Java-Modell enthält keine Informationen über den Methodenkörper oder die Namensauflösung. Daher bietet JDT Core für eine detaillierte Analyse von Java-Code ein zusätzliches (nicht handle-basiertes) Modell an: abstrakter Syntaxbaum (abstract syntax tree, AST). Der AST stellt das Ergebnis der syntaktischen Analyse des Quelltextes dar. Die Knoten des AST entsprechen den Elementen der Struktur des Quellmoduls (Deklarationen, Operatoren, Ausdrücke usw.) und enthalten Informationen über die Position des entsprechenden Elements im Quelltext sowie optional Informationen zur Namensauflösung in Form von Verweisen auf sogenannte Bindings. Bindings sind Objekte, die benannte Entitäten wie Typen, Methoden und Variablen repräsentieren, die dem Compiler bekannt sind. Im Gegensatz zu den Knoten des AST, die einen Baum bilden, unterstützen Bindings Querverweise und bilden im Allgemeinen ein Graph. Die abstrakte Klasse ASTNode ist die gemeinsame Basisklasse für alle Knoten des AST. Die Unterklassen von ASTNode entsprechen bestimmten syntaktischen Konstruktionen der Programmiersprache Java.

Da syntaktische Bäume erhebliche Mengen an Speicher verbrauchen können, speichert JDT nur einen AST für den aktiven Editor im Cache. Im Gegensatz zum Java-Modell wird der AST normalerweise als 'zwischenzeitliches', 'temporäres' Modell betrachtet, auf dessen Elemente die Clients außerhalb des Kontexts der Operation, die zur Erstellung des AST geführt hat, keine Verweise halten sollten.

Die genannten drei Modelle (Java-Modell, AST, Bindings) bilden zusammen die Grundlage für die Entwicklung von „intelligenten Entwicklungswerkzeugen“ in JDT. Dazu gehören ein leistungsstarker Java-Editor mit verschiedenen „Hilfen“, Funktionen zur Verarbeitung von Quellcode (wie die Organisation der Importliste und das Formatieren gemäß dem festgelegten Stil), sowie Such- und Refactoring-Tools. Dabei spielt das Java-Modell eine besondere Rolle, da es als Grundlage für die visuelle Darstellung der Struktur der zu entwickelnden Anwendung dient (zum Beispiel im Package Explorer, Outline, Suche, Call Hierarchy und Type Hierarchy).

Eclipse-Komponenten, die in 1C:Enterprise Development Tools verwendet werden

In Abb. 7 sind die Eclipse-Komponenten dargestellt, die das Fundament der technologischen Plattform für die 1C:Enterprise Development Tools bilden.

Abb. 7. Eclipse als Plattform für die 1C:Enterprise Development Tools

Eclipse-Plattform stellt die grundlegende Infrastruktur bereit. Einige Aspekte dieser Infrastruktur haben wir im vorherigen Abschnitt behandelt.

Eclipse Modeling Framework (EMF) bietet allgemeine Mittel zur Modellierung strukturierter Daten. EMF ist in die Eclipse-Plattform integriert, kann aber auch eigenständig in regulären Java-Anwendungen verwendet werden. Häufig sind neue Eclipse-Entwickler bereits gut mit EMF vertraut, obwohl sie sich in den Feinheiten der Eclipse-Plattform noch nicht ganz auskennen. Ein Grund für diese wohlverdiente Popularität ist das universelle Design, das unter anderem eine einheitliche API auf Metaebene umfasst, die eine generische Arbeit mit jedem EMF-Modell ermöglicht. Die von EMF bereitgestellten Basisimplementierungen für Modellobjekte und das System zur Codegenerierung basierend auf der Metamodell erhöhen erheblich die Entwicklungsgeschwindigkeit und reduzieren die Anzahl der Fehler. Darüber hinaus enthält EMF Mechanismen zur Serialisierung von Modellen, zur Verfolgung von Änderungen im Modell und vieles mehr.

Wie jedes wirklich universelle Werkzeug eignet sich EMF zur Lösung einer Vielzahl von Modellierungsaufgaben, aber einige Klassen von Modellen (wie die oben beschriebenen handle-basierten Modelle) benötigen möglicherweise spezialisiertere Modellierungstools. Über EMF zu berichten, ist eine undankbare Aufgabe, insbesondere im begrenzten Rahmen eines Artikels, da es sich um ein Thema für ein eigenes, recht umfangreiches Buch handelt. Es sei nur erwähnt, dass das qualitativ hochwertige System der Verallgemeinerungen, das dem EMF zugrunde liegt, die Entstehung einer ganzen Reihe von Modellen ermöglicht hat, die in ein übergeordnetes Projekt zur Modellierung eingehen. Eclipse Modeling neben EMF selbst. Eines dieser Projekte ist Eclipse Xtext.

Eclipse Xtext bietet eine Infrastruktur für das 'Textmodellieren'. Xtext verwendet ANTLR Für die syntaktische Analyse des Quelltexts und EMF zur Darstellung des resultierenden ASG (Abstract Semantic Graph, der im Wesentlichen eine Kombination aus AST und Bindungen ist), auch als "semantisches Modell" bezeichnet. Die Grammatik des mit Xtext modellierten Sprachs wird in einer eigenen Xtext-Sprache beschrieben. Dies ermöglicht nicht nur die Generierung einer Grammatikbeschreibung für ANTLR, sondern auch den Erhalt eines Mechanismus zur Serialisierung des AST (d.h. Xtext bietet sowohl einen Parser als auch einen Unparser), kontextbezogene Hinweise und eine Reihe weiterer sprachlicher Komponenten. Andererseits ist die in Xtext verwendete Grammatikbeschreibungssprache weniger flexibel im Vergleich zu der Grammatikbeschreibungssprache in ANTLR. Daher muss man manchmal die zu implementierende Sprache an Xtext anpassen, was normalerweise kein Problem darstellt, wenn es sich um eine vollständig neu entwickelte Sprache handelt, aber für Sprachen mit bereits etabliertem Syntax unpraktisch sein kann. Trotz dieser Einschränkungen ist Xtext derzeit das reifste, funktional vollständigste und vielseitigste Tool in Eclipse zur Erstellung von Programmiersprachen und den dazugehörigen Entwicklungstools. Insbesondere ist es ein ideales Werkzeug für schnelles Prototyping. domänenspezifische Sprachen (Domain Specific Language, DSL). Neben dem erwähnten „Sprachkern“ auf Basis von ANTLR und EMF bietet Xtext eine Vielzahl nützlicher Funktionen auf höherer Ebene, einschließlich Indexierungsmechanismen, inkrementellem Build, „intelligentem Editor“ und vieles mehr, lässt jedoch sprachliche handle-basierte Modelle außen vor. Wie EMF ist auch Xtext ein Thema für ein eigenes Buch, und wir werden wahrscheinlich selbst nicht in der Lage sein, jetzt auch nur kurz auf alle seine Möglichkeiten einzugehen.

Die 1C:Enterprise Development Tools nutzen sowohl EMF selbst als auch eine Reihe anderer Projekte von Eclipse Modeling aktiv. Insbesondere ist Xtext eines der wichtigsten Werkzeuge für die Entwicklung von 1C:Enterprise-Sprachen, wie der eingebetteten Programmiersprache und der Abfragesprache. Eine weitere Basis dieser Entwicklungswerkzeuge ist das Projekt Eclipse Handly, auf das wir näher eingehen werden (unter den genannten Komponenten von Eclipse ist es bislang am wenigsten bekannt).

Eclipse Handly, ein Teilprojekt des übergeordneten Projekts Eclipse Technology, entstand durch den initialen Codebeitrag von 1C an die Eclipse Foundation im Jahr 2014. Seitdem unterstützt die Firma 1C die Weiterentwicklung des Projekts weiterhin: Die Committer von Handly sind Mitarbeiter des Unternehmens. Das Projekt ist klein, besetzt jedoch eine ausreichend einzigartige Nische in Eclipse: Das Hauptziel ist die Unterstützung der Entwicklung von handle-basierten Modellen.

Die grundlegenden architektonischen Prinzipien handle-basierter Modelle, wie die Handle/Body-Idiomatik, wurden oben am Beispiel des Ressourcenmodells und des Java-Modells behandelt. Es wurde ebenfalls festgestellt, dass sowohl das Ressourcenmodell als auch das Java-Modell wichtige Grundlagen für die Eclipse Java Development Tools (JDT) darstellen. Da praktisch alle *DT-Projekte von Eclipse eine Architektur ähnlich der von JDT aufweisen, ist es keine Übertreibung zu sagen, dass handle-basierte Modelle der Grundstein für viele, wenn nicht sogar alle IDEs sind, die auf der Eclipse-Plattform basieren. Zum Beispiel gibt es im Eclipse C/C++ Development Tooling (CDT) ein handle-basiertes Modell für C/C++, das in der Architektur von CDT die gleiche Rolle spielt wie das Java-Modell in JDT.

Bis zur Einführung von Handly bot Eclipse keine spezialisierten Bibliotheken zum Erstellen von handle-basierten Sprachmodellen an. Die bestehenden Modelle wurden hauptsächlich durch direkte Anpassung des Java-Modellcodes entwickelt (a.k.a. Copy/Paste). in den Fällen, in denen dies möglich ist Eclipse Public License (EPL). (Es versteht sich von selbst, dass dies für Projekte von Eclipse normalerweise rechtlich kein Problem darstellt, was jedoch nicht für Produkte mit proprietärem Code gilt.) Abgesehen von der typischen Unsystematik dieser Methode führt sie zu bekannten Problemen: zur Duplizierung von Code, zu Fehlern, die bei der Anpassung auftreten, und ähnlichem. Noch schlimmer ist, dass die resultierenden Modelle 'eine Sache für sich' bleiben und das vorhandene Potenzial zur Vereinheitlichung nicht nutzen. Es wäre jedoch möglich, durch die Identifizierung gemeinsamer Konzepte und Protokolle für handle-basierte Sprachmodelle wiederverwendbare Komponenten zu schaffen, ähnlich wie es bei EMF der Fall war.

Man kann nicht sagen, dass es in Eclipse kein Bewusstsein für diese Probleme gegeben hätte. Schon 2005 Martin Aeschlimann, der die Erfahrungen bei der Entwicklung des CDT-Prototyps zusammenfasste, argumentierte Die Notwendigkeit, eine gemeinsame Infrastruktur für Sprachmodelle, einschließlich handle-basierter Modelle, zu schaffen. Doch wie so oft blieben diese Ideen aufgrund vorrangiger Aufgaben unerledigt. Inzwischen bleibt die Faktorisierung des Codes von *DT-Projekten ein nach wie vor unzureichend bearbeitetes Thema in Eclipse.

In gewissem Sinne soll das Handly-Projekt ähnliche Aufgaben wie EMF lösen, jedoch für handle-basierte Modelle, insbesondere Sprachmodelle (d.h. Modelle, die Elemente der Struktur einer Programmiersprache repräsentieren). Im Folgenden sind die Hauptziele aufgelistet, die bei der Gestaltung von Handly verfolgt wurden:

• Herausarbeitung der grundlegenden Abstraktionen des Fachgebiets.
• Reduzierung des Aufwands und Verbesserung der Qualität der Implementierung von sprachlichen handle-basierten Modellen durch Wiederverwendung von Code.
• Bereitstellung einer einheitlichen API auf Meta-Ebene für die resultierenden Modelle, die die Erstellung gemeinsamer IDE-Komponenten ermöglicht, die mit sprachlichen handle-basierten Modellen arbeiten.
• Flexibilität und Skalierbarkeit.
• Integration mit Xtext (in einer separaten Schicht).

Zur Identifizierung allgemeiner Konzepte und Protokolle wurden bestehende Implementierungen von handle-basierten Modellen analysiert. Die grundlegenden Schnittstellen und Basisimplementierungen, die von Handly bereitgestellt werden, sind in Abb. 8 dargestellt.

Abb. 8. Allgemeine Schnittstellen und Basisimplementierungen der Handly-Elemente

Das IElement-Interface repräsentiert den Handle eines Elements und ist allgemeingültig für alle Elemente von Modellen, die auf Handly basieren. Die abstrakte Klasse Element implementiert den generischen Handle/Body-Mechanismus (Abb. 9).

Abb. 9. IElement und generische Implementierung von Handle/Body

Darüber hinaus bietet Handly einen generischen Mechanismus zur Benachrichtigung über Änderungen an den Modellen (Abb. 10). Wie zu sehen ist, ähnelt er im Großen und Ganzen den Benachrichtigungsmechanismen, die in der Ressourcenmodellierung und der Java-Modellierung implementiert sind, und verwendet IElementDelta für eine einheitliche Darstellung von Änderungsinformationen über Elemente.

Abb. 10. Allgemeine Schnittstellen und Basisimplementierungen des Handly-Benachrichtigungsmechanismus

Der oben behandelte Teil von Handly (Abb. 9 und 10) kann zur Darstellung nahezu beliebiger handle-basierter Modelle verwendet werden. Zur Erstellung sprachlicher Das Projektmodell bietet zusätzliche Funktionen – insbesondere allgemeine Schnittstellen und grundlegende Implementierungen für Elemente der Struktur des ursprünglichen Textes, auch bekannt als Quellelemente (Abb. 8). Die Schnittstelle ISourceFile repräsentiert die Quelldatei, während ISourceConstruct – ein Element innerhalb der Quelldatei ist. Die abstrakten Klassen SourceFile und SourceConstruct implementieren verallgemeinerte Mechanismen zur Unterstützung der Arbeit mit Quelldateien und deren Elementen, beispielsweise die Arbeit mit Textpuffern, die Bindung an die Koordinaten des Elements im ursprünglichen Text, die Abstimmung der Modelle mit dem aktuellen Inhalt des Arbeitskopie-Puffers usw. Die Implementierung dieser Mechanismen ist in der Regel eine anspruchsvolle Aufgabe, und Handly kann den Entwicklungsaufwand für sprachliche, handle-basierte Modelle erheblich reduzieren, indem es qualitativ hochwertige Grundimplementierungen bereitstellt.

Neben den oben genannten grundlegenden Mechanismen bietet Handly eine Infrastruktur für Textpuffer und Snapshots, unterstützt die Integration mit Quellcode-Editoren (einschließlich der direkt verfügbaren Integration mit dem Xtext-Editor) und enthält einige allgemeine UI-Komponenten, die mit Handly-basierten Modellen arbeiten, wie beispielsweise das Outline-Framework. Zur Veranschaulichung seiner Möglichkeiten stellt das Projekt mehrere Beispiele bereit, darunter auch die Implementierung eines Java-Modells auf Handly. (Im Vergleich zur vollständigen Implementierung des Java-Modells in JDT ist dieses Modell absichtlich etwas vereinfacht, um die Anschaulichkeit zu erhöhen.)

Wie bereits erwähnt, wurde beim anfänglichen Design von Handly und dessen fortlaufender Entwicklung ein ernsthaftes Augenmerk auf Skalierbarkeit und Flexibilität gelegt und wird dies auch weiterhin getan.

Im Grunde genommen skalieren handle-basierte Modelle aufgrund ihres Designs recht gut. Beispielsweise ermöglicht die Idiomatik von Handle/Body eine Begrenzung des von dem Modell verbrauchten Speichers. Allerdings gibt es einige Feinheiten. Bei Testungen von Handly hinsichtlich der Skalierbarkeit wurde ein Problem in der Implementierung des Benachrichtigungsmechanismus festgestellt – bei der Änderung einer großen Anzahl von Elementen benötigte der Delta-Bau zu viel Zeit. Es stellte sich heraus, dass dasselbe Problem auch im Java-Modell JDT vorhanden war, aus dem der entsprechende Code einst adaptiert wurde. Wir haben den Fehler in Handly behoben und einen ähnlichen Patch für JDT vorbereitet, der dankend angenommen wurde. Dies ist nur ein Beispiel, wie die Integration von Handly in bestehende Modellimplementierungen potenziell nützlich sein könnte, da in diesem Fall der Fehler nur an einer Stelle behoben werden könnte.

Um die Integration von Handly in bestehende Modellimplementierungen technisch zu ermöglichen, muss die Bibliothek über erhebliche Flexibilität verfügen. Das Hauptproblem besteht darin, die Abwärtskompatibilität des API-Modells zu wahren. Diese Herausforderung wurde gelöst in Handly 0.5 durch die klare Trennung der modell-spezifischen API, die vom Entwickler definiert und vollständig kontrolliert wird, vom einheitlichen Meta-Level-API, das von der Bibliothek bereitgestellt wird. Dies ermöglicht nicht nur die technische Integration von Handly in bestehende Implementierungen, sondern gibt auch dem Entwickler des neuen Modells erhebliche Freiheit bei der API-Gestaltung.

Flexibilität hat auch andere Aspekte. Handly legt beispielsweise kaum Einschränkungen an die Modellstruktur und kann sowohl für die Modellierung von allgemeinen Programmiersprachen als auch von domänenspezifischen Sprachen verwendet werden. Beim Aufbau der Struktur der Quelldatei gibt Handly keine bestimmte Form der AST-Darstellung vor und erfordert grundsätzlich nicht einmal das Vorhandensein eines AST, was die Kompatibilität mit praktisch allen Parsing-Mechanismen gewährleistet. Schließlich unterstützt Handly eine umfassende Integration mit dem Eclipse-Arbeitsbereich, kann jedoch auch direkt mit Dateisystemen arbeiten, dank der Integration mit Eclipse File System (EFS).

Aktuelle Version Handly 0.6 wurde im Dezember 2016 veröffentlicht. Obwohl sich das Projekt derzeit in der Inkubationsphase befindet und die API noch nicht endgültig festgelegt ist, wird Handly bereits in zwei großen kommerziellen Produkten eingesetzt, die den Mut hatten, als "frühe Anwender" aufzutreten, und bis jetzt keine Bedenken geäußert haben.

Wie bereits erwähnt, ist eines dieser Produkte – 1C:Enterprise Development Tools, wo Handly von Anfang an zur Modellierung von Elementen der hochrangigen Struktur von Sprachen wie 1C:Enterprise verwendet wird, einschließlich der integrierten Programmiersprache und der Abfragesprache. Ein anderes Produkt ist der breiten Öffentlichkeit weniger bekannt. Es handelt sich um Codasip Studio, eine integrierte Entwicklungsumgebung für die Gestaltung anwendungsspezifischer Prozessoren (application-specific instruction-set processor, ASIP), die sowohl innerhalb des tschechischen Unternehmens Codasip als auch von dessen Kunden genutzt wird, darunter AMD, DURCHSCHNITT, Mobileye, Sigma Designs. Codasip nutzt Handly seit 2015 in der Produktion, beginnend mit der Version Handly 0.2. Die aktuellste Version von Codasip Studio verwendet die Version 0.5, die im Juni 2016 veröffentlicht wurde. Ondřej Ilčík, der die IDE-Entwicklung bei Codasip leitet, steht in Kontakt mit dem Projekt und liefert äußerst wichtiges Feedback seitens des „externen Adopters“. Er fand sogar etwas Zeit, um aktiv an der Entwicklung des Projekts teilzunehmen, indem er eine UI-Schicht (~ 4000 Zeilen Code) für eines der Handly-Beispiele, das Java-Modell, implementierte. Weitere Informationen „aus erster Hand“ über die Nutzung von Handly durch Adopter finden Sie auf der Seite Erfolgsgeschichten des Projekts bekanntgaben.

Wir sind zuversichtlich, dass nach der Veröffentlichung der Version 1.0 mit der Garantierung der Stabilität der API und dem Abschluss des Projekts aus dem Inkubationsstatus Handly neue Adapter gewinnen wird. Das Projekt befindet sich weiterhin in der Erprobung und der kontinuierlichen Verbesserung der API und veröffentlicht zweimal jährlich zwei „große“ Releases – im Juni (am gleichen Tag, an dem Eclipse ebenfalls veröffentlicht wird) und im Dezember. Damit wird ein vorhersehbarer Zeitplan gewährleistet, auf den die Adapter zählen können. Zusätzlich lässt sich sagen, dass die Fehlerquote des Projekts auf einem stabil niedrigen Niveau bleibt und Handly seit den ersten Versionen zuverlässig in Produkten von Frühadoptern funktioniert. Für weitere Einblicke in Eclipse Handly können Sie verwenden Einsteiger-Tutorial und Architekturübersicht.

Quelle: habr.com