Probablement, n'a certainement plus besoin d'être présenté. Beaucoup connaissent Eclipse grâce aux outils de développement Java Eclipse (). Cette populaire IDE open-source est associée pour la plupart des développeurs au mot « Eclipse ». Cependant, Eclipse est également une plateforme extensible pour l'intégration d'outils de développement (Eclipse Platform) et une série d'IDE construites sur sa base, y compris JDT. Eclipse est également le Projet Eclipse, un projet de haut niveau qui coordonne le développement d'Eclipse Platform et JDT, ainsi que l'Eclipse SDK – le résultat fourni de ce développement. Enfin, Eclipse est une fondation open-source avec une immense communauté de projets, dont beaucoup ne sont pas écrits en Java ni liés aux outils de développement (par exemple, les projets et ). Le monde d'Eclipse est très varié.
Dans cet article, qui est de nature générale, nous allons essayer d'examiner quelques bases de l'architecture d'Eclipse en tant que plateforme de développement d'outils intégrés et donner une première impression des composants d'Eclipse qui forment les bases de la plateforme technologique pour le « nouveau configurateur » 1C: Enterprise, . Il va de soi qu'un tel examen sera inévitablement quelque peu superficiel et plutôt limité, notamment parce que nous nous orientons non seulement vers les développeurs d'Eclipse comme public cible. Toutefois, nous espérons que même les développeurs d'Eclipse expérimentés pourront trouver des informations intéressantes dans cet article. Par exemple, nous parlerons d'un des « secrets d'Eclipse », un projet relativement nouveau et encore peu connu , fondé et soutenu par la société 1C.
Introduction à l'architecture d'Eclipse
Examinons d'abord certains aspects généraux de l'architecture d'Eclipse à travers l'exemple de (JDT). Le choix de JDT comme exemple n'est pas fortuit. C'est le premier environnement de développement intégré apparu dans Eclipse. Les autres projets *DT d'Eclipse, tels que Eclipse C/C++ Development Tooling (CDT), ont été créés plus tard et ont emprunté tant les principes architecturaux fondamentaux que des fragments de code source à JDT. Les bases de l'architecture établies dans JDT sont toujours pertinentes aujourd'hui pour pratiquement toute IDE construite sur la plateforme Eclipse, y compris pour 1C:Enterprise Development Tools.
Tout d'abord, il convient de noter qu'Eclipse se caractérise par une architecture suffisamment claire, séparant la fonctionnalité indépendante du langage de celle destinée à la prise en charge de langages de programmation spécifiques, ainsi que séparant les composants « noyaux » (core) indépendants de l'interface utilisateur des composants associés à la prise en charge de l'interface utilisateur.
Ainsi, la plateforme Eclipse définit une infrastructure générale, indépendante du langage, tandis que les outils de développement Java ajoutent à Eclipse un IDE Java complet. Tant la plateforme Eclipse que JDT se composent de plusieurs composants, chacun appartenant soit au « noyau » indépendant de l'interface utilisateur, soit à la couche de l'interface utilisateur (voir Fig. 1).
Fig. 1. Plateforme Eclipse et JDT
Énumérons les principaux composants de la plateforme Eclipse :
- Runtime — Définit l'infrastructure des plugins. Eclipse se caractérise par une architecture modulaire. En substance, Eclipse est une collection de « points d'extension » et d'« extensions ».
- Workspace — Gère un ou plusieurs projets. Un projet est composé de dossiers et de fichiers, qui sont directement affichés sur le système de fichiers.
- Standard Widget Toolkit (SWT) — Fournit des éléments de base de l'interface utilisateur, intégrés au système d'exploitation.
- JFace — Fournit un ensemble de frameworks UI construits sur SWT.
- Workbench — Définit la paradigme UI d'Eclipse : éditeurs, vues, perspectives.
Il convient de mentionner qu'Eclipse Platform offre également de nombreux autres composants utiles pour la création d'outils de développement intégrés, parmi lesquels on peut citer Debug, Compare, Search, et Team. Il convient également de mentionner JFace Text – la base pour la création d'« éditeurs intelligents » de code source. Malheureusement, même un examen rapide de ces composants, ainsi que de ceux de la couche UI, ne peut être effectué dans le cadre de cet article, c'est pourquoi, dans le reste de cette section, nous nous limiterons à un aperçu des principaux composants « noyaux » de la plateforme Eclipse et de JDT.
Core Runtime
L'infrastructure des plugins Eclipse repose sur et est fournie par le projet . Chaque plugin Eclipse est un bundle OSGi. La spécification OSGi définit, entre autres, les mécanismes de versionnage et de résolution des dépendances. En plus de ces mécanismes standard, Equinox introduit le concept de point d'extension. Chaque plugin peut définir ses propres points d'extension et également apporter des fonctionnalités supplémentaires au système (« extensions »), en utilisant des points d'extension définis par ce même plugin ou d'autres. Une description détaillée des mécanismes OSGi et Equinox dépasse le cadre de cet article. Notons simplement que la modularisation dans Eclipse est de nature totale (tous les sous-systèmes, y compris Runtime, se composent d'un ou plusieurs plugins) et pratiquement tout dans Eclipse est une extension. De plus, ces principes ont été intégrés dans l'architecture d'Eclipse bien avant l'implémentation d'OSGi (à l'époque, une technologie propriétaire, largement similaire à OSGi, était utilisée).
Espace de travail principal
Pratiquement tous les environnements de développement intégrés construits sur la base de la plateforme Eclipse fonctionnent avec l'espace de travail Eclipse. C'est précisément l'espace de travail qui contient généralement le code source de l'application développée dans l'IDE. L'espace de travail est directement mappé au système de fichiers et se compose de projets qui contiennent des dossiers et des fichiers. Ces projets, dossiers et fichiers sont appelés ressources espace de travail. La mise en œuvre de l'espace de travail dans Eclipse sert en quelque sorte de cache par rapport au système de fichiers, ce qui permet d'accélérer considérablement la navigation dans l'arborescence des ressources. De plus, l'espace de travail fournit plusieurs services supplémentaires, y compris et .
La composante Core Resources (plugin org.eclipse.core.resources) est responsable du soutien de l'espace de travail et de ses ressources. En particulier, cette composante fournit un accès programmatique à l'espace de travail sous la forme de modèle de ressources. Pour travailler efficacement avec ce modèle, les clients ont besoin d'un moyen simple de représenter une référence à une ressource. Dans ce cas, il serait souhaitable de cacher l'objet qui conserve directement l'état de la ressource dans le modèle de l'accès du client. Autrement dit, en cas de suppression d'un fichier, le client pourrait continuer à maintenir un objet qui n'est plus dans le modèle, entraînant ainsi des problèmes. Eclipse résout ce problème en utilisant ce que l'on appelle un handle de ressource. Le handle agit en tant que clé (il connaît uniquement le chemin vers la ressource dans l'espace de travail) et contrôle totalement l'accès à l'objet interne du modèle, qui conserve directement les informations sur l'état de la ressource. Ce design est une variation du patron .
La figure 2 illustre l'idiome Handle/Body en rapport avec le modèle de ressources. L'interface IResource représente le handle d'une ressource et constitue une API, contrairement à la classe Resource, qui implémente cette interface, ainsi qu'à la classe ResourceInfo, qui représente le body et ne fait pas partie de l'API. Notons que le handle ne connaît que le chemin vers la ressource par rapport à la racine de l'espace de travail et ne contient pas de lien vers les informations de la ressource. Les objets d'information de la ressource forment ce qu'on appelle un « arbre d'éléments » (element tree). Cette structure de données est entièrement matérialisée en mémoire. Pour trouver une instance d'information de ressource correspondant à un certain handle, l'arbre des éléments est parcouru en suivant le chemin stocké dans ce handle.
Figure 2. IResource et ResourceInfo
Comme nous le verrons plus loin, le design de base du modèle de ressources (qu'on peut appeler basé sur le handle) est utilisé dans Eclipse et pour d'autres modèles. En attendant, énumérons quelques propriétés distinctives de ce design :
- Le handle est un objet valeur (value object). Les objets valeur sont des objets immuables (immutable), dont l'égalité ne repose pas 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 faire référence à la même ressource. Pour les comparer, il faut utiliser la méthode equals(Object).
- Le handle définit le comportement de la ressource, mais ne contient aucune information sur l'état de la ressource (les seules données qu'il conserve sont la « clé », le chemin vers la ressource).
- Le handle peut référencer une ressource inexistante (soit une ressource qui n'est pas encore créée, soit une ressource qui a déjà été supprimée). L'existence de la ressource peut être vérifiée à l'aide de la méthode IResource.exists().
- Certaines opérations peuvent être effectuées uniquement à partir des informations stockées dans le handle lui-même (appelées opérations handle-only). Des exemples incluent IResource.getParent(), getFullPath(), etc. Il n'est pas nécessaire que la ressource existe pour que cette opération soit effectuée avec succès. Les opérations nécessitant que la ressource existe pour s'exécuter avec succès lèveront une exception (CoreException) si la ressource n'existe pas.
Eclipse fournit un mécanisme efficace de notification des modifications des ressources de l'espace de travail (voir Fig. 3). Les ressources peuvent changer à la suite d'actions effectuées dans l'IDE Eclipse lui-même ou en raison de la synchronisation avec le système de fichiers. Dans les deux cas, les clients abonnés aux notifications reçoivent des informations détaillées sur les changements sous la forme de « delta de ressource » (resource delta). Le delta décrit les modifications entre deux états de l'arborescence des ressources de l'espace de travail et est en lui-même une arborescence, chaque nœud décrivant une modification d'une certaine ressource et contenant une liste de deltas de niveau inférieur, décrivant les modifications des ressources enfants.
Fig. 3. IResourceChangeEvent et IResourceDelta
Le mécanisme de notification basé sur les deltas de ressources a les caractéristiques suivantes :
- Une seule modification et de multiples modifications sont décrites à l'aide de la même structure, car le delta est construit selon le principe de la composition récursive. Les clients abonnés peuvent traiter les notifications de changement de ressources par une descente récursive dans l'arborescence des deltas.
- Le delta contient toutes les informations concernant la modification de la ressource, y compris son déplacement et/ou le changement de ses « marqueurs » associés (des erreurs de compilation, par exemple, sont représentées sous forme de marqueurs).
- Puisque les références à la ressource se font via un handle, le delta peut naturellement faire référence à une ressource distante.
Comme nous le verrons bientôt, les éléments principaux du design du mécanisme de notification des modifications du modèle de ressources s'appliquent également à d'autres modèles basés sur des handles.
JDT Core
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 du point de vue de Java, le modèle Java dit (modèle Java). Cette API est définie en termes d'éléments Java, contrairement à l'API sous-jacente du modèle de ressources, 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 à la Fig. 4.
Fig. 4. Éléments du modèle Java
Le modèle Java utilise la même idiome handle/body que le modèle de ressources (fig. 5). IJavaElement est le handle, tandis que JavaElementInfo joue le rôle de body. L'interface IJavaElement définit un protocole commun à tous les éléments Java. Certains de ses méthodes sont uniquement des handles : getElementName(), getParent(), etc. L'objet JavaElementInfo stocke l'état de l'élément correspondant : sa structure et ses attributs.
Fig. 5. IJavaElement et JavaElementInfo
Le modèle Java présente certaines différences dans la mise en œuvre de la conception de base handle/body par rapport au modèle de ressources. Comme mentionné précédemment, dans le modèle de ressources, l'arbre des éléments, dont les nœuds sont des objets resource info, est entièrement chargé en mémoire. Cependant, dans le modèle Java, il peut y avoir un nombre d'éléments beaucoup plus élevé que dans l'arbre des ressources, car il inclut également la structure interne des fichiers .java et .class : types, champs et méthodes.
Pour éviter la matérialisation complète de tout l'arbre des éléments en mémoire, l'implémentation du modèle Java utilise un cache LRU de taille limitée pour l'element info, où la clé est le handle IJavaElement. Les objets element info sont créés à la demande au fur et à mesure que la navigation dans l'arbre des éléments se poursuit. Les éléments les moins utilisés sont expulsés du cache, et la consommation de mémoire par le modèle reste limitée à la taille spécifiée du cache. C'est un autre avantage de la conception basée sur le handle, qui cache complètement de tels détails de mise en œuvre du code client.
Le mécanisme de notification de changement des éléments Java est en gros analogue au mécanisme de suivi des changements des ressources de l'espace de travail examiné ci-dessus. Un client souhaitant suivre les changements dans le modèle Java s'abonne à des notifications, qui sont présentées sous la forme d'un objet ElementChangedEvent, contenant IJavaElementDelta (fig. 6).
Fig. 6. ElementChangedEvent et IJavaElementDelta
Le modèle Java ne contient pas d'informations sur le corps des méthodes ou la résolution des noms, c'est pourquoi pour une analyse détaillée du code écrit en Java, JDT Core fournit un modèle supplémentaire (non basé sur handle) : (arbre de syntaxe abstrait, AST). L'AST représente le résultat de l'analyse syntaxique du texte source. Les nœuds de l'AST correspondent aux é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 des noms sous forme de liens vers ce que l'on appelle bindings. Les Bindings sont des objets représentant des entités nommées telles que des types, des méthodes et des variables connues du compilateur. Contrairement aux nœuds de l'AST, qui forment un arbre, les bindings prennent en charge les références croisées et, en général, forment un graphe. La classe abstraite ASTNode est la classe de base commune pour tous les nœuds de l'AST. Les sous-classes d'ASTNode correspondent aux constructions syntaxiques spécifiques du langage Java.
Comme les arbres syntaxiques peuvent consommer une quantité significative de mémoire, JDT met en cache 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 éléments ne devraient pas être référencés par les clients en dehors du contexte de l'opération ayant conduit à la création de l'AST.
Les trois modèles énumérés (modèle Java, AST, bindings) constituent ensemble la base de la création d'outils de développement « intelligents » dans JDT, parmi lesquels un puissant éditeur Java avec divers « assistants », différentes actions de traitement du code source (y compris l'organisation de la liste d'importation des noms et le formatage selon le style configuré), des outils de recherche et de refactoring. Dans ce contexte, le modèle Java joue un rôle particulier, car c'est lui qui est utilisé comme fondement pour la représentation visuelle de la structure de l'application en cours de développement (par exemple, dans l'Explorateur de paquets, le Plan, la Recherche, la Hiérarchie des appels, et la Hiérarchie des types).
Composants Eclipse utilisés dans les Outils de développement 1C:Enterprise
La figure 7 montre les composants Eclipse qui constituent la base de la plateforme technologique pour les Outils de développement 1C:Enterprise.
Fig. 7. Eclipse comme plateforme pour les Outils de développement 1C:Enterprise
Plateforme Eclipse fournit une infrastructure de base. Nous avons examiné certains aspects de cette infrastructure dans la section précédente.
(EMF) fournit des outils généraux pour la modélisation de données structurées. EMF est intégré à la plateforme Eclipse, mais peut également être utilisé de manière autonome dans des applications Java classiques. Il est assez fréquent que les développeurs débutants d'Eclipse soient déjà bien familiarisés avec EMF, bien qu'ils ne maîtrisent pas encore toutes les subtilités de la plateforme Eclipse. L'une des raisons de cette popularité bien méritée est son design universel, incluant, entre autres, une API unifiée de méta-niveau qui permet de travailler de manière générique avec n'importe quel modèle EMF. Les implémentations de base d'EMF pour les objets modèle et le sous-système de génération de code modèle à partir de la méta-modèle augmentent considérablement la rapidité de développement et réduisent le nombre d'erreurs. De plus, EMF contient des mécanismes de sérialisation des modèles, de suivi des modifications dans le modèle, et bien plus encore.
Comme tout véritable outil universel, EMF convient à un large éventail de tâches liées à la modélisation, mais certaines classes de modèles (par exemple, les modèles basés sur des handles mentionnés ci-dessus) peuvent nécessiter des outils de modélisation plus spécialisés. Parler d'EMF est une tâche ingrate, surtout dans le cadre limité d'un seul article, car c'est le sujet d'un livre à part entière, et un livre assez épais. Notons simplement que le système de généralisation de qualité, sur lequel EMF est basé, a permis l'émergence d'un large éventail de projets consacrés à la modélisation, qui font partie du projet de haut niveau. aux côtés de l'EMF lui-même. L'un de ces projets est Eclipse Xtext.
fournit une infrastructure de « modélisation textuelle ». Xtext utilise pour l'analyse syntaxique du texte source et l'EMF pour représenter le ASG (graphe sémantique abstrait, qui est essentiellement une combinaison de l'AST et des bindings), également appelé « modèle sémantique ». La grammaire du langage modélisé à l'aide de Xtext est décrite dans son propre langage Xtext. Cela permet non seulement de générer une description de la grammaire pour ANTLR, mais aussi d'obtenir un mécanisme de sérialisation de l'AST (c'est-à-dire que Xtext fournit à la fois un parseur et un unparsor), l'auto-complétion contextuelle et un certain nombre d'autres composants linguistiques. D'autre part, le langage de description de la grammaire utilisé dans Xtext est moins flexible par rapport, disons, au langage de description de grammaire dans ANTLR. Par conséquent, il faut parfois « adapter » le langage mis en œuvre à Xtext, ce qui n'est généralement pas un problème pour un langage développé de zéro, mais peut être inacceptable pour des langages ayant déjà une syntaxe établie. Cela dit, Xtext est actuellement l'outil le plus mature, fonctionnellement complet et polyvalent dans Eclipse pour la construction de langages de programmation et d'outils de développement associés. En particulier, il est l'outil idéal pour le prototypage rapide. (domain-specific language, DSL). En plus du « noyau du langage » basé sur ANTLR et EMF mentionné ci-dessus, Xtext fournit de nombreux composants utiles de niveau supérieur, y compris des mécanismes d'indexation, de construction incrémentale, un « éditeur intelligent », et beaucoup d'autres choses, mais omet les modèles linguistiques basés sur des handles. Comme EMF, Xtext mérite un livre à part entière, et il est peu probable que nous puissions même effleurer toutes ses capacités.
Les Outils de Développement 1C:Enterprise utilisent activement à la fois l'EMF en tant que tel et plusieurs autres projets d'Eclipse Modeling. En particulier, Xtext est l'une des bases des outils de développement pour des langages tels que 1C:Enterprise, comme le langage de programmation intégré et le langage de requêtes. L'autre base de ces outils de développement est le projet Eclipse Handly, que nous examinerons plus en détail (parmi les composants Eclipse listés, il est pour l'instant le moins connu).
, sous-projet du projet de haut niveau Eclipse Technology, a émergé suite à la contribution initiale de code à la Fondation Eclipse, réalisée par l'entreprise 1C en 2014. Depuis, l'entreprise 1C continue de soutenir le développement du projet : les committers de Handly sont des employés de cette société. Le projet est modeste, mais occupe une niche assez unique dans Eclipse : son objectif principal est de soutenir le développement de modèles basés sur des handles.
Les principaux principes architecturaux des modèles basés sur des handles, comme l'idiome handle/body, ont été abordés plus haut à l'aide de l'exemple du modèle des ressources et du modèle Java. Il a également été noté que le modèle des ressources et le modèle Java servent de bases importantes pour les outils de développement Java d'Eclipse (JDT). Et comme presque tous les projets *DT d'Eclipse ont une architecture similaire à celle de JDT, il ne serait pas exagéré de dire que les modèles basés sur des handles sont à la base de nombreux, sinon tous, les IDE construits sur la plateforme Eclipse. Par exemple, dans Eclipse C/C++ Development Tooling (CDT), il existe un modèle basé sur des handles pour C/C++, qui joue dans l'architecture de CDT le même rôle que le modèle Java dans JDT.
Avant l'émergence de Handly, Eclipse ne proposait pas de bibliothèques spécialisées pour la construction de modèles linguistiques basés sur des handles. Les modèles existants étaient principalement créés par une adaptation directe du code du modèle Java (c'est-à-dire copier/coller), dans les cas où cela est permis par la licence publique Eclipse (EPL). (Il est évident que, par exemple, pour les projets d'Eclipse eux-mêmes, cela ne pose généralement pas de problème juridique, ce qui n'est pas le cas pour les produits avec code source fermé.) En plus de son caractère désordonné typique, cette méthode entraîne des problèmes bien connus : duplication de code, erreurs introduites lors de l'adaptation, etc. Ce qui est encore pire, c'est que les modèles résultants restent « des objets isolés » et ne tirent pas parti du potentiel d'unification existant. Pourtant, l'identification de concepts et de protocoles communs pour les modèles linguistiques basés sur des handles pourrait conduire à la création de composants réutilisables pour travailler avec eux, de la même manière que cela s'est produit avec EMF.
Il ne faut pas dire qu'Eclipse n'avait pas conscience de ces problèmes. Déjà en 2005, , en 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 langues, y compris les modèles basés sur des handles. Cependant, comme c'est souvent le cas, en raison de tâches plus prioritaires, ces idées n'ont finalement pas pu être mises en œuvre. Pendant ce temps, la factorisation du code des projets *DT reste l'un des sujets encore peu explorés dans Eclipse.
D'une certaine manière, le projet Handly vise à résoudre des tâches similaires à celles de l'EMF, mais pour les modèles basés sur des handles, et en particulier linguistiques (c'est-à-dire représentant des éléments de la structure d'un certain langage de programmation). Voici les principaux objectifs qui ont été fixés lors de la conception de Handly :
- Identifier les abstractions clés du domaine thématique.
- Réduire les efforts et améliorer la qualité de l'implémentation des modèles linguistiques basés sur des handles grâce à la réutilisation du code.
- Fournir une API unifiée au niveau méta aux modèles résultants, permettant la création de composants IDE communs travaillant avec des modèles linguistiques basés sur des handles.
- Flexibilité et évolutivité.
- Intégration avec Xtext (dans une couche distincte).
Pour identifier les concepts et protocoles communs, des implémentations existantes de modèles linguistiques basés sur des handles ont été analysées. Les interfaces principales et les implémentations de base fournies par Handly sont présentées à la figure 8.
Fig. 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 un mécanisme généralisé handle/body (voir fig. 9).
Fig. 9. IElement et implémentation généralisée handle/body
De plus, Handly fournit un mécanisme généralisé de notification des modifications d'éléments du modèle (voir fig. 10). Comme on peut le voir, en termes généraux, il est analogue aux mécanismes de notification mis en œuvre dans le modèle de ressources et le modèle Java, et utilise IElementDelta pour une représentation unifiée des informations sur les modifications d'éléments.
Fig. 10. Interfaces communes et implémentations de base du mécanisme de notification Handly.
La partie de Handly examinée ci-dessus (fig. 9 et 10) peut être utilisée pour représenter pratiquement n'importe quel modèle basé sur des handles. Pour créer des modèles linguistiques 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, appelés éléments source (fig. 8). L'interface ISourceFile représente le fichier source, tandis que ISourceConstruct représente un élément à l'intérieur du fichier source. Les classes abstraites SourceFile et SourceConstruct mettent en œuvre des mécanismes génériques pour soutenir le travail avec des fichiers source et leurs éléments, comme le traitement des buffers de texte, la liaison aux coordonnées de l'élément dans le texte source, la réconciliation du modèle avec le contenu actuel du buffer de travail, etc. La mise en œuvre de ces mécanismes est généralement une tâche assez complexe, et Handly peut considérablement réduire les efforts de développement des modèles basés sur des handles en fournissant des implémentations de base de qualité.
En plus des mécanismes principaux mentionnés ci-dessus, Handly fournit une infrastructure pour les buffers de texte et les « snapshots », ainsi qu'un soutien à l'intégration avec les éditeurs de code source (y compris une intégration « prête à l'emploi » avec l'éditeur Xtext), ainsi que certains composants UI généraux fonctionnant avec des modèles basés sur Handly, comme le framework outline. Pour illustrer ses capacités, le projet fournit plusieurs exemples, y compris une implémentation d'un modèle Java sur Handly. (Comparée à l'implémentation complète du modèle Java dans JDT, cette modèle est délibérément simplifiée pour plus de clarté.)
Comme mentionné précédemment, une attention particulière a été portée lors de la conception initiale de Handly et de son évolution ultérieure à la scalabilité et à la flexibilité.
En principe, les modèles basés sur des handles sont assez bien scalables « par design ». Par exemple, l'idiome handle/body permet de limiter la mémoire consommée par le modèle. Mais il y a des nuances. Ainsi, lors des tests de scalabilité de Handly, un problème a été découvert dans la mise en œuvre du mécanisme de notification – lors de la modification d'un grand nombre d'éléments, la construction des deltas prenait trop de temps. Il s'est avéré que le même problème existait également dans le modèle Java de JDT, à partir duquel le code correspondant avait été adapté autrefois. Nous avons corrigé le bug dans Handly et préparé un patch similaire pour JDT, qui a été accepté avec gratitude. C'est juste un exemple parmi d'autres, où l'intégration de Handly dans des réalisations de modèles existantes pourrait potentiellement être bénéfique, car dans ce cas, une telle erreur pourrait être corrigée en un seul endroit.
Pour rendre l'intégration de Handly techniquement possible dans des implémentations de modèles existants, la bibliothèque doit posséder une flexibilité significative. Le principal défi est de maintenir la rétrocompatibilité de l'API du modèle. Ce problème a été résolu dans par une séparation claire entre l'API spécifique au modèle, définie et contrôlée de manière exhaustive par le développeur, et l'API unifiée de niveau méta fournie par la bibliothèque. Cela rend non seulement techniquement possible l'intégration de Handly dans des implémentations existantes, mais donne également au développeur d'un nouveau modèle une grande liberté dans la conception de l'API.
La flexibilité présente d'autres aspects. Par exemple, Handly impose peu de restrictions sur la structure du modèle et peut être utilisé tant pour le modélisation de langages de programmation général que pour des langages orientés domaine. Lors de la construction de la structure de fichier source, Handly ne prescrit pas de forme spécifique de représentation AST et ne nécessite en principe pas même la présence d'un AST, garantissant ainsi la compatibilité avec pratiquement tous les mécanismes d'analyse syntaxique. Enfin, Handly supporte une intégration complète avec l'espace de travail Eclipse, mais peut également fonctionner directement avec des systèmes de fichiers, grâce à son intégration avec (EFS).
La version actuelle a été publiée en décembre 2016. Bien que le projet soit actuellement en phase d'incubation et que l'API ne soit pas encore définitivement stabilisée, Handly est déjà utilisé dans deux grands produits commerciaux qui ont pris le risque d'être des « premiers adoptants » et, il faut le dire, n'ont jusqu'à présent aucun regret.
Comme mentionné précédemment, l'un de ces produits est 1C:Enterprise Development Tools, où Handly est utilisé depuis le début pour modéliser les éléments de la structure de haut niveau de langages tels que 1C:Entreprise, y compris le langage de programmation intégré et le langage de requêtes. L'autre produit est moins connu du grand public. C'est , un environnement intégré de conception de processeurs orientés problèmes (application-specific instruction-set processor, ASIP), utilisé tant à l'intérieur de la société tchèque Codasip que par ses clients, parmi lesquels , , , . Codasip utilise Handly en production depuis 2015, à partir de la version Handly 0.2. La dernière version actuellement disponible de Codasip Studio utilise la version 0.5, sortie en juin 2016. Ondřej Ilčík, responsable du développement de l'IDE chez Codasip, est en contact avec le projet, fournissant un retour d'information crucial de la part d'un « adoptant externe ». Il a même pu trouver un peu de temps libre pour participer directement au développement du projet, en réalisant une couche d'interface utilisateur (~ 4000 lignes de code) pour un des exemples de Handly, modèle Java. Des informations plus détaillées « de première main » sur l'utilisation de Handly par les adoptants peuvent être trouvées sur la page .
Nous espérons qu'après la sortie de la version 1.0 avec une garantie de stabilité de l'API et le passage du projet hors de l'état d'incubation, Handly aura de nouveaux adoptants. Pour l'instant, le projet continue d'être testé et d'améliorer davantage l'API, en publiant deux « grandes » versions par an – en juin (à la même date que la sortie simultanée d'Eclipse) et en décembre, garantissant un calendrier prévisible sur lequel les adoptants peuvent compter. Il convient également d'ajouter que le taux de bogues du projet reste à un niveau constamment bas et que Handly fonctionne de manière fiable dans les produits des premiers adoptants depuis ses premières versions. Pour en savoir plus sur Eclipse Handly, vous pouvez utiliser et .
Source : habr.com
