Probablement, n’a depuis longtemps eu besoin d’aucune introduction particulière. De nombreuses personnes connaissent Eclipse grâce aux outils de développement Eclipse Java (). C'est cet IDE Java open source populaire que la plupart des développeurs associent au mot « Eclipse ». Cependant, Eclipse est à la fois une plateforme extensible d'intégration d'outils de développement (Eclipse Platform) et un certain nombre d'IDE construits sur cette base, dont JDT. Eclipse est à la fois le projet Eclipse, le projet de niveau supérieur qui coordonne le développement de la plateforme Eclipse et du JDT, et le SDK Eclipse, le résultat de ce développement. Enfin, Eclipse est une fondation open source avec une énorme communauté de projets, qui ne sont pas tous écrits en Java ou liés à des outils de développement (par exemple, des projets и ). Le monde d'Eclipse est très diversifié.
Dans cet article, qui est de nature générale, nous essaierons d'examiner certaines des bases de l'architecture Eclipse en tant que plate-forme de création d'outils de développement intégrés et donnerons une première idée des composants Eclipse qui constituent le fondement de la technologie. plateforme pour le « nouveau Configurateur » 1C : Entreprise. . Bien entendu, un tel examen sera inévitablement largement superficiel et plutôt limité, notamment parce que nous ne nous concentrons pas uniquement sur les développeurs Eclipse en tant que public cible. Cependant, nous espérons que même les développeurs Eclipse expérimentés pourront trouver des informations intéressantes dans l'article. Par exemple, nous parlerons d'un des « secrets d'Eclipse », un projet relativement nouveau et peu connu , qui a été fondé et soutenu par 1C.
Introduction à l'architecture Eclipse
Examinons d'abord quelques aspects généraux de l'architecture Eclipse à l'aide de l'exemple (JDT). Le choix de JDT comme exemple n’est pas accidentel. Il s'agit du premier environnement de développement intégré à apparaître dans Eclipse. D'autres projets *DT Eclipse, tels que les outils de développement Eclipse C/C++ (CDT), ont été créés plus tard et empruntent à la fois les principes architecturaux de base et les fragments de code source individuels de JDT. Les principes fondamentaux de l'architecture définis dans JDT sont pertinents à ce jour pour presque tous les IDE construits sur la plate-forme Eclipse, y compris 1C:Enterprise Development Tools.
Tout d'abord, il convient de noter qu'Eclipse se caractérise par une stratification architecturale assez claire, avec la séparation des fonctionnalités indépendantes du langage des fonctionnalités conçues pour prendre en charge des langages de programmation spécifiques, et la séparation des composants « centraux » indépendants de l'interface utilisateur des composants associés. avec interface utilisateur prise en charge.
Ainsi, la plate-forme Eclipse définit une infrastructure commune indépendante du langage, et les outils de développement Java ajoutent un IDE Java complet à Eclipse. La plate-forme Eclipse et le JDT se composent de plusieurs composants, chacun appartenant soit à un « noyau » indépendant de l'interface utilisateur, soit à une couche d'interface utilisateur (Figure 1).
Riz. 1. Plateforme Eclipse et JDT
Listons les principaux composants de la plateforme Eclipse :
- Runtime — Définit l'infrastructure du plugin. Eclipse se caractérise par une architecture modulaire. Essentiellement, Eclipse est une collection de « points d'extension » et d'« extensions ».
- Espace de travail — Gère un ou plusieurs projets. Un projet se compose de dossiers et de fichiers mappés directement sur le système de fichiers.
- Boîte à outils de widgets standard (SWT) - Fournit des éléments d'interface utilisateur de base intégrés au système d'exploitation.
- JFace — Fournit un certain nombre de frameworks d'interface utilisateur construits sur SWT.
- Workbench — Définit le paradigme de l'interface utilisateur Eclipse : éditeurs, vues, perspectives.
Il faut dire que la plateforme Eclipse fournit également de nombreux autres composants utiles pour créer des outils de développement intégrés, notamment Debug, Compare, Search et Team. Une mention spéciale doit être faite à JFace Text - la base pour créer des « éditeurs intelligents » de code source. Malheureusement, même un examen superficiel de ces composants, ainsi que des composants de la couche UI, n'est pas possible dans le cadre de cet article. Dans le reste de cette section, nous nous limiterons donc à un aperçu des principaux composants « centraux » de la plateforme Eclipse et JDT.
Runtime de base
L'infrastructure du plugin Eclipse est basée sur et fourni par le projet . Chaque plugin Eclipse est un bundle OSGi. La spécification OSGi définit notamment des mécanismes de versioning et de résolution des dépendances. En plus de ces mécanismes standards, Equinox introduit le concept points d'expansion. Chaque plugin peut définir ses propres points d'extension, et également introduire des fonctionnalités supplémentaires (« extensions ») au système en utilisant des points d'extension définis par le même plugin ou par d'autres plugins. Toute description détaillée des mécanismes OSGi et Equinox dépasse le cadre de cet article. Notons seulement que la modularisation dans Eclipse est totale (tout sous-système, y compris le Runtime, est constitué d'un ou plusieurs plugins), et presque tout dans Eclipse est une extension. De plus, ces principes étaient intégrés dans l'architecture Eclipse bien avant l'introduction d'OSGi (à cette époque, ils utilisaient leur propre technologie, très similaire à OSGi).
Espace de travail principal
Presque tous les environnements de développement intégrés construits sur la plate-forme Eclipse fonctionnent avec l'espace de travail Eclipse. C'est l'espace de travail qui contient généralement le code source de l'application développée dans l'EDI. L'espace de travail correspond directement au système de fichiers et se compose de projets contenant des dossiers et des fichiers. Ces projets, dossiers et fichiers sont appelés les ressources espace de travail. L'implémentation de l'espace de travail dans Eclipse sert de cache par rapport au système de fichiers, ce qui permet d'accélérer considérablement la traversée de l'arborescence des ressources. De plus, Workspace fournit un certain nombre de services supplémentaires, notamment и .
Le composant Core Resources (plugin org.eclipse.core.resources) est responsable de la prise en charge de l'espace de travail et de ses ressources. En particulier, ce composant fournit un accès programmatique à l'espace de travail sous la forme modèles de ressources. Pour travailler efficacement avec ce modèle, les clients ont besoin d'un moyen simple de présenter un lien vers une ressource. Dans ce cas, il serait souhaitable de masquer à l'accès client l'objet qui stocke directement l'état de la ressource dans le modèle. Dans le cas contraire, dans le cas par exemple de la suppression d'un fichier, le client pourrait continuer à détenir un objet qui n'est plus dans le modèle, avec les problèmes qui en découlent. Eclipse résout ce problème en utilisant quelque chose appelé manipuler Ressource. Handle agit comme une clé (il ne connaît que le chemin d'accès à la ressource dans l'espace de travail) et contrôle complètement l'accès à l'objet de modèle interne, qui stocke directement les informations sur l'état de la ressource. Cette conception est une variation du modèle .
Riz. La figure 2 illustre l'idiome Handle/Body tel qu'appliqué au modèle de ressource. L'interface IResource représente le handle d'une ressource et est une API, contrairement à la classe Resource, qui implémente cette interface, et à la classe ResourceInfo, qui représente le corps, qui ne sont pas des API. Nous soulignons que handle ne connaît que le chemin d'accès à la ressource par rapport à la racine de l'espace de travail et ne contient pas de lien vers les informations sur la ressource. Les objets d'information sur les ressources forment ce que l'on appelle une « arborescence d'éléments ». Cette structure de données est entièrement matérialisée en mémoire. Pour trouver l'instance d'informations sur la ressource correspondant à un handle, l'arborescence des éléments est parcourue en fonction du chemin stocké dans ce handle.
Riz. 2. IResource et ResourceInfo
Comme nous le verrons plus tard, la conception de base du modèle de ressource (nous pourrions l'appeler basée sur les handles) est également utilisée dans Eclipse pour d'autres modèles. Pour l’instant, énumérons quelques-unes des propriétés distinctives de cette conception :
- Handle est un objet de valeur. Les objets de valeur sont des objets immuables dont l'égalité n'est pas basée sur l'identité. De tels objets peuvent être utilisés en toute sécurité comme clé dans des conteneurs hachés. Plusieurs instances de handle peuvent référencer la même ressource. Pour les comparer, vous devez utiliser la méthode equals(Object).
- Handle définit le comportement d'une ressource, mais ne contient pas d'informations sur l'état de la ressource (les seules données qu'il stocke sont la "clé", le chemin d'accès à la ressource).
- Handle peut faire référence à une ressource qui n’existe pas (soit une ressource qui n’a pas encore été créée, soit une ressource qui a déjà été supprimée). L'existence d'une ressource peut être vérifiée à l'aide de la méthode IResource.exists().
- Certaines opérations peuvent être mises en œuvre uniquement sur la base des informations stockées dans le handle lui-même (opérations dites de handle-only). Les exemples sont IResource.getParent(), getFullPath(), etc. Il n’est pas nécessaire que la ressource existe pour qu’une telle opération réussisse. Les opérations qui nécessitent l’existence d’une ressource pour réussir lèvent une CoreException si la ressource n’existe pas.
Eclipse fournit un mécanisme efficace pour notifier les modifications des ressources de l'espace de travail (Figure 3). Les ressources peuvent changer soit à la suite d'actions effectuées dans l'EDI Eclipse lui-même, soit à la suite d'une synchronisation avec le système de fichiers. Dans les deux cas, les clients qui s'abonnent aux notifications reçoivent des informations détaillées sur les modifications sous la forme de « deltas de ressources ». Un delta décrit les changements entre deux états d'une (sous-)arborescence de ressources d'espace de travail et est lui-même une arborescence dont chaque nœud décrit une modification apportée à une ressource et contient une liste de deltas au niveau suivant qui décrivent les modifications apportées aux ressources enfants.
Riz. 3. IResourceChangeEvent et IResourceDelta
Le mécanisme de notification basé sur les deltas de ressources présente les caractéristiques suivantes :
- Un seul changement et plusieurs changements sont décrits en utilisant la même structure, puisque le delta est construit selon le principe de composition récursive. Les clients abonnés peuvent traiter les notifications de modification de ressources en utilisant une descente récursive à travers une arborescence de deltas.
- Le delta contient des informations complètes sur les modifications apportées à la ressource, y compris son mouvement et/ou les modifications des « marqueurs » qui lui sont associés (par exemple, les erreurs de compilation sont représentées sous forme de marqueurs).
- Étant donné que les références aux ressources sont effectuées via le handle, delta peut naturellement référencer une ressource distante.
Comme nous le verrons bientôt, les principaux composants de la conception du mécanisme de notification de changement de modèle de ressources sont également pertinents pour d'autres modèles basés sur des handles.
Noyau JDT
Le modèle de ressources de l'espace de travail Eclipse est un modèle fondamental indépendant du langage. Le composant JDT Core (plugin org.eclipse.jdt.core) fournit une API pour naviguer et analyser la structure de l'espace de travail d'un point de vue Java, ce que l'on appelle le « modèle Java » (Modèle Java). Cette API est définie en termes d'éléments Java, par opposition à l'API du modèle de ressources sous-jacente, qui est définie en termes de dossiers et de fichiers. Les principales interfaces de l'arborescence des éléments Java sont présentées dans la Fig. 4.
Riz. 4. Éléments du modèle Java
Le modèle Java utilise le même idiome handle/body que le modèle de ressource (Figure 5). IJavaElement est le handle et JavaElementInfo joue le rôle de corps. L'interface IJavaElement définit un protocole commun à tous les éléments Java. Certaines de ses méthodes sont uniquement de type handle : getElementName(), getParent(), etc. L'objet JavaElementInfo stocke l'état de l'élément correspondant : sa structure et ses attributs.
Riz. 5. IJavaElement et JavaElementInfo
Le modèle Java présente quelques différences dans l'implémentation de la conception de base du manche/corps par rapport au modèle de ressource. Comme indiqué ci-dessus, dans le modèle de ressources, l'arborescence des éléments, dont les nœuds sont des objets d'informations sur les ressources, est entièrement contenue en mémoire. Mais le modèle Java peut contenir un nombre d'éléments nettement plus important que l'arborescence des ressources, car il représente également la structure interne des fichiers .java et .class : types, champs et méthodes.
Pour éviter de matérialiser complètement l'intégralité de l'arborescence des éléments en mémoire, l'implémentation du modèle Java utilise un cache LRU d'informations sur les éléments de taille limitée, où la clé est le handle IJavaElement. Les objets d'information sur les éléments sont créés à la demande au fur et à mesure de la navigation dans l'arborescence des éléments. Dans ce cas, les éléments les moins fréquemment utilisés sont évincés du cache et la consommation mémoire du modèle reste limitée à la taille du cache spécifiée. Il s'agit d'un autre avantage de la conception basée sur les handles, qui masque complètement ces détails d'implémentation du code client.
Le mécanisme de notification des modifications apportées aux éléments Java est en général similaire au mécanisme de suivi des modifications apportées aux ressources de l'espace de travail évoqué ci-dessus. Un client souhaitant surveiller les modifications dans le modèle Java s'abonne aux notifications, qui sont représentées sous la forme d'un objet ElementChangedEvent contenant un IJavaElementDelta (Figure 6).
Riz. 6. ElementChangedEvent et IJavaElementDelta
Le modèle Java ne contient pas d'informations sur les corps de méthode ou la résolution de noms. Par conséquent, pour une analyse détaillée du code écrit en Java, JDT Core fournit un modèle supplémentaire (non basé sur des handles) : (arbre de syntaxe abstraite, AST). AST représente le résultat de l'analyse du texte source. Les nœuds AST correspondent à des éléments de la structure du module source (déclarations, opérateurs, expressions, etc.) et contiennent des informations sur les coordonnées de l'élément correspondant dans le texte source, ainsi que (en option) des informations sur la résolution de nom dans la forme de liens vers ce qu'on appelle fixations. Les liaisons sont des objets qui représentent des entités nommées, telles que des types, des méthodes et des variables, connues du compilateur. Contrairement aux nœuds AST, qui forment une arborescence, les liaisons prennent en charge les références croisées et forment généralement un graphique. La classe abstraite ASTNode est la classe de base commune à tous les nœuds AST. Les sous-classes ASTNode correspondent à des constructions syntaxiques spécifiques du langage Java.
Étant donné que les arbres de syntaxe peuvent consommer une quantité importante de mémoire, JDT ne met en cache qu'un seul AST pour l'éditeur actif. Contrairement au modèle Java, l'AST est généralement considéré comme un modèle « intermédiaire », « temporaire » dont les membres ne doivent pas être référencés par les clients en dehors du contexte de l'opération qui a conduit à la création de l'AST.
Les trois modèles répertoriés (modèle Java, AST, liaisons) forment ensemble la base pour créer des « outils de développement intelligents » dans JDT, y compris un puissant éditeur Java avec divers « assistants », diverses actions pour traiter le code source (y compris l'organisation d'une liste d'importation noms et mise en forme selon le style personnalisé), outils de recherche et de refactoring. Dans ce cas, le modèle Java joue un rôle particulier, puisque c'est lui qui sert de base à une représentation visuelle de la structure de l'application en cours de développement (par exemple, dans l'Explorateur de packages, Outline, Search, Call Hierarchy et Tapez Hiérarchie).
Composants Eclipse utilisés dans 1C:Enterprise Developments Tools
En figue. La figure 7 montre les composants Eclipse qui constituent la base de la plate-forme technologique pour 1C:Enterprise Development Tools.
Riz. 7. Eclipse en tant que plate-forme pour 1C : outils de développement d'entreprise
Plateforme Eclipse fournit une infrastructure de base. Nous avons examiné certains aspects de cette infrastructure dans la section précédente.
(EMF) fournit un moyen général de modélisation de données structurées. EMF est intégré à la plateforme Eclipse, mais peut également être utilisé séparément dans les applications Java classiques. Très souvent, les nouveaux développeurs Eclipse connaissent déjà bien EMF, même s'ils ne comprennent pas encore pleinement les subtilités de la plate-forme Eclipse. L'une des raisons d'une telle popularité bien méritée est la conception universelle, qui comprend, entre autres, une API unifiée de méta-niveau, qui vous permet de travailler avec n'importe quel modèle EMF de manière générale. Les implémentations de base pour les objets de modèle fournies par EMF et le sous-système de génération de code de modèle basé sur le méta-modèle augmentent considérablement la vitesse de développement et réduisent le nombre d'erreurs. EMF contient également des mécanismes pour sérialiser les modèles, suivre les modifications apportées au modèle et bien plus encore.
Comme tout outil véritablement généraliste, EMF convient à la résolution d'un large éventail de problèmes de modélisation, mais certaines classes de modèles (par exemple, les modèles basés sur des poignées évoqués ci-dessus) peuvent nécessiter des outils de modélisation plus spécialisés. Parler des champs électromagnétiques est une tâche ingrate, surtout dans les limites d'un seul article, puisqu'il s'agit du sujet d'un livre séparé, et plutôt épais. Notons seulement que le système de généralisations de haute qualité qui sous-tend l'EMF a permis la naissance de toute une gamme de projets dédiés à la modélisation, qui sont inclus dans le projet de haut niveau avec le FEM lui-même. L'un de ces projets est Eclipse Xtext.
fournit une infrastructure de « modélisation de texte ». Utilisations de Xtext pour analyser le texte source et EMF pour représenter l'ASG (graphe sémantique abstrait, qui est essentiellement une combinaison d'AST et de liaisons) résultant, également appelé « modèle sémantique ». La grammaire du langage modélisé par Xtext est décrite dans le langage propre de Xtext. Cela vous permet non seulement de générer une description grammaticale pour ANTLR, mais également d'obtenir un mécanisme de sérialisation AST (c'est-à-dire que Xtext fournit à la fois un analyseur et un analyseur), une indication de contexte et un certain nombre d'autres composants de langage. D’un autre côté, le langage grammatical utilisé dans Xtext est moins flexible que, par exemple, le langage grammatical utilisé dans ANTLR. Par conséquent, il est parfois nécessaire de « plier » le langage implémenté vers Xtext, ce qui ne pose généralement pas de problème si nous parlons d'un langage développé à partir de zéro, mais peut être inacceptable pour les langages avec une syntaxe déjà établie. Malgré cela, Xtext est actuellement l'outil le plus mature, le plus riche en fonctionnalités et le plus polyvalent d'Eclipse pour créer des langages de programmation et des outils de développement pour ceux-ci. C’est notamment un outil idéal pour le prototypage rapide (langage spécifique au domaine, DSL). En plus du « noyau de langage » mentionné ci-dessus basé sur ANTLR et EMF, Xtext fournit de nombreux composants utiles de niveau supérieur, notamment des mécanismes d'indexation, une construction incrémentielle, un « éditeur intelligent » et bien plus encore, mais laisse de côté la gestion. modèles de langage basés sur Comme EMF, Xtext est un sujet digne d'un livre séparé, et nous pouvons à peine parler brièvement de toutes ses capacités pour le moment.
1C:Enterprise Development Tools utilise activement à la fois EMF lui-même et un certain nombre d'autres projets de modélisation Eclipse. En particulier, Xtext est l'un des fondements des outils de développement pour les langages 1C:Enterprise tels que le langage de programmation et le langage de requête intégrés. Une autre base de ces outils de développement est le projet Eclipse Handly, dont nous parlerons plus en détail (des composants Eclipse répertoriés, il est encore le moins connu).
, un sous-projet du projet de haut niveau Eclipse Technology, est né d'une première contribution de code à la Fondation Eclipse effectuée par 1C en 2014. Depuis, 1C continue de soutenir le développement du projet : les committers Handly sont des salariés de l'entreprise. Le projet est petit, mais il occupe une niche assez unique dans Eclipse : son objectif principal est de soutenir le développement de modèles basés sur des poignées.
Les principes architecturaux de base des modèles basés sur des handles, tels que l'idiome handle/body, ont été abordés ci-dessus en utilisant le modèle de ressource et le modèle Java comme exemples. Il a également noté que le modèle de ressources et le modèle Java constituent des fondements importants pour les outils de développement Java (JDT) d'Eclipse. Et comme presque tous les projets *DT Eclipse ont une architecture similaire à JDT, il ne serait pas exagéré de dire que les modèles basés sur les handles sous-tendent de nombreux, sinon tous les IDE construits sur la plate-forme Eclipse. Par exemple, les outils de développement Eclipse C/C++ (CDT) disposent d'un modèle C/C++ basé sur des handles qui joue le même rôle dans l'architecture CDT que le modèle Java dans le JDT.
Avant Handly, Eclipse ne proposait pas de bibliothèques spécialisées pour la création de modèles de langage basés sur des handles. Les modèles qui existent actuellement ont été créés principalement en adaptant directement le code du modèle Java (aka copier/coller), dans les cas où cela permet Licence publique Eclipse (EPL). (Évidemment, ce n'est généralement pas un problème juridique pour, par exemple, les projets Eclipse eux-mêmes, mais pas pour les produits fermés.) En plus de son caractère aléatoire inhérent, cette technique introduit des problèmes bien connus : la duplication de code introduite par l'adaptation aux erreurs, etc. Le pire est que les modèles qui en résultent restent des « choses en soi » et ne tirent pas parti du potentiel d’unification. Mais isoler les concepts et protocoles communs pour les modèles de langage basés sur des handles pourrait conduire à la création de composants réutilisables pour travailler avec eux, comme ce qui s'est produit dans le cas d'EMF.
Ce n'est pas qu'Eclipse n'ait pas compris ces problèmes. Retour en 2005 , résumant l'expérience de développement du prototype CDT, la nécessité de créer une infrastructure commune pour les modèles de langage, y compris les modèles basés sur des handles. Mais comme cela arrive souvent, en raison de tâches plus prioritaires, la mise en œuvre de ces idées n’a jamais abouti. Pendant ce temps, la factorisation du code *DT est encore l’un des sujets sous-développés dans Eclipse.
Dans un certain sens, le projet Handly est conçu pour résoudre à peu près les mêmes problèmes qu'EMF, mais pour des modèles basés sur des handles, et principalement des modèles de langage (c'est-à-dire représentant des éléments de la structure d'un langage de programmation). Les principaux objectifs fixés lors de la conception de Handly sont répertoriés ci-dessous :
- Identification des principales abstractions du domaine.
- Réduire les efforts et améliorer la qualité de la mise en œuvre des modèles de langage basés sur des handles grâce à la réutilisation du code.
- Fournir une API de méta-niveau unifiée aux modèles résultants, permettant de créer des composants IDE communs qui fonctionnent avec des modèles basés sur des handles de langage.
- Flexibilité et évolutivité.
- Intégration avec Xtext (dans une couche séparée).
Pour mettre en évidence les concepts et protocoles communs, les implémentations existantes de modèles basés sur des descripteurs de langage ont été analysées. Les principales interfaces et implémentations de base fournies par Handly sont présentées dans la Fig. 8.
Riz. 8. Interfaces communes et implémentations de base des éléments Handly
L'interface IElement représente le handle d'un élément et est commune aux éléments de tous les modèles basés sur Handly. La classe abstraite Element implémente le mécanisme poignée/corps généralisé (Fig. 9).
Riz. 9. IElement et implémentation générique du handle/body
De plus, Handly fournit un mécanisme généralisé pour notifier les modifications apportées aux éléments du modèle (Fig. 10). Comme vous pouvez le constater, il est globalement similaire aux mécanismes de notification implémentés dans le modèle de ressource et le modèle Java, et utilise IElementDelta pour fournir une représentation unifiée des informations de modification des éléments.
Riz. 10. Interfaces générales et implémentations de base du mécanisme de notification Handly
La partie Handly discutée ci-dessus (Fig. 9 et 10) peut être utilisée pour représenter presque tous les modèles basés sur une poignée. Pour créer linguistique modèles, le projet offre des fonctionnalités supplémentaires - en particulier des interfaces communes et des implémentations de base pour les éléments de la structure du texte source, ce qu'on appelle éléments sources (Fig. 8). L'interface ISourceFile représente un fichier source et ISourceConstruct représente un élément dans le fichier source. Les classes abstraites SourceFile et SourceConstruct implémentent des mécanismes généralisés pour prendre en charge l'utilisation des fichiers sources et de leurs éléments, par exemple, travailler avec des tampons de texte, lier les coordonnées d'un élément dans le texte source, réconcilier les modèles avec le contenu actuel d'un tampon de copie de travail. , etc. La mise en œuvre de ces mécanismes est généralement un véritable défi, et Handly peut réduire considérablement les efforts de développement de modèles de langage basés sur des handles en fournissant des implémentations de base de haute qualité.
En plus des mécanismes de base répertoriés ci-dessus, Handly fournit une infrastructure pour les tampons de texte et les instantanés, la prise en charge de l'intégration avec les éditeurs de code source (y compris l'intégration prête à l'emploi avec l'éditeur Xtext), ainsi que certains composants d'interface utilisateur courants qui travailler avec des éditeurs de code source, des modèles manuels tels que le framework outline. Pour illustrer ses capacités, le projet fournit plusieurs exemples, dont une implémentation du modèle Java dans Handly. (Par rapport à l'implémentation complète du modèle Java dans JDT, ce modèle est intentionnellement quelque peu simplifié pour plus de clarté.)
Comme indiqué précédemment, lors de la conception initiale et du développement ultérieur de Handly, l'accent a été et continue d'être mis sur l'évolutivité et la flexibilité.
En principe, les modèles basés sur des poignées s'adaptent assez bien « de par leur conception ». Par exemple, l'idiome handle/body vous permet de limiter la quantité de mémoire consommée par un modèle. Mais il y a aussi des nuances. Ainsi, lors des tests d'évolutivité de Handly, un problème a été découvert dans la mise en œuvre du mécanisme de notification : lorsqu'un grand nombre d'éléments étaient modifiés, la construction de deltas prenait trop de temps. Il s'est avéré que le même problème était présent dans le modèle Java JDT, à partir duquel le code correspondant avait été adapté. Nous avons corrigé le bug dans Handly et préparé un correctif similaire pour JDT, qui a été reçu avec gratitude. Ce n'est qu'un exemple où l'introduction de Handly dans les implémentations de modèles existantes pourrait être potentiellement utile, car dans ce cas, un tel bug pourrait être corrigé à un seul endroit.
Pour rendre l’implémentation de Handly dans les implémentations de modèles existantes techniquement réalisable, la bibliothèque doit avoir une flexibilité importante. Le principal problème est de maintenir la compatibilité ascendante à travers le modèle API. Ce problème a été résolu en en séparant clairement l'API spécifique au modèle, définie et entièrement contrôlée par le développeur, de l'API méta-niveau unifiée fournie par la bibliothèque. Cela rend non seulement techniquement possible l'implémentation de Handly dans les implémentations existantes, mais donne également au nouveau développeur de modèles une liberté significative lors de la conception de l'API.
La flexibilité a aussi d’autres aspects. Par exemple, Handly n'impose presque aucune restriction sur la structure du modèle et peut être utilisé pour modéliser à la fois des langages à usage général et spécifiques à un domaine. Lors de la construction de la structure du fichier source, Handly ne prescrit aucune forme particulière de représentation AST et, en principe, ne nécessite même pas la présence d'un AST lui-même, garantissant ainsi la compatibilité avec presque tous les mécanismes d'analyse. Enfin, Handly prend en charge l'intégration complète avec l'espace de travail Eclipse, mais peut également travailler directement avec les systèmes de fichiers grâce à son intégration avec (EFS).
Version actuelle est sorti en décembre 2016. Bien que le projet soit actuellement en phase d'incubation et que l'API n'ait pas encore été définitivement fixée, Handly est déjà utilisé dans deux grands produits commerciaux qui ont pris le risque d'agir comme des « early adopters » et, je dois le dire, je ne le regrette pas encore.
Comme indiqué ci-dessus, l'un de ces produits est 1C:Enterprise Development Tools, où Handly est utilisé dès le début pour modéliser des éléments de la structure de haut niveau de langages 1C:Enterprise tels que le langage de programmation intégré et le langage de requête. . Un autre produit est moins connu du grand public. Ce , un environnement de conception intégré pour processeur de jeu d'instructions spécifiques à une application (ASIP), utilisé à la fois au sein de la société tchèque Codasip elle-même et par ses clients, notamment , , , . Codasip utilise Handly en production depuis 2015, à partir de la version Handly 0.2. La dernière version de Codasip Studio utilise la version 0.5, sortie en juin 2016. Ondřej Ilčík, qui dirige le développement de l'IDE chez Codasip, est en contact avec le projet, fournissant des commentaires essentiels au nom du « tiers adoptant ». Il a même pu trouver du temps libre pour participer directement au développement du projet, en implémentant une couche d'interface utilisateur (~4000 lignes de code) pour l'un des exemples de Handly, un modèle Java. Des informations de première main plus détaillées sur l’utilisation de Handly par les adoptants peuvent être trouvées sur la page le projet.
Nous espérons qu'après la sortie de la version 1.0 avec une garantie de stabilité de l'API et la sortie du projet de l'état d'incubation, Handly aura de nouveaux adoptants. Entre-temps, le projet continue de tester et d'améliorer l'API, en publiant deux versions « majeures » par an – en juin (à la même date que la version simultanée d'Eclipse) et en décembre, offrant un calendrier prévisible sur lequel les adoptants peuvent compter. Nous pouvons également ajouter que le « taux de bugs » du projet reste à un niveau constamment bas et que Handly travaille de manière fiable dans les produits des premiers utilisateurs depuis les toutes premières versions. Pour explorer davantage Eclipse Handly, vous pouvez utiliser и .
Source: habr.com