Probablemente, ya no necesita una presentación especial. Muchos conocen Eclipse gracias a las herramientas de desarrollo de Java Eclipse (). Esta popular IDE de Java de código abierto es asociada por la mayoría de los desarrolladores con la palabra “Eclipse”. Sin embargo, Eclipse es también una plataforma extensible para la integración de herramientas de desarrollo (Eclipse Platform), y una serie de IDEs que se construyen sobre ella, incluyendo JDT. Eclipse es el Proyecto Eclipse, un proyecto de alto nivel que coordina el desarrollo de la Eclipse Platform y JDT, y el Eclipse SDK, que es el resultado de este desarrollo. Finalmente, Eclipse es una Fundación de código abierto con una enorme comunidad de proyectos, muchos de los cuales no están escritos en Java o no tienen relación con herramientas de desarrollo (por ejemplo, los proyectos y ). El mundo de Eclipse es muy diverso.
En este artículo, de carácter general, intentaremos examinar algunos fundamentos de la arquitectura de Eclipse como plataforma para construir herramientas de desarrollo integradas y dar una primera impresión sobre los componentes de Eclipse que forman la base de la plataforma tecnológica para el “nuevo Configurador” 1C:Enterprise, . Por supuesto, este análisis será inevitablemente superficial y bastante limitado, en parte porque no nos dirigimos únicamente a los desarrolladores de Eclipse como público objetivo. Sin embargo, esperamos que incluso los desarrolladores experimentados de Eclipse puedan encontrar en el artículo información interesante para ellos. Por ejemplo, hablaremos sobre uno de los “secretos de Eclipse”, un proyecto relativamente nuevo y poco conocido hasta ahora, , que fue fundado y mantenido por la firma 1C.
Introducción a la arquitectura de Eclipse
Comencemos revisando algunos aspectos generales de la arquitectura de Eclipse utilizando como ejemplo (JDT). La elección de JDT como ejemplo no es casual. Esta fue la primera plataforma de desarrollo integrada que apareció en Eclipse. Los otros proyectos *DT de Eclipse, como Eclipse C/C++ Development Tooling (CDT), se crearon más tarde y tomaron tanto los principios arquitectónicos básicos como fragmentos de código fuente de JDT. Los fundamentos de la arquitectura establecidos en JDT siguen siendo relevantes hasta hoy para prácticamente cualquier IDE construida sobre la Eclipse Platform, incluyendo las herramientas de desarrollo 1C:Enterprise.
En primer lugar, es importante señalar que Eclipse se caracteriza por una clara estratificación arquitectónica, separando la funcionalidad independiente del lenguaje de la funcionalidad destinada a soportar lenguajes de programación específicos, así como separando los componentes "núcleo" (core) independientes de la interfaz de usuario de los componentes relacionados con el soporte de la interfaz de usuario.
Así, la plataforma Eclipse define una infraestructura general, independiente del lenguaje, mientras que las herramientas de desarrollo de Java añaden a Eclipse un entorno de desarrollo integrado (IDE) para Java totalmente funcional. Tanto la plataforma Eclipse como JDT se componen de varios componentes, cada uno de los cuales se refiere ya sea al "núcleo" independiente de la interfaz de usuario o a la capa de interfaz de usuario (Fig. 1).
Fig. 1. Plataforma Eclipse y JDT
Enumeremos los componentes principales de la plataforma Eclipse:
- Runtime — Define la infraestructura de plugins. Eclipse se caracteriza por una arquitectura modular. En esencia, Eclipse es una colección de "puntos de extensión" y "extensiones".
- Workspace — Gestiona uno o varios proyectos. Un proyecto consta de carpetas y archivos que se reflejan directamente en el sistema de archivos.
- Standard Widget Toolkit (SWT) — Proporciona los elementos básicos de la interfaz de usuario, integrados con el sistema operativo.
- JFace — Proporciona un conjunto de frameworks de UI construidos sobre SWT.
- Workbench — Define la paradigma UI de Eclipse: editores, vistas, perspectivas.
Cabe mencionar que la plataforma Eclipse ofrece también muchos otros componentes útiles para construir herramientas de desarrollo integradas, entre los que se pueden señalar Debug, Compare, Search y Team. Además, se debe mencionar JFace Text, la base para construir "editores inteligentes" de código fuente. Lamentablemente, incluso un breve examen de estos componentes, así como de los componentes de la capa de UI, no se puede realizar en el marco de este artículo, por lo que en la restante parte de esta sección nos limitaremos a revisar los principales componentes "núcleo" de la plataforma Eclipse y JDT.
Core Runtime
La infraestructura de plugins de Eclipse se basa en y es proporcionada por el proyecto . Cada plugin de Eclipse es un bundle OSGi. La especificación OSGi define, entre otras cosas, los mecanismos de versionado y resolución de dependencias. Además de estos mecanismos estándar, Equinox introduce el concepto de puntos de extensión. Cada plugin puede definir sus propios puntos de extensión, así como aportar funcionalidad adicional al sistema ("extensiones"), utilizando los puntos de extensión definidos por el mismo o por otros plugins. Una descripción detallada de los mecanismos OSGi y Equinox excede el alcance de este artículo. Solo resaltamos que la modularización en Eclipse es total (cualquier subsistema, incluyendo Runtime, se compone de uno o varios plugins), y prácticamente todo en Eclipse es una extensión. Además, estos principios fueron establecidos en la arquitectura de Eclipse mucho antes de la implementación de OSGi (en ese momento se utilizaba una tecnología propia, muy similar a OSGi).
Espacio de trabajo principal
Prácticamente cualquier entorno de desarrollo integrado construido sobre la base de la plataforma Eclipse trabaja con el espacio de trabajo de Eclipse. De hecho, el espacio de trabajo normalmente contiene el código fuente de la aplicación que se está desarrollando en el IDE. El espacio de trabajo se refleja directamente en el sistema de archivos y se compone de proyectos que contienen carpetas y archivos. Estos proyectos, carpetas y archivos se denominan recursos el espacio de trabajo. La implementación del espacio de trabajo en Eclipse actúa como un caché en relación con el sistema de archivos, lo que permite a su vez acelerar notablemente la navegación del árbol de recursos. Además, el espacio de trabajo ofrece una serie de servicios adicionales, incluyendo y .
El soporte del espacio de trabajo y sus recursos está a cargo del componente Core Resources (plugin org.eclipse.core.resources). En particular, este componente proporciona acceso programático al espacio de trabajo en forma de modelo de recursos. Para trabajar de manera efectiva con este modelo, los clientes necesitan una forma sencilla de representar un enlace a un recurso. En este caso, sería recomendable ocultar el objeto que almacena directamente el estado del recurso en el modelo del acceso del cliente. De lo contrario, en caso de, por ejemplo, eliminar un archivo, el cliente podría seguir manteniendo el objeto que ya no existe en el modelo, lo que generaría problemas. Eclipse resuelve esta tarea utilizando lo que se llama un handle de recurso. El handle actúa como una clave (solo conoce la ruta al recurso en el espacio de trabajo) y controla completamente el acceso al objeto interno del modelo, que almacena directamente la información sobre el estado del recurso. Este diseño es una variación del patrón .
La figura 2 ilustra la idiomática Handle/Body en relación con el modelo de recursos. La interfaz IResource representa el handle del recurso y actúa como una API, a diferencia de la clase Resource, que implementa esta interfaz, así como de la clase ResourceInfo, que representa el body, que no es una API. Es importante destacar que el handle solo conoce la ruta al recurso en relación con la raíz del espacio de trabajo y no contiene una referencia a la información del recurso. Los objetos de información del recurso forman lo que se conoce como el "árbol de elementos" (element tree). Esta estructura de datos está completamente materializada en memoria. Para encontrar una instancia de información del recurso que corresponda a un handle determinado, se recorre el árbol de elementos de acuerdo con la ruta almacenada en ese handle.
Figura 2. IResource y ResourceInfo
Como veremos más adelante, el diseño básico del modelo de recursos (que se puede llamar basado en handle) se utiliza en Eclipse y en otros modelos. Por ahora, enumeremos algunas propiedades distintivas de este diseño:
- El handle es un objeto-valor (value object). Los objetos-valor son objetos inmutables (immutable) cuya igualdad no se basa en la identidad. Tales objetos pueden utilizarse de forma segura como clave en contenedores hasheados. Varios instancias de handle pueden hacer referencia al mismo recurso. Para compararlos, se debe utilizar el método equals(Object).
- El handle define el comportamiento del recurso, pero no contiene información sobre el estado del recurso (los únicos datos que almacena son la "clave", que es la ruta al recurso).
- El handle puede hacer referencia a un recurso que no existe (ya sea un recurso que aún no se ha creado o un recurso que ya ha sido eliminado). La existencia del recurso se puede verificar mediante el método IResource.exists().
- Algunas operaciones pueden implementarse únicamente a partir de la información almacenada en el propio handle (las llamadas operaciones solo de handle). Ejemplos de esto son IResource.getParent(), getFullPath(), etc. El recurso no necesariamente debe existir para que se ejecute con éxito tal operación. Las operaciones que requieren que el recurso exista para ejecutarse con éxito lanzan una excepción (CoreException) si el recurso no existe.
Eclipse proporciona un mecanismo eficaz de notificación sobre cambios en los recursos del espacio de trabajo (fig. 3). Los recursos pueden cambiar tanto como resultado de acciones realizadas en la propia Eclipse IDE, como de la ejecución de una sincronización con el sistema de archivos. En ambos casos, los clientes suscritos a las notificaciones reciben información detallada sobre los cambios en forma de «deltas de recursos» (resource delta). El delta describe los cambios entre dos estados del (sub)árbol de recursos del espacio de trabajo y es en sí mismo un árbol, donde cada nodo describe un cambio en un recurso y contiene una lista de deltas de nivel siguiente que describen los cambios en los recursos hijos.
Fig. 3. IResourceChangeEvent e IResourceDelta
El mecanismo de notificación basado en deltas de recursos tiene las siguientes características:
- Un solo cambio y múltiples cambios se describen utilizando la misma estructura, ya que el delta se construye según el principio de composición recursiva. Los clientes suscriptores pueden procesar las notificaciones sobre cambios de recursos mediante un descenso recursivo a través del árbol de deltas.
- El delta contiene información completa sobre el cambio de un recurso, incluyendo su movimiento y/o el cambio de los «marcadores» asociados (como los errores de compilación que se presentan en forma de marcadores).
- Dado que las referencias a un recurso se realizan a través de un handle, el delta puede referirse naturalmente a un recurso remoto.
Como veremos pronto, los principales componentes del diseño del mecanismo de notificación sobre cambios en el modelo de recursos son relevantes también para otros modelos basados en handles.
JDT Core
El modelo de recursos del espacio de trabajo de Eclipse es un modelo fundamental independiente del lenguaje. El componente JDT Core (plugin org.eclipse.jdt.core) proporciona una API para navegar y analizar la estructura del espacio de trabajo desde la perspectiva de Java, la llamada «modelo de Java» (modelo Java). Esta API está definida en términos de elementos Java, a diferencia de la API subyacente del modelo de recursos, que está definida en términos de carpetas y archivos. Las principales interfaces del árbol de elementos Java se muestran en la fig. 4.
Fig. 4. Elementos del modelo de Java
El modelo Java utiliza la misma idiomática handle/body que el modelo de recursos (fig. 5). IJavaElement es el handle, y JavaElementInfo desempeña el papel de body. La interfaz IJavaElement define un protocolo común para todos los elementos Java. Algunos de sus métodos son solo de handle: getElementName(), getParent(), etc. El objeto JavaElementInfo almacena el estado del elemento correspondiente: su estructura y atributos.
Fig. 5. IJavaElement y JavaElementInfo
El modelo Java tiene algunas diferencias en la implementación del diseño básico handle/body en comparación con el modelo de recursos. Como se mencionó anteriormente, en el modelo de recursos, el árbol de elementos, cuyos nodos son objetos de información de recursos, se almacena completamente en memoria. Sin embargo, en el modelo Java puede haber un número significativamente mayor de elementos que en el árbol de recursos, ya que representa, entre otros, la estructura interna de los archivos .java y .class: tipos, campos y métodos.
Para evitar la materialización completa de todo el árbol de elementos en memoria, la implementación del modelo Java utiliza una caché LRU de tamaño limitado para la información del elemento, donde la clave es el handle IJavaElement. Los objetos de información del elemento se crean bajo demanda a medida que se navega por el árbol de elementos. En este proceso, los elementos menos utilizados se eliminan de la caché, y el consumo de memoria del modelo permanece limitado al tamaño establecido de la caché. Esta es otra ventaja del diseño basado en handles, que oculta completamente tales detalles de implementación del código del cliente.
El mecanismo de notificación de cambios en los elementos Java es, en términos generales, análogo al mecanismo de seguimiento de cambios en los recursos del espacio de trabajo mencionado anteriormente. Un cliente que desee rastrear cambios en el modelo Java se suscribe a las notificaciones, que se presentan en forma de un objeto ElementChangedEvent, que contiene IJavaElementDelta (fig. 6).
Fig. 6. ElementChangedEvent y IJavaElementDelta
El modelo Java no contiene información sobre el cuerpo de los métodos o la resolución de nombres, por lo tanto, para un análisis detallado del código escrito en Java, JDT Core proporciona un modelo adicional (no basado en handles): (árbol de sintaxis abstracta, AST). El AST representa el resultado del análisis sintáctico del texto fuente. Los nodos del AST corresponden a los 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 (opcionalmente) información sobre la resolución de nombres en forma de enlaces a lo que se llaman enlaces. Los enlaces son objetos que representan entidades nombradas, como tipos, métodos y variables, que son conocidos por el compilador. A diferencia de los nodos del AST, que forman un árbol, los enlaces mantienen referencias cruzadas y, en general, forman un grafo. La clase abstracta ASTNode es la clase base común para todos los nodos del AST. Las subclases de ASTNode corresponden a construcciones sintácticas específicas del lenguaje Java.
Dado que los árboles sintácticos pueden consumir una cantidad significativa de memoria, JDT almacena en caché solo un AST, para el editor activo. A diferencia del modelo de Java, el AST generalmente se considera un modelo 'intermedio', 'temporal', del que los clientes no deberían mantener referencias fuera del contexto de la operación que llevó a la creación del AST.
Los tres modelos enumerados (modelo de Java, AST, enlaces) conjuntamente son la base para construir 'herramientas de desarrollo inteligentes' en JDT, entre las cuales se encuentra un potente editor de Java con diversos 'asistentes', varias acciones para procesar el código fuente (entre las que se incluyen la organización de la lista de importación de nombres y el formateo según el estilo configurado), herramientas de búsqueda y refactorización. En este contexto, el modelo de Java juega un papel especial, ya que es el que se utiliza como base para la representación visual de la estructura de la aplicación en desarrollo (por ejemplo, en Package Explorer, Outline, Search, Call Hierarchy y Type Hierarchy).
Componentes de Eclipse utilizados en 1C:Enterprise Developments Tools
En la Fig. 7 se muestran los componentes de Eclipse que forman la base de la plataforma tecnológica para 1C:Enterprise Development Tools.
Fig. 7. Eclipse como plataforma para 1C:Enterprise Development Tools
Plataforma Eclipse proporciona la infraestructura básica. Hemos revisado algunos aspectos de esta infraestructura en la sección anterior.
(EMF) proporciona herramientas generales para la modelación de datos estructurados. EMF está integrado con la plataforma Eclipse, pero también puede usarse por separado en aplicaciones Java estándar. A menudo, los desarrolladores novatos de Eclipse ya están familiarizados con EMF, aunque aún no comprenden completamente las sutilezas de la plataforma Eclipse. Una de las razones de su merecida popularidad es su diseño universal, que incluye, entre otras cosas, una API unificada de nivel meta que permite trabajar de manera genérica con cualquier modelo de EMF. Las implementaciones básicas de EMF para objetos de modelo y el subsistema de generación de código de modelo a partir de la meta-modelo aumentan significativamente la velocidad de desarrollo y reducen la cantidad de errores. Además, EMF contiene mecanismos de serialización de modelos, seguimiento de cambios en el modelo, y mucho más.
Como cualquier herramienta verdaderamente universal, EMF es adecuada para abordar una amplia gama de tareas relacionadas con la modelación, pero algunas clases de modelos (como los modelos basados en handles mencionados anteriormente) pueden requerir herramientas de modelación más especializadas. Hablar de EMF es una tarea ingrata, especialmente dentro del marco limitado de un solo artículo, ya que es el tema de un libro por sí solo, y bastante extenso. Solo cabe señalar que un sistema de generalizaciones de calidad que se encuentra en la base de EMF ha permitido el surgimiento de toda una variedad de proyectos dedicados a la modelación, que forman parte del proyecto de alto nivel. junto con el propio EMF. Uno de esos proyectos es Eclipse Xtext.
proporciona infraestructura para la 'modelación de texto'. Xtext utiliza para el análisis sintáctico del texto fuente y EMF para representar el ASG resultante (grafo semántico abstracto, que, en esencia, es una combinación de AST y bindings), también llamado «modelo semántico». La gramática del lenguaje modelado con Xtext se describe en su propio lenguaje Xtext. Esto permite no solo generar la descripción de la gramática para ANTLR, sino también obtener un mecanismo de serialización del AST (es decir, Xtext proporciona tanto parser como unparser), sugerencias contextuales y una serie de otros componentes del lenguaje. Por otro lado, el lenguaje de descripción de gramática utilizado en Xtext es menos flexible en comparación, digamos, con el lenguaje de descripción de gramática en ANTLR. Por lo tanto, a veces es necesario «ajustar» el lenguaje implementado a Xtext, lo que generalmente no es un problema si se trata de un lenguaje desarrollado desde cero, pero puede ser inaceptable para lenguajes con una sintaxis ya establecida. A pesar de esto, Xtext es actualmente la herramienta más madura, funcionalmente completa y versátil en Eclipse para la construcción de lenguajes de programación y herramientas de desarrollo para ellos. En particular, es una herramienta ideal para la rápida creación de prototipos. (domain-specific language, DSL). Además del mencionado «núcleo del lenguaje» basado en ANTLR y EMF, Xtext ofrece numerosos componentes útiles de nivel superior, incluyendo mecanismos de indexación, construcción incremental, «editor inteligente» y mucho, mucho más, pero deja de lado los modelos de lenguaje basados en handles. Al igual que EMF, Xtext es un tema que merece un libro aparte, y es poco probable que podamos incluso esbozar todas sus capacidades ahora.
Las herramientas de desarrollo de 1C:Enterprise utilizan activamente tanto EMF por sí mismo como una serie de otros proyectos de Eclipse Modeling. En particular, Xtext es una de las bases de las herramientas de desarrollo para lenguajes como el lenguaje de programación integrado y el lenguaje de consultas de 1C:Enterprise. Otro fundamento de estas herramientas de desarrollo es el proyecto Eclipse Handly, del que nos detendremos más en detalle (de los componentes mencionados de Eclipse, es hasta ahora el menos conocido).
, el subproyecto del proyecto de nivel superior Eclipse Technology, surgió a partir de una contribución inicial de código a la Fundación Eclipse, realizada por la empresa 1C en 2014. Desde entonces, la empresa 1C ha continuado apoyando el desarrollo del proyecto: los committers de Handly son empleados de la empresa. El proyecto es pequeño, pero ocupa un nicho bastante único en Eclipse: su objetivo principal es apoyar el desarrollo de modelos basados en handles.
Los principios arquitectónicos fundamentales de los modelos basados en handles, como la idiomática handle/body, se discutieron anteriormente con el ejemplo del modelo de recursos y el modelo Java. Allí también se señaló que tanto el modelo de recursos como el modelo Java son bases importantes para las herramientas de desarrollo Java de Eclipse (JDT). Y dado que prácticamente todos los proyectos *DT de Eclipse tienen una arquitectura similar a la de JDT, no será una gran exageración decir que los modelos basados en handles son la base de muchos, si no de todos, los IDE construidos sobre la Plataforma Eclipse. Por ejemplo, en las herramientas de desarrollo C/C++ de Eclipse (CDT) hay un modelo basado en handles para C/C++, que desempeña en la arquitectura de CDT el mismo papel que el modelo Java en JDT.
Antes de la aparición de Handly, Eclipse no ofrecía bibliotecas especializadas para construir modelos de lenguaje basados en handles. Los modelos existentes se creaban principalmente mediante la adaptación directa del código del modelo Java (también conocido como copiar/pegar), en aquellos casos en que esto es posible. Eclipse Public License (EPL). (Es obvio que, por ejemplo, para los proyectos de Eclipse en sí, esto generalmente no es un problema desde el punto de vista legal, lo cual no se puede decir de los productos con código cerrado). Aparte de la falta de sistematicidad característica, esa metodología lleva a problemas bien conocidos: duplicación de código, errores introducidos durante la adaptación, etc. Y lo que es peor, los modelos resultantes quedan como 'cosas en sí mismas' y no aprovechan el potencial existente para la unificación. Sin embargo, la identificación de conceptos comunes y protocolos para modelos de lenguaje basados en handles podría haber llevado a la creación de componentes reutilizables para trabajar con ellos, de manera similar a lo que ocurrió con EMF.
No se puede decir que en Eclipse no se comprendieran estos problemas. Ya en 2005 , resumiendo la experiencia del desarrollo del prototipo de CDT, la necesidad de crear una infraestructura común para modelos de lenguajes, incluidas las modelos basadas en handle. Sin embargo, como a menudo sucede, debido a tareas más prioritarias, estas ideas nunca se materializaron. Mientras tanto, la factorización del código de los *proyectos DT sigue siendo uno de los temas poco desarrollados en Eclipse.
En cierto sentido, el proyecto Handly está diseñado para abordar aproximadamente las mismas tareas que EMF, pero para modelos basados en handle, y principalmente lenguajes (es decir, que representan elementos de la estructura de algún lenguaje de programación). A continuación se enumeran los principales objetivos establecidos durante el diseño de Handly:
- Identificación de las principales abstracciones del dominio.
- Reducción de esfuerzos y mejora de la calidad de la implementación de modelos de lenguajes basados en handle mediante la reutilización de código.
- Proporcionar una API unificada en el meta-nivel a los modelos resultantes, facilitando la creación de componentes IDE comunes que trabajen con modelos de lenguajes basados en handle.
- Flexibilidad y escalabilidad.
- Integración con Xtext (en una capa separada).
Para identificar conceptos y protocolos comunes, se analizaron implementaciones existentes de modelos de lenguajes basados en handle. Las principales interfaces y implementaciones básicas provistas por Handly se muestran en la fig. 8.
Fig. 8. Interfaces comunes e implementación básica de elementos Handly
La interfaz IElement representa el handle de un elemento y es común a los elementos de todos los modelos basados en Handly. La clase abstracta Element implementa un mecanismo genérico handle/body (fig. 9).
Fig. 9. IElement y la implementación genérica handle/body
Además, Handly proporciona un mecanismo genérico de notificación sobre cambios en los elementos del modelo (fig. 10). Como se puede ver, en términos generales es similar a los mecanismos de notificación implementados en el modelo de recursos y el modelo de Java, y utiliza IElementDelta para representar de manera unificada la información sobre el cambio de un elemento.
Fig. 10. Interfaces comunes e implementación básica del mecanismo de notificación de Handly
La parte de Handly discutida anteriormente (figs. 9 y 10) puede ser utilizada para representar prácticamente cualquier modelo basado en handle. Para la creación de lenguajes modelos, el proyecto ofrece funcionalidad adicional, en particular, interfaces comunes e implementaciones básicas para elementos de la estructura del texto fuente, denominados elementos fuente (fig. 8). La interfaz ISourceFile representa el archivo fuente, y ISourceConstruct es un elemento dentro del archivo fuente. Las clases abstractas SourceFile y SourceConstruct implementan mecanismos genéricos para apoyar el trabajo con archivos fuente y sus elementos, como el manejo de búferes de texto, la asignación a las coordenadas de un elemento en el texto fuente, la reconciliación del modelo con el contenido actual del búfer de la copia de trabajo, etc. La implementación de estos mecanismos suele ser una tarea bastante compleja, y Handly puede reducir significativamente el esfuerzo en el desarrollo de modelos basados en handle al proporcionar implementaciones básicas de alta calidad.
Además de los mecanismos principales mencionados anteriormente, Handly proporciona infraestructura para búferes de texto y «instantáneas» (snapshots), soporte para la integración con editores de código fuente (incluida la integración «lista para usar» con el editor Xtext), así como algunos componentes de UI comunes que funcionan con modelos basados en Handly, como el marco de esquema. Para ilustrar sus capacidades, el proyecto proporciona varios ejemplos, incluida la implementación de un modelo Java en Handly. (En comparación con la implementación completa del modelo Java en JDT, este modelo se ha simplificado intencionadamente para mayor claridad.)
Como se mencionó anteriormente, se ha prestado y continúa prestándose seriosa atención a la escalabilidad y flexibilidad durante el diseño inicial de Handly y su posterior desarrollo.
En principio, los modelos basados en handle escalan bastante bien «por diseño». Por ejemplo, la idiomática handle/body permite limitar la cantidad de memoria que consume el modelo. Pero hay ciertos matices. En las pruebas de escalabilidad de Handly, se descubrió un problema en la implementación del mecanismo de notificación: al modificar un gran número de elementos, la construcción de las diferencias tardaba demasiado tiempo. Se descubrió que el mismo problema estaba presente en el modelo Java de JDT, del cual se adaptó el código correspondiente en su momento. Corregimos el error en Handly y preparé un parche similar para JDT, que fue aceptado con gratitud. Este es solo un ejemplo de cómo la implementación de Handly en implementaciones existentes de modelos podría ser potencialmente útil, ya que en este caso se podría corregir dicho error en un solo lugar.
Para hacer posible la integración de Handly en implementaciones existentes de modelos, la biblioteca debe tener una gran flexibilidad. El principal desafío es mantener la compatibilidad hacia atrás en la API del modelo. Este problema se ha resuelto en mediante una clara separación de la API específica del modelo, que es definida y completamente controlada por el desarrollador, de la API unificada de nivel meta proporcionada por la biblioteca. Esto no solo hace posible desde el punto de vista técnico la integración de Handly en implementaciones existentes, sino que también otorga al desarrollador de un nuevo modelo una considerable libertad en el diseño de la API.
La flexibilidad también tiene otros aspectos. Por ejemplo, Handly impone casi ninguna limitación en la estructura del modelo y puede utilizarse tanto para modelar lenguajes de propósito general como lenguajes orientados a dominios específicos. Al construir la estructura del archivo fuente, Handly no prescribe ninguna forma específica de representación de AST y, en general, ni siquiera requiere la existencia misma de un AST, lo que garantiza así la compatibilidad con prácticamente cualquier mecanismo de análisis sintáctico. Finalmente, Handly soporta una integración completa con el espacio de trabajo de Eclipse, pero también puede trabajar directamente con sistemas de archivos, gracias a la integración con (EFS).
La versión actual se lanzó en diciembre de 2016. A pesar de que actualmente el proyecto se encuentra en estado de incubación y la API aún no está finalizada, Handly ya se utiliza en dos importantes productos comerciales que se arriesgaron a ser "early adopters", y, hay que decir, hasta ahora no se han arrepentido.
Como se mencionó 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 lenguajes 1C:Enterprise, como su lenguaje de programación integrado y lenguaje de consultas. El otro producto es menos conocido por el público en general. Es , un entorno integrado de diseño de procesadores orientados a problemas (application-specific instruction-set processor, ASIP), utilizado tanto dentro de la propia empresa checa Codasip como por sus clientes, entre los cuales se encuentran , , , . Codasip utiliza 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, quien lidera el desarrollo del IDE en Codasip, está en contacto con el proyecto, proporcionando retroalimentación crucial de los 'adoptantes externos'. Incluso ha logrado encontrar algo de tiempo libre para participar directamente en el desarrollo del proyecto, implementando una capa de UI (~ 4000 líneas de código) para uno de los ejemplos de Handly, un modelo Java. Más información de primera mano sobre el uso de Handly por parte de los adoptantes se puede obtener en la página del proyecto.
Esperamos que tras el lanzamiento de la versión 1.0 con garantía de estabilidad de la API y la salida del proyecto del estado de incubación, Handly tenga nuevos adoptantes. Mientras tanto, el proyecto sigue en pruebas y perfeccionando la API, lanzando dos 'grandes' versiones al año - en junio (en la misma fecha que el lanzamiento simultáneo de Eclipse) y en diciembre, asegurando un calendario predecible en el que los adoptantes pueden confiar. Además, el índice de 'tasa de errores' del proyecto se mantiene en un nivel consistentemente bajo y Handly ha funcionado de manera fiable en los productos de los adoptantes tempranos desde las primeras versiones. Para un conocimiento más profundo de Eclipse Handly, se puede utilizar y .
Fuente: habr.com
