Probablemente hace tiempo que no necesita presentación especial. Mucha gente está familiarizada con Eclipse gracias a las herramientas de desarrollo Java de Eclipse (). Es este popular IDE de Java de código abierto el que la mayoría de los desarrolladores asocian con la palabra "Eclipse". Sin embargo, Eclipse es a la vez una plataforma extensible para integrar herramientas de desarrollo (Plataforma Eclipse) y una serie de IDE creados sobre esta base, incluido JDT. Eclipse es tanto el Proyecto Eclipse, el proyecto de nivel superior que coordina el desarrollo de la Plataforma Eclipse y el JDT, como el SDK de Eclipse, el resultado de ese desarrollo. Finalmente, Eclipse es una Fundación de código abierto con una enorme comunidad de proyectos, no todos escritos en Java o relacionados con herramientas de desarrollo (por ejemplo, proyectos и ). El mundo de Eclipse es muy diverso.
En este artículo, que es de naturaleza general, intentaremos analizar algunos de los conceptos básicos de la arquitectura Eclipse como plataforma para crear herramientas de desarrollo integradas y dar una idea inicial de los componentes de Eclipse que forman la base de la tecnología. plataforma para el “nuevo Configurador” 1C: Enterprise. . Por supuesto, dicha revisión será inevitablemente en gran medida superficial y bastante limitada, incluso porque no nos centramos sólo en los desarrolladores de Eclipse como público objetivo. Sin embargo, esperamos que incluso los desarrolladores experimentados de Eclipse puedan encontrar información interesante en el artículo. Por ejemplo, hablaremos de uno de los “secretos de Eclipse”, un proyecto relativamente nuevo y poco conocido. , que fue fundada y apoyada por 1C.
Introducción a la arquitectura de Eclipse
Primero veamos algunos aspectos generales de la arquitectura Eclipse usando el ejemplo. (JDT). La elección de JDT como ejemplo no es casual. Este es el primer entorno de desarrollo integrado que aparece en Eclipse. Otros proyectos *DT Eclipse, como Eclipse C/C++ Development Tooling (CDT), se crearon más tarde y tomaron prestados tanto principios arquitectónicos básicos como fragmentos de código fuente individuales de JDT. Los fundamentos de la arquitectura establecidos en JDT son relevantes hasta el día de hoy para casi cualquier IDE construido sobre la plataforma Eclipse, incluidas las herramientas de desarrollo 1C:Enterprise.
En primer lugar, cabe señalar que Eclipse se caracteriza por una estratificación arquitectónica bastante clara, con la separación de la funcionalidad independiente del lenguaje de la funcionalidad diseñada para soportar lenguajes de programación específicos, y la separación de los componentes "centrales" independientes de la interfaz de usuario de los componentes asociados. con interfaz de usuario compatible.
Por lo tanto, la plataforma Eclipse define una infraestructura común e independiente del lenguaje, y las herramientas de desarrollo de Java agregan un IDE de Java con todas las funciones a Eclipse. Tanto la plataforma Eclipse como el JDT constan de varios componentes, cada uno de los cuales pertenece a un “núcleo” independiente de la interfaz de usuario o a una capa de interfaz de usuario (Figura 1).
Arroz. 1. Plataforma Eclipse y JDT
Enumeremos los componentes principales de la plataforma Eclipse:
- Runtime — Define la infraestructura del complemento. Eclipse se caracteriza por una arquitectura modular. Básicamente, Eclipse es una colección de "puntos de extensión" y "extensiones".
- Espacio de trabajo — Gestiona uno o más proyectos. Un proyecto consta de carpetas y archivos que se asignan directamente al sistema de archivos.
- Kit de herramientas de widgets estándar (SWT) - Proporciona elementos básicos de interfaz de usuario integrados con el sistema operativo.
- JCara — Proporciona una serie de marcos de interfaz de usuario creados sobre SWT.
- Banco de trabajo — Define el paradigma de la interfaz de usuario de Eclipse: editores, vistas, perspectivas.
Hay que decir que la plataforma Eclipse también proporciona muchos otros componentes útiles para crear herramientas de desarrollo integradas, incluidos Debug, Compare, Search y Team. Mención especial merece JFace Text, la base para crear "editores inteligentes" de código fuente. Desafortunadamente, ni siquiera un examen superficial de estos componentes, así como de los componentes de la capa UI, es posible dentro del alcance de este artículo, por lo que en el resto de esta sección nos limitaremos a una descripción general de los principales componentes "centrales" de la plataforma Eclipse y JDT.
Tiempo de ejecución principal
La infraestructura del complemento Eclipse se basa en y proporcionado por el proyecto . Cada complemento de Eclipse es un paquete OSGi. La especificación OSGi define, en particular, mecanismos para el control de versiones y la resolución de dependencias. Además de estos mecanismos estándar, Equinox introduce el concepto puntos de expansión. Cada complemento puede definir sus propios puntos de extensión y también introducir funcionalidades adicionales (“extensiones”) al sistema utilizando puntos de extensión definidos por el mismo u otros complementos. Cualquier descripción detallada de los mecanismos OSGi y Equinox está fuera del alcance de este artículo. Solo notemos que la modularización en Eclipse es total (cualquier subsistema, incluido Runtime, consta de uno o más complementos), y casi todo en Eclipse es una extensión. Además, estos principios estaban integrados en la arquitectura de Eclipse mucho antes de la introducción de OSGi (en ese momento usaban su propia tecnología, muy similar a OSGi).
Espacio de trabajo principal
Casi cualquier entorno de desarrollo integrado creado sobre la plataforma Eclipse funciona con el espacio de trabajo de Eclipse. Es el espacio de trabajo que suele contener el código fuente de la aplicación desarrollada en el IDE. El espacio de trabajo se asigna directamente al sistema de archivos y consta de proyectos que contienen carpetas y archivos. Estos proyectos, carpetas y archivos se denominan Los recursos espacio de trabajo. La implementación del espacio de trabajo en Eclipse sirve como caché en relación con el sistema de archivos, lo que permite acelerar significativamente el recorrido del árbol de recursos. Además, Workspace ofrece una serie de servicios adicionales, que incluyen и .
El componente Core Resources (complemento org.eclipse.core.resources) es responsable de respaldar el espacio de trabajo y sus recursos. En particular, este componente proporciona acceso programático al espacio de trabajo en la forma modelos de recursos. Para trabajar eficazmente con este modelo, los clientes necesitan una forma sencilla de presentar un enlace a un recurso. En este caso, sería deseable ocultar del acceso del cliente el objeto que almacena directamente el estado del recurso en el modelo. De lo contrario, en el caso de, por ejemplo, eliminar un archivo, el cliente podría seguir reteniendo un objeto que ya no está en el modelo, con los consiguientes problemas. Eclipse resuelve este problema usando algo llamado encargarse de recurso. Handle actúa como una clave (solo conoce la ruta al recurso en el espacio de trabajo) y controla completamente el acceso al objeto del modelo interno, que almacena directamente información sobre el estado del recurso. Este diseño es una variación del patrón. .
Arroz. La Figura 2 ilustra el modismo Mango/Cuerpo aplicado al modelo de recursos. La interfaz IResource representa el identificador de un recurso y es una API, a diferencia de la clase Resource, que implementa esta interfaz, y la clase ResourceInfo, que representa el cuerpo, que no son API. Hacemos hincapié en que el identificador solo conoce la ruta al recurso relativa a la raíz del espacio de trabajo y no contiene un enlace a la información del recurso. Los objetos de información de recursos forman el llamado "árbol de elementos". Esta estructura de datos se materializa completamente en la memoria. Para encontrar la instancia de información de recurso correspondiente a un identificador, se recorre el árbol de elementos según la ruta almacenada en ese identificador.
Arroz. 2. IResource y ResourceInfo
Como veremos más adelante, el diseño básico del modelo de recursos (podríamos llamarlo basado en identificadores) también se utiliza en Eclipse para otros modelos. Por ahora, enumeremos algunas de las propiedades distintivas de este diseño:
- Handle es un objeto de valor. Los objetos de valor son objetos inmutables cuya igualdad no se basa en la identidad. Estos objetos se pueden utilizar de forma segura como clave en contenedores hash. Varias instancias de identificador pueden hacer referencia al mismo recurso. Para compararlos, debe utilizar el método igual (Objeto).
- Handle define el comportamiento de un recurso, pero no contiene información sobre el estado del recurso (los únicos datos que almacena es la "clave", la ruta al recurso).
- Identificador puede referirse a un recurso que no existe (ya sea un recurso que aún no se ha creado o un recurso que ya se ha eliminado). La existencia de un recurso se puede comprobar utilizando el método IResource.exists().
- Algunas operaciones se pueden implementar basándose únicamente en la información almacenada en el propio identificador (las llamadas operaciones de solo identificador). Algunos ejemplos son IResource.getParent(), getFullPath(), etc. No es necesario que el recurso exista para que dicha operación tenga éxito. Las operaciones que requieren que exista un recurso para tener éxito generan una CoreException si el recurso no existe.
Eclipse proporciona un mecanismo eficiente para notificar cambios en los recursos del espacio de trabajo (Figura 3). Los recursos pueden cambiar como resultado de acciones realizadas dentro del propio IDE de Eclipse o como resultado de la sincronización con el sistema de archivos. En ambos casos, los clientes que se suscriben a las notificaciones reciben información detallada sobre los cambios en forma de "deltas de recursos". Un delta describe cambios entre dos estados de un (sub)árbol de recursos del espacio de trabajo y es en sí mismo un árbol, cada nodo del cual describe un cambio en un recurso y contiene una lista de deltas en el siguiente nivel que describen cambios en los recursos secundarios.
Arroz. 3. IResourceChangeEvent e IResourceDelta
El mecanismo de notificación basado en deltas de recursos tiene las siguientes características:
- Un solo cambio y muchos cambios se describen usando la misma estructura, ya que el delta se construye usando el principio de composición recursiva. Los clientes suscriptores pueden procesar notificaciones de cambios de recursos mediante un descenso recursivo a través de un árbol de deltas.
- El delta contiene información completa sobre los cambios en el recurso, incluido su movimiento y/o cambios en los "marcadores" asociados con él (por ejemplo, los errores de compilación se representan como marcadores).
- Dado que las referencias a recursos se realizan a través del identificador, delta naturalmente puede hacer referencia a un recurso remoto.
Como veremos pronto, los componentes principales del diseño del mecanismo de notificación de cambios del modelo de recursos también son relevantes para otros modelos basados en identificadores.
Núcleo JDT
El modelo de recursos del espacio de trabajo de Eclipse es un modelo fundamental independiente del lenguaje. El componente JDT Core (complemento org.eclipse.jdt.core) proporciona una API para navegar y analizar la estructura del espacio de trabajo desde una perspectiva Java, el llamado "modelo Java" (modelo java). Esta API se define en términos de elementos Java, a diferencia de la API del modelo de recursos subyacente, que se define en términos de carpetas y archivos. Las principales interfaces del árbol de elementos de Java se muestran en la Fig. 4.
Arroz. 4. Elementos del modelo Java
El modelo Java utiliza el mismo lenguaje de identificador/cuerpo que el modelo de recursos (Figura 5). IJavaElement es el identificador y JavaElementInfo desempeña el papel de cuerpo. La interfaz IJavaElement define un protocolo común a todos los elementos Java. Algunos de sus métodos son de solo control: getElementName(), getParent(), etc. El objeto JavaElementInfo almacena el estado del elemento correspondiente: su estructura y atributos.
Arroz. 5. IJavaElement y JavaElementInfo
El modelo Java tiene algunas diferencias en la implementación del diseño básico de mango/cuerpo en comparación con el modelo de recursos. Como se señaló anteriormente, en el modelo de recursos, el árbol de elementos, cuyos nodos son objetos de información de recursos, está completamente contenido en la memoria. Pero el modelo Java puede tener una cantidad significativamente mayor de elementos que el árbol de recursos, porque también representa la estructura interna de los archivos .java y .class: tipos, campos y métodos.
Para evitar materializar completamente todo el árbol de elementos en la memoria, la implementación del modelo Java utiliza un caché LRU de tamaño limitado de información de elementos, donde la clave es manejar IJavaElement. Los objetos de información de elementos se crean a pedido a medida que se navega por el árbol de elementos. En este caso, los elementos utilizados con menos frecuencia se expulsan del caché y el consumo de memoria del modelo permanece limitado al tamaño de caché especificado. Esta es otra ventaja del diseño basado en identificadores, que oculta completamente dichos detalles de implementación del código del cliente.
El mecanismo para notificar cambios en elementos Java es en general similar al mecanismo para rastrear cambios en los recursos del espacio de trabajo discutido anteriormente. Un cliente que desea monitorear cambios en el modelo Java se suscribe a notificaciones, que se representan como un objeto ElementChangedEvent que contiene un IJavaElementDelta (Figura 6).
Arroz. 6. ElementChangedEvent y IJavaElementDelta
El modelo Java no contiene información sobre los cuerpos de los métodos o la resolución de nombres, por lo que para un análisis detallado del código escrito en Java, JDT Core proporciona un modelo adicional (no basado en identificadores): (árbol de sintaxis abstracta, AST). AST representa el resultado de analizar el texto fuente. Los nodos AST corresponden a elementos de la estructura del módulo fuente (declaraciones, operadores, expresiones, etc.) y contienen información sobre las coordenadas del elemento correspondiente en el texto fuente, así como (como opción) información sobre la resolución de nombres en la forma de enlaces a los llamados Enlaces. Los enlaces son objetos que representan entidades con nombre, como tipos, métodos y variables, conocidas por el compilador. A diferencia de los nodos AST, que forman un árbol, los enlaces admiten referencias cruzadas y generalmente forman un gráfico. La clase abstracta ASTNode es la clase base común para todos los nodos AST. Las subclases de ASTNode corresponden a construcciones sintácticas específicas del lenguaje Java.
Debido a que los árboles de sintaxis pueden consumir una cantidad significativa de memoria, JDT almacena en caché solo un AST para el editor activo. A diferencia del modelo Java, el AST generalmente se considera un modelo "intermedio" y "temporal" cuyos miembros no deben ser referenciados por los clientes fuera del contexto de la operación que condujo a la creación del AST.
Los tres modelos enumerados (modelo Java, AST, enlaces) juntos forman la base para construir "herramientas de desarrollo inteligentes" en JDT, incluido un potente editor Java con varios "ayudantes", varias acciones para procesar el código fuente (incluida la organización de una lista de archivos de importación). nombres y formato según el estilo personalizado), herramientas de búsqueda y refactorización. En este caso, el modelo Java juega un papel especial, ya que es el que se utiliza como base para una representación visual de la estructura de la aplicación que se está desarrollando (por ejemplo, en Package Explorer, Outline, Search, Call Hierarchy y Jerarquía de tipos).
Componentes de Eclipse utilizados en 1C: Herramientas de desarrollo empresarial
En la Fig. La Figura 7 muestra los componentes de Eclipse que forman la base de la plataforma tecnológica para 1C:Enterprise Development Tools.
Arroz. 7. Eclipse como plataforma para 1C: Herramientas de desarrollo empresarial
Plataforma Eclipse Proporciona infraestructura básica. Analizamos algunos aspectos de esta infraestructura en la sección anterior.
(EMF) proporciona un medio general para modelar datos estructurados. EMF está integrado con la plataforma Eclipse, pero también se puede utilizar por separado en aplicaciones Java normales. Muy a menudo, los nuevos desarrolladores de Eclipse ya conocen bien EMF, aunque todavía no comprenden completamente las complejidades de la plataforma Eclipse. Una de las razones de tan merecida popularidad es el diseño universal, que incluye, entre otras cosas, una API de metanivel unificada, que permite trabajar con cualquier modelo EMF de forma general. Las implementaciones básicas para objetos modelo proporcionadas por EMF y el subsistema para generar código modelo basado en el metamodelo aumentan significativamente la velocidad de desarrollo y reducen la cantidad de errores. EMF también contiene mecanismos para serializar modelos, rastrear cambios en el modelo y mucho más.
Como cualquier herramienta verdaderamente de propósito general, EMF es adecuado para resolver una amplia gama de problemas de modelado, pero algunas clases de modelos (por ejemplo, los modelos basados en manijas discutidos anteriormente) pueden requerir herramientas de modelado más especializadas. Hablar de CEM es una tarea ingrata, especialmente dentro de los límites limitados de un artículo, ya que es el tema de un libro aparte, y bastante denso. Solo notemos que el sistema de generalizaciones de alta calidad subyacente al EMF permitió el nacimiento de toda una gama de proyectos dedicados al modelado, que se incluyen en el proyecto de nivel superior. junto con el propio FEM. Uno de esos proyectos es Eclipse Xtext.
proporciona una infraestructura de "modelado de texto". Usos de Xtext para analizar el texto fuente y EMF para representar el ASG resultante (gráfico semántico abstracto, que es esencialmente una combinación de AST y enlaces), también llamado "modelo semántico". La gramática del lenguaje modelado por Xtext se describe en el propio lenguaje de Xtext. Esto le permite no solo generar una descripción gramatical para ANTLR, sino también obtener un mecanismo de serialización de AST (es decir, Xtext proporciona un analizador y un analizador), una sugerencia de contexto y una serie de otros componentes del lenguaje. Por otro lado, el lenguaje gramatical usado en Xtext es menos flexible que, digamos, el lenguaje gramatical usado en ANTLR. Por lo tanto, a veces es necesario "doblar" el lenguaje implementado a Xtext, lo que no suele ser un problema si hablamos de un lenguaje desarrollado desde cero, pero puede resultar inaceptable para lenguajes con una sintaxis ya establecida. A pesar de esto, Xtext es actualmente la herramienta más madura, rica en funciones y versátil de Eclipse para crear lenguajes de programación y herramientas de desarrollo para ellos. En particular, es una herramienta ideal para la creación rápida de prototipos. (lenguaje específico de dominio, DSL). Además del "núcleo del lenguaje" mencionado anteriormente basado en ANTLR y EMF, Xtext proporciona muchos componentes útiles de nivel superior, incluidos mecanismos de indexación, construcción incremental, un "editor inteligente" y mucho, mucho más, pero deja de lado el manejo. Modelos lingüísticos basados en Al igual que EMF, Xtext es un tema digno de un libro aparte, y apenas podemos hablar brevemente sobre todas sus capacidades en este momento.
1C:Enterprise Development Tools utiliza activamente tanto el propio EMF como otros proyectos de modelado de Eclipse. En particular, Xtext es una de las bases de las herramientas de desarrollo para lenguajes 1C:Enterprise como el lenguaje de programación integrado y el lenguaje de consulta. Otra base para estas herramientas de desarrollo es el proyecto Eclipse Handly, que analizaremos con más detalle (de los componentes de Eclipse enumerados, sigue siendo el menos conocido).
, un subproyecto del proyecto de alto nivel de Tecnología Eclipse, surgió como resultado de una contribución de código inicial a la Fundación Eclipse realizada por 1C en 2014. Desde entonces, 1C ha seguido apoyando el desarrollo del proyecto: los comprometidos con Handly son empleados de la empresa. El proyecto es pequeño, pero ocupa un nicho bastante singular en Eclipse: su objetivo principal es apoyar el desarrollo de modelos basados en mangos.
Los principios arquitectónicos básicos de los modelos basados en mangos, como el modismo mango/cuerpo, se analizaron anteriormente utilizando el modelo de recursos y el modelo Java como ejemplos. También señaló que tanto el modelo de recursos como el modelo Java son bases importantes para las herramientas de desarrollo Java (JDT) de Eclipse. Y dado que casi todos los proyectos *DT Eclipse tienen una arquitectura similar a JDT, no sería una gran exageración decir que los modelos basados en manijas subyacen a muchos, si no a todos, los IDE construidos sobre la plataforma Eclipse. Por ejemplo, las herramientas de desarrollo (CDT) de Eclipse C/C++ tienen un modelo C/C++ basado en identificadores que desempeña el mismo papel en la arquitectura CDT que el modelo Java en JDT.
Antes de Handly, Eclipse no ofrecía bibliotecas especializadas para crear modelos de lenguaje basados en identificadores. Los modelos que existen actualmente se crearon principalmente adaptando directamente el código del modelo Java (también conocido como copiar/pegar), en los casos en que lo permita Licencia pública Eclipse (EPL). (Obviamente, esto no suele ser un problema legal para, por ejemplo, los proyectos Eclipse en sí, pero no para los productos de código cerrado). Además de su inherente desorden, esta técnica introduce problemas bien conocidos: duplicación de código introducida al adaptarse a errores, etc. Lo peor es que los modelos resultantes siguen siendo “cosas en sí mismas” y no aprovechan el potencial de unificación. Pero aislar conceptos y protocolos comunes para modelos de lenguaje basados en identificadores podría llevar a la creación de componentes reutilizables para trabajar con ellos, similar a lo que ocurrió en el caso de EMF.
No es que Eclipse no entendiera estos problemas. En 2005 , resumiendo la experiencia de desarrollo del prototipo CDT, la necesidad de crear una infraestructura común para los modelos de lenguaje, incluidos los modelos basados en identificadores. Pero, como suele suceder, debido a las tareas de mayor prioridad, la implementación de estas ideas nunca llegó a su fin. Mientras tanto, la factorización del código *DT sigue siendo uno de los temas poco desarrollados en Eclipse.
En cierto sentido, el proyecto Handly está diseñado para resolver aproximadamente los mismos problemas que EMF, pero para modelos basados en mangos y, principalmente, de lenguaje (es decir, que representan elementos de la estructura de algún lenguaje de programación). Los principales objetivos marcados al diseñar Handly se enumeran a continuación:
- Identificación de las principales abstracciones del área temática.
- Reducir el esfuerzo y mejorar la calidad de la implementación de modelos de lenguaje basados en identificadores mediante la reutilización de código.
- Proporcionar una API de metanivel unificada a los modelos resultantes, lo que permite crear componentes IDE comunes que funcionan con modelos basados en identificadores de lenguaje.
- Flexibilidad y escalabilidad.
- Integración con Xtext (en una capa separada).
Para resaltar conceptos y protocolos comunes, se analizaron las implementaciones existentes de modelos basados en lenguajes. Las principales interfaces e implementaciones básicas proporcionadas por Handly se muestran en la Fig. 8.
Arroz. 8. Interfaces comunes e implementaciones básicas de elementos Handly.
La interfaz IElement representa el identificador de un elemento y es común a los elementos de todos los modelos basados en Handly. La clase abstracta Element implementa el mecanismo generalizado de mango/cuerpo (Fig. 9).
Arroz. 9. IElement e implementación genérica de identificador/cuerpo
Además, Handly proporciona un mecanismo generalizado para notificar cambios en los elementos del modelo (Fig. 10). Como puede ver, es muy similar a los mecanismos de notificación implementados en el modelo de recursos y el modelo Java, y utiliza IElementDelta para proporcionar una representación unificada de la información de cambio de elementos.
Arroz. 10. Interfaces generales e implementaciones básicas del mecanismo de notificación Handly
La parte Handy comentada anteriormente (Fig. 9 y 10) se puede utilizar para representar casi cualquier modelo basado en mango. Para crear lingüístico modelos, el proyecto ofrece funcionalidad adicional, en particular, interfaces comunes e implementaciones básicas para elementos de la estructura del texto fuente, los llamados elementos fuente (Figura 8). La interfaz ISourceFile representa un archivo fuente e ISourceConstruct representa un elemento dentro del archivo fuente. Las clases abstractas SourceFile y SourceConstruct implementan mecanismos generalizados para soportar el trabajo con archivos fuente y sus elementos, por ejemplo, trabajar con buffers de texto, vincular las coordenadas de un elemento en el texto fuente, conciliar modelos con el contenido actual de un buffer de copia de trabajo. , etc. La implementación de estos mecanismos suele ser todo un desafío, y Handly puede reducir significativamente el esfuerzo de desarrollar modelos de lenguaje basados en identificadores al proporcionar implementaciones básicas de alta calidad.
Además de los mecanismos principales enumerados anteriormente, Handly proporciona una infraestructura para búferes de texto e instantáneas, soporte para la integración con editores de código fuente (incluida la integración inmediata con el editor Xtext), así como algunos componentes de interfaz de usuario comunes que Trabajar con editores de código fuente. Manejar modelos como el marco de esquema. Para ilustrar sus capacidades, el proyecto proporciona varios ejemplos, incluida una implementación del modelo Java en Handly. (En comparación con la implementación completa del modelo Java en JDT, este modelo está algo simplificado intencionalmente para mayor claridad).
Como se señaló anteriormente, un enfoque importante durante el diseño inicial y el desarrollo posterior de Handly fue y sigue siendo la escalabilidad y la flexibilidad.
En principio, los modelos basados en mangos se escalan bastante bien "por diseño". Por ejemplo, el modismo mango/cuerpo le permite limitar la cantidad de memoria consumida por un modelo. Pero también hay matices. Por lo tanto, al probar la escalabilidad de Handly, se descubrió un problema en la implementación del mecanismo de notificación: cuando se cambiaba una gran cantidad de elementos, construir deltas llevaba demasiado tiempo. Resultó que el mismo problema estaba presente en el modelo JDT Java, del cual una vez se adaptó el código correspondiente. Arreglamos el error en Handly y preparamos un parche similar para JDT, que fue recibido con gratitud. Este es solo un ejemplo en el que introducir Handly en implementaciones de modelos existentes podría ser potencialmente útil, porque en este caso dicho error podría corregirse en un solo lugar.
Para que la implementación de Handly en implementaciones de modelos existentes sea técnicamente factible, la biblioteca debe tener una flexibilidad significativa. El principal problema es mantener la compatibilidad con versiones anteriores en todo el modelo API. Este problema fue resuelto en separando claramente la API específica del modelo, definida y totalmente controlada por el desarrollador, de la API de metanivel unificada proporcionada por la biblioteca. Esto no sólo hace que sea técnicamente posible implementar Handly en implementaciones existentes, sino que también brinda al desarrollador del nuevo modelo una gran libertad al diseñar la API.
La flexibilidad también tiene otros aspectos. Por ejemplo, Handly casi no impone restricciones a la estructura del modelo y puede usarse para modelar lenguajes tanto de propósito general como de dominio específico. Al construir la estructura del archivo fuente, Handly no prescribe ninguna forma particular de representación de AST y, en principio, ni siquiera requiere la presencia de un AST en sí, garantizando así la compatibilidad con casi cualquier mecanismo de análisis. Finalmente, Handly admite la integración total con el espacio de trabajo de Eclipse, pero también puede trabajar directamente con sistemas de archivos gracias a su integración con (EFS).
Versión actual salió en diciembre de 2016. A pesar de que el proyecto se encuentra actualmente en estado de incubación y la API aún no se ha solucionado finalmente, Handly ya se utiliza en dos grandes productos comerciales que se arriesgaron a actuar como "early adopters" y, debo decir, No te arrepientas todavía.
Como se señaló anteriormente, uno de estos productos es 1C:Enterprise Development Tools, donde Handly se utiliza desde el principio para modelar elementos de la estructura de alto nivel de dichos lenguajes 1C:Enterprise como el lenguaje de programación integrado y el lenguaje de consulta. . Otro producto es menos conocido por el público en general. Este , un entorno de diseño integrado para procesadores de conjuntos de instrucciones de aplicaciones específicas (ASIP), utilizado tanto dentro de la propia empresa checa Codasip como por sus clientes, incluidos , , , . Codasip ha estado utilizando Handly en producción desde 2015, comenzando con la versión Handly 0.2. La última versión de Codasip Studio utiliza la versión 0.5, lanzada en junio de 2016. Ondřej Ilčík, que lidera el desarrollo de IDE en Codasip, está en contacto con el proyecto y proporciona comentarios vitales en nombre del "tercero adoptante". Incluso pudo encontrar algo de tiempo libre para participar directamente en el desarrollo del proyecto, implementando una capa UI (~4000 líneas de código) para uno de los ejemplos de Handly, un modelo Java. Puede encontrar información más detallada de primera mano sobre el uso de Handly por parte de los adoptantes en la página proyecto.
Esperamos que después del lanzamiento de la versión 1.0 con una garantía de estabilidad de API y que el proyecto salga del estado de incubación, Handly tenga nuevos adoptantes. Mientras tanto, el proyecto continúa probando y mejorando aún más la API, lanzando dos versiones "importantes" por año: en junio (la misma fecha que la versión simultánea de Eclipse) y diciembre, lo que proporciona un cronograma predecible en el que los adoptantes pueden confiar. También podemos agregar que la "tasa de errores" del proyecto se mantiene en un nivel consistentemente bajo y Handly ha estado trabajando de manera confiable en los productos de los primeros usuarios desde las primeras versiones. Para explorar más a fondo Eclipse Handly, puede utilizar и .
Fuente: habr.com