Probablemente, hai tempo que non necesitaba presentación especial. Moitas persoas están familiarizadas con Eclipse grazas ás ferramentas de desenvolvemento Eclipse Java (). É este popular IDE Java de código aberto que a maioría dos desenvolvedores asocian coa palabra "Eclipse". Non obstante, Eclipse é tanto unha plataforma extensible para integrar ferramentas de desenvolvemento (Eclipse Platform) como unha serie de IDE construídos sobre a súa base, incluíndo JDT. Eclipse é tanto o Proxecto Eclipse, o proxecto de nivel superior que coordina o desenvolvemento da Plataforma Eclipse e o JDT, como o SDK Eclipse, o resultado entregado dese desenvolvemento. Finalmente, Eclipse é unha Fundación de código aberto cunha enorme comunidade de proxectos, non todos escritos en Java ou relacionados con ferramentas de desenvolvemento (por exemplo, proxectos и ). O mundo de Eclipse é moi diverso.
Neste artigo, de carácter xeral, trataremos de analizar algúns dos conceptos básicos da arquitectura Eclipse como plataforma para construír ferramentas de desenvolvemento integradas e dar unha idea inicial dos compoñentes de Eclipse que forman a base da tecnoloxía. plataforma para o “novo Configurador” 1C: Enterprise. . Por suposto, tal revisión será inevitablemente en gran medida superficial e bastante limitada, incluso porque nos centramos non só nos desenvolvedores de Eclipse como público obxectivo. Non obstante, esperamos que incluso os desenvolvedores experimentados de Eclipse poidan atopar información interesante no artigo. Por exemplo, falaremos dun dos “segredos de Eclipse”, un proxecto relativamente novo e pouco coñecido. , que foi fundada e apoiada por 1C.
Introdución á Arquitectura Eclipse
Vexamos primeiro algúns aspectos xerais da arquitectura Eclipse usando o exemplo (JDT). A elección de JDT como exemplo non é casual. Este é o primeiro ambiente de desenvolvemento integrado que aparece en Eclipse. Outros proxectos *DT Eclipse, como Eclipse C/C++ Development Tooling (CDT), creáronse máis tarde e toman prestados tanto principios arquitectónicos básicos como fragmentos individuais de código fonte de JDT. Os fundamentos da arquitectura establecidas en JDT son relevantes ata hoxe para case calquera IDE construído sobre a plataforma Eclipse, incluíndo 1C: Ferramentas de desenvolvemento empresarial.
En primeiro lugar, hai que ter en conta que Eclipse caracterízase por unha estratificación arquitectónica bastante clara, coa separación da funcionalidade independente da linguaxe da funcionalidade deseñada para soportar linguaxes de programación específicas e a separación dos compoñentes "núcleos" independentes da IU dos compoñentes asociados. con interface de usuario compatible.
Así, a plataforma Eclipse define unha infraestrutura común e independente da linguaxe, e as ferramentas de desenvolvemento de Java engaden un IDE Java completo a Eclipse. Tanto a plataforma Eclipse como o JDT constan de varios compoñentes, cada un dos cales pertence a un "núcleo" independente da IU ou a unha capa de IU (Figura 1).
Arroz. 1. Plataforma Eclipse e JDT
Imos enumerar os principais compoñentes da plataforma Eclipse:
- Tempo de execución — Define a infraestrutura do complemento. Eclipse caracterízase por unha arquitectura modular. Esencialmente, Eclipse é unha colección de "puntos de extensión" e "extensións".
- Espazo de traballo — Xestiona un ou varios proxectos. Un proxecto consta de cartafoles e ficheiros que se asignan directamente ao sistema de ficheiros.
- Kit de ferramentas de widget estándar (SWT) - Proporciona elementos básicos da interface de usuario integrados co sistema operativo.
- JFace — Ofrece unha serie de marcos de interface de usuario construídos sobre SWT.
- Workbench — Define o paradigma da interface de usuario de Eclipse: editores, vistas, perspectivas.
Hai que dicir que a plataforma Eclipse tamén ofrece moitos outros compoñentes útiles para construír ferramentas de desenvolvemento integradas, incluíndo Depuración, Comparación, Busca e Equipo. Mención especial merece a JFace Text - a base para construír "editores intelixentes" de código fonte. Desafortunadamente, nin sequera un exame superficial destes compoñentes, así como os compoñentes da capa da IU, non é posible no ámbito deste artigo, polo que no resto desta sección limitarémonos a unha visión xeral dos principais compoñentes "básicos" de a Plataforma Eclipse e JDT.
Core Runtime
A infraestrutura do complemento Eclipse está baseada e proporcionado polo proxecto . Cada complemento de Eclipse é un paquete OSGi. A especificación OSGi define, en particular, mecanismos de versión e resolución de dependencias. Ademais destes mecanismos estándar, Equinox introduce o concepto puntos de expansión. Cada complemento pode definir os seus propios puntos de extensión e tamén introducir funcionalidades adicionais ("extensións") ao sistema usando puntos de extensión definidos polo mesmo ou outros complementos. Calquera descrición detallada dos mecanismos OSGi e Equinox está fóra do alcance deste artigo. Teñamos en conta que a modularización en Eclipse é total (calquera subsistema, incluído o Runtime, consta dun ou máis engadidos), e case todo en Eclipse é unha extensión. Ademais, estes principios estaban integrados na arquitectura Eclipse moito antes da introdución de OSGi (naquel momento usaban a súa propia tecnoloxía, moi semellante a OSGi).
Espazo de traballo básico
Case calquera ambiente de desenvolvemento integrado construído sobre a plataforma Eclipse funciona co espazo de traballo de Eclipse. É o espazo de traballo que adoita conter o código fonte da aplicación desenvolvida no IDE. O espazo de traballo mapea directamente ao sistema de ficheiros e consiste en proxectos que conteñen cartafoles e ficheiros. Estes proxectos, cartafoles e ficheiros chámanse recursos espazo de traballo. A implementación do espazo de traballo en Eclipse serve como caché en relación co sistema de ficheiros, o que permite acelerar significativamente o percorrido da árbore de recursos. Ademais, o espazo de traballo ofrece unha serie de servizos adicionais, incluíndo и .
O compoñente Core Resources (complemento org.eclipse.core.resources) é o responsable de soportar o espazo de traballo e os seus recursos. En particular, este compoñente proporciona acceso mediante programación ao espazo de traballo no formulario modelos de recursos. Para traballar eficazmente con este modelo, os clientes necesitan un xeito sinxelo de presentar unha ligazón a un recurso. Neste caso, sería desexable ocultar o obxecto que almacena directamente o estado do recurso no modelo do acceso do cliente. En caso contrario, no caso de, por exemplo, eliminar un ficheiro, o cliente podería seguir mantendo un obxecto que xa non está no modelo, cos problemas conseguintes. Eclipse resolve este problema usando algo chamado manipular recurso. Handle actúa como clave (só coñece a ruta do recurso no espazo de traballo) e controla completamente o acceso ao obxecto do modelo interno, que almacena directamente información sobre o estado do recurso. Este deseño é unha variación do patrón .
Arroz. A figura 2 ilustra o idioma Handle/Body aplicado ao modelo de recursos. A interface IResource representa o identificador dun recurso e é unha API, a diferenza da clase Resource, que implementa esta interface, e a clase ResourceInfo, que representa o corpo, que non son API. Destacamos que o controlador só coñece a ruta do recurso en relación á raíz do espazo de traballo e non contén unha ligazón á información do recurso. Os obxectos de información de recursos forman a chamada "árbore de elementos". Esta estrutura de datos materialízase completamente na memoria. Para atopar a instancia de información do recurso correspondente a un identificador, percorre a árbore de elementos segundo o camiño almacenado nese identificador.
Arroz. 2. IResource e ResourceInfo
Como veremos máis adiante, o deseño básico do modelo de recursos (poderíamos chamalo baseado en manexos) tamén se usa en Eclipse para outros modelos. De momento, imos enumerar algunhas das propiedades distintivas deste deseño:
- Handle é un obxecto de valor. Os obxectos de valor son obxectos inmutables cuxa igualdade non se basea na identidade. Estes obxectos poden usarse con seguridade como chave en contedores hash. Varias instancias de handle poden facer referencia ao mesmo recurso. Para comparalos, cómpre usar o método equals(Object).
- Handle define o comportamento dun recurso, pero non contén información sobre o estado do recurso (os únicos datos que almacena é a "chave", o camiño ao recurso).
- O manexo pode referirse a un recurso que non existe (xa sexa un recurso que aínda non foi creado ou un recurso que xa foi eliminado). A existencia dun recurso pódese comprobar mediante o método IResource.exists().
- Algunhas operacións pódense implementar baseándose unicamente na información almacenada no propio identificador (as chamadas operacións de só manexo). Exemplos son IResource.getParent(), getFullPath(), etc. Non é necesario que exista o recurso para que tal operación teña éxito. As operacións que requiren que exista un recurso para ter éxito xeran unha CoreException se o recurso non existe.
Eclipse proporciona un mecanismo eficiente para notificar os cambios de recursos do espazo de traballo (Figura 3). Os recursos poden cambiar como resultado das accións realizadas dentro do propio IDE de Eclipse ou como resultado da sincronización co sistema de ficheiros. En ambos os casos, os clientes que se subscriben ás notificacións reciben información detallada sobre os cambios en forma de "deltas de recursos". Un delta describe os cambios entre dous estados dunha (sub)árbore de recursos de espazo de traballo e é en si mesma unha árbore, cada un dos cales describe un cambio nun recurso e contén unha lista de deltas no seguinte nivel que describe os cambios nos recursos fillos.
Arroz. 3. IResourceChangeEvent e IResourceDelta
O mecanismo de notificación baseado en deltas de recursos ten as seguintes características:
- Un único cambio e moitos cambios descríbense usando a mesma estrutura, xa que o delta constrúese usando o principio de composición recursiva. Os clientes subscritores poden procesar as notificacións de cambios de recursos mediante un descenso recursivo a través dunha árbore de deltas.
- O delta contén información completa sobre os cambios no recurso, incluíndo o seu movemento e/ou cambios nos "marcadores" asociados a el (por exemplo, os erros de compilación represéntanse como marcadores).
- Dado que as referencias de recursos fanse a través do identificador, delta pode facer referencia naturalmente a un recurso remoto.
Como veremos en breve, os compoñentes principais do deseño do mecanismo de notificación de cambios no modelo de recursos tamén son relevantes para outros modelos baseados en manexos.
Núcleo JDT
O modelo de recursos do espazo de traballo Eclipse é un modelo fundamental independente da linguaxe. O compoñente JDT Core (plugin org.eclipse.jdt.core) proporciona unha API para navegar e analizar a estrutura do espazo de traballo desde a perspectiva de Java, o chamado "modelo Java" (Modelo Java). Esta API defínese en termos de elementos Java, en oposición á API do modelo de recursos subxacente, que se define en termos de cartafoles e ficheiros. As interfaces principais da árbore de elementos Java móstranse na Fig. 4.
Arroz. 4. Elementos do modelo Java
O modelo Java usa o mesmo modo de manexo/corpo que o modelo de recursos (Figura 5). IJavaElement é o identificador e JavaElementInfo desempeña o papel de corpo. A interface IJavaElement define un protocolo común a todos os elementos Java. Algúns dos seus métodos son só de manipulación: getElementName(), getParent(), etc. O obxecto JavaElementInfo almacena o estado do elemento correspondente: a súa estrutura e atributos.
Arroz. 5. IJavaElement e JavaElementInfo
O modelo Java ten algunhas diferenzas na implementación do deseño básico de manexo/corpo en comparación co modelo de recursos. Como se indicou anteriormente, no modelo de recursos, a árbore de elementos, cuxos nodos son obxectos de información de recursos, está totalmente contida na memoria. Pero o modelo Java pode ter un número significativamente maior de elementos que a árbore de recursos, porque tamén representa a estrutura interna dos ficheiros .java e .class: tipos, campos e métodos.
Para evitar que se materialice completamente toda a árbore de elementos na memoria, a implementación do modelo Java usa unha caché LRU de tamaño limitado de información de elementos, onde a clave é manexar IJavaElement. Os obxectos de información de elementos créanse baixo demanda mentres se navega pola árbore de elementos. Neste caso, os elementos que se usan con menos frecuencia son expulsados da caché e o consumo de memoria do modelo permanece limitado ao tamaño da caché especificado. Esta é outra vantaxe do deseño baseado en manexos, que oculta completamente tales detalles de implementación do código do cliente.
O mecanismo para notificar cambios nos elementos Java é, en xeral, similar ao mecanismo para rastrexar os cambios nos recursos do espazo de traballo comentado anteriormente. Un cliente que desexa supervisar os cambios no modelo Java subscríbese ás notificacións, que se representan como un obxecto ElementChangedEvent que contén un IJavaElementDelta (Figura 6).
Arroz. 6. ElementChangedEvent e IJavaElementDelta
O modelo Java non contén información sobre os corpos do método ou a resolución de nomes, polo que para unha análise detallada do código escrito en Java, JDT Core ofrece un modelo adicional (non baseado en manexos): (árbore de sintaxe abstracta, AST). AST representa o resultado da análise do texto fonte. Os nodos AST corresponden a elementos da estrutura do módulo fonte (declaracións, operadores, expresións, etc.) e conteñen información sobre as coordenadas do elemento correspondente no texto fonte, así como (como opción) información sobre a resolución de nomes en a forma de ligazóns aos chamados encadernacións. As ligazóns son obxectos que representan entidades con nome, como tipos, métodos e variables, coñecidas polo compilador. A diferenza dos nodos AST, que forman unha árbore, as ligazóns admiten referencias cruzadas e xeralmente forman un gráfico. A clase abstracta ASTNode é a clase base común para todos os nodos AST. As subclases ASTNode corresponden a construcións sintácticas específicas da linguaxe Java.
Dado que as árbores de sintaxe poden consumir unha cantidade significativa de memoria, JDT almacena só un AST para o editor activo. A diferenza do modelo Java, o AST adoita ser visto como un modelo "intermedio" "temporal" cuxos membros non deben ser referenciados polos clientes fóra do contexto da operación que levou á creación do AST.
Os tres modelos enumerados (modelo Java, AST, enlaces) xuntos constitúen a base para construír "ferramentas de desenvolvemento intelixentes" en JDT, incluíndo un poderoso editor Java con varios "axudantes", varias accións para procesar o código fonte (incluída a organización dunha lista de importación). nomes e formato segundo o estilo personalizado), ferramentas de busca e refactorización. Neste caso, o modelo Java xoga un papel especial, xa que é o que se utiliza como base para unha representación visual da estrutura da aplicación que se está a desenvolver (por exemplo, no Explorador de paquetes, Esquema, Busca, Hierarquía de chamadas e Xerarquía de tipos).
Compoñentes de Eclipse utilizados en 1C: Ferramentas de desenvolvemento empresarial
Na Fig. A Figura 7 mostra os compoñentes de Eclipse que forman a base da plataforma tecnolóxica para 1C:Enterprise Development Tools.
Arroz. 7. Eclipse como plataforma para 1C: Ferramentas de Desenvolvemento Empresarial
Plataforma Eclipse proporciona infraestrutura básica. Na sección anterior analizamos algúns aspectos desta infraestrutura.
(EMF) proporciona un medio xeral para modelar datos estruturados. EMF está integrado coa plataforma Eclipse, pero tamén se pode usar por separado en aplicacións Java habituais. Moitas veces, os novos desenvolvedores de Eclipse xa están ben familiarizados con EMF, aínda que aínda non comprenden completamente as complejidades da plataforma Eclipse. Unha das razóns de tan merecida popularidade é o deseño universal, que inclúe, entre outras cousas, unha API unificada de meta-nivel, que permite traballar con calquera modelo EMF dun xeito xeral. As implementacións básicas para obxectos modelo proporcionadas por EMF e o subsistema para xerar código de modelo baseado no metamodelo aumentan significativamente a velocidade de desenvolvemento e reducen o número de erros. EMF tamén contén mecanismos para serializar modelos, rastrexar os cambios no modelo e moito máis.
Como calquera ferramenta de propósito xeral, a EMF é adecuada para resolver unha ampla gama de problemas de modelado, pero algunhas clases de modelos (por exemplo, os modelos baseados en manexos comentados anteriormente) poden requirir ferramentas de modelado máis especializadas. Falar de EMF é unha tarefa ingrata, especialmente dentro dos límites limitados dun artigo, xa que este é o tema dun libro separado e un bastante groso. Só teremos en conta que o sistema de xeneralizacións de alta calidade que subxace ao FEM permitiu o nacemento de toda unha serie de proxectos dedicados á modelización, que se inclúen no proxecto de primeiro nivel. xunto co propio EMF. Un destes proxectos é Eclipse Xtext.
proporciona unha infraestrutura de "modelado de texto". Xtext usa para analizar o texto fonte e EMF para representar o ASG resultante (gráfico semántico abstracto, que é esencialmente unha combinación de AST e enlaces), tamén chamado "modelo semántico". A gramática da linguaxe modelada por Xtext descríbese na lingua propia de Xtext. Isto permítelle non só xerar unha descrición gramatical para ANTLR, senón tamén obter un mecanismo de serialización AST (é dicir, Xtext proporciona un analizador e un desanalizador), unha suxestión de contexto e outros compoñentes da linguaxe. Por outra banda, a linguaxe gramatical utilizada en Xtext é menos flexible que, por exemplo, a linguaxe gramatical empregada en ANTLR. Polo tanto, ás veces é necesario "doblar" a linguaxe implementada a Xtext, o que normalmente non é un problema se estamos a falar dunha linguaxe que se está a desenvolver desde cero, pero pode ser inaceptable para linguas cunha sintaxe xa establecida. A pesar diso, Xtext é actualmente a ferramenta máis madura, rica en funcións e versátil de Eclipse para crear linguaxes de programación e ferramentas de desenvolvemento para eles. En particular, é unha ferramenta ideal para a creación rápida de prototipos (idioma específico do dominio, DSL). Ademais do mencionado "núcleo da linguaxe" baseado en ANTLR e EMF, Xtext ofrece moitos compoñentes útiles de nivel superior, incluíndo mecanismos de indexación, construción incremental, un "editor intelixente" e moito, moito máis, pero deixa fóra os manexos. modelos lingüísticos baseados. Do mesmo xeito que EMF, Xtext é un tema digno dun libro aparte, e case non podemos falar brevemente de todas as súas capacidades neste momento.
1C: As ferramentas de desenvolvemento empresarial usan activamente tanto o propio EMF como outros proxectos de modelado de Eclipse. En particular, Xtext é un dos fundamentos das ferramentas de desenvolvemento para linguaxes 1C:Enterprise como a linguaxe de programación incorporada e a linguaxe de consulta. Outra base para estas ferramentas de desenvolvemento é o proxecto Eclipse Handly, do que comentaremos con máis detalle (dos compoñentes de Eclipse enumerados, aínda é o menos coñecido).
, un subproxecto do proxecto de alto nivel Eclipse Technology, xurdiu como resultado dunha contribución inicial de código á Fundación Eclipse feita por 1C en 2014. Desde entón, 1C continuou apoiando o desenvolvemento do proxecto: os Handly committers son empregados da empresa. O proxecto é pequeno, pero ocupa un nicho bastante único en Eclipse: o seu obxectivo principal é apoiar o desenvolvemento de modelos baseados en asa.
Os principios arquitectónicos básicos dos modelos baseados en manexos, como o idioma manexo/corpo, foron discutidos anteriormente usando o modelo de recursos e o modelo Java como exemplos. Tamén observou que tanto o modelo de recursos como o modelo Java son fundamentos importantes para as ferramentas de desenvolvemento Java (JDT) de Eclipse. E dado que case todos os proxectos *DT Eclipse teñen unha arquitectura similar á JDT, non sería unha gran esaxeración dicir que os modelos baseados en manexos subxacen en moitos, se non en todos, IDE construídos sobre a plataforma Eclipse. Por exemplo, o Eclipse C/C++ Development Tooling (CDT) ten un modelo C/C++ baseado en manexos que xoga o mesmo papel na arquitectura CDT que o modelo Java no JDT.
Antes de Handly, Eclipse non ofrecía bibliotecas especializadas para construír modelos de linguaxe baseados en identificadores. Os modelos que existen actualmente creáronse principalmente adaptando directamente o código do modelo Java (tamén coñecido como copiar/pegar), nos casos en que o permita Licenza pública Eclipse (EPL). (Obviamente, isto non adoita ser un problema legal para, por exemplo, os proxectos de Eclipse en si, pero non para os produtos de código pechado.) Ademais da súa inherente azar, esta técnica introduce problemas coñecidos: a duplicación de código introducida por cando se adapta a erros, etc. O peor é que os modelos resultantes seguen sendo "cousas en si" e non aproveitan o potencial de unificación. Pero illar conceptos e protocolos comúns para modelos de linguaxe baseados en manexos podería levar á creación de compoñentes reutilizables para traballar con eles, de xeito similar ao que ocorreu no caso dos EMF.
Non é que Eclipse non entendese estes problemas. Alá polo 2005 , que resume a experiencia no desenvolvemento do prototipo CDT, a necesidade de crear unha infraestrutura común para os modelos lingüísticos, incluídos os modelos baseados en manexos. Pero, como adoita suceder, debido ás tarefas de maior prioridade, a posta en práctica destas ideas nunca chegou a iso. Mentres tanto, a factorización do código *DT aínda é un dos temas pouco desenvolvidos en Eclipse.
En certo sentido, o proxecto Handly está deseñado para resolver aproximadamente os mesmos problemas que EMF, pero para modelos baseados en manexos, e principalmente os de linguaxe (é dicir, que representan elementos da estrutura dalgunha linguaxe de programación). Os principais obxectivos establecidos ao deseñar Handly enuméranse a continuación:
- Identificación das principais abstraccións da área temática.
- Reducir o esforzo e mellorar a calidade da implementación de modelos de linguaxe baseados en manexos mediante a reutilización de código.
- Proporcionar unha API de metanivel unificada aos modelos resultantes, facendo posible crear compoñentes IDE comúns que funcionen con modelos baseados en manexos de linguaxe.
- Flexibilidade e escalabilidade.
- Integración con Xtext (nunha capa separada).
Para destacar conceptos e protocolos comúns, analizáronse as implementacións existentes de modelos baseados en manexos de linguaxe. As interfaces principais e as implementacións básicas proporcionadas por Handly móstranse na Fig. 8.
Arroz. 8. Interfaces comúns e implementacións básicas de elementos Handly
A interface IElement representa o identificador dun elemento e é común aos elementos de todos os modelos baseados en Handly. A clase abstracta Element implementa o mecanismo de asa/corpo xeneralizado (Fig. 9).
Arroz. 9. IElement e implementación de handle/body xenérico
Ademais, Handly ofrece un mecanismo xeneralizado para notificar cambios nos elementos do modelo (Fig. 10). Como podes ver, é moi similar aos mecanismos de notificación implementados no modelo de recursos e no modelo Java, e usa IElementDelta para proporcionar unha representación unificada da información de cambio de elementos.
Arroz. 10. Interfaces xerais e implementacións básicas do mecanismo de notificación Handly
A parte Handly comentada anteriormente (Fig. 9 e 10) pódese usar para representar case calquera modelo baseado en asa. Para crear lingüístico modelos, o proxecto ofrece unha funcionalidade adicional, en particular, interfaces comúns e implementacións básicas para elementos da estrutura do texto fonte, os chamados elementos fonte (Fig. 8). A interface ISourceFile representa un ficheiro fonte e ISourceConstruct representa un elemento dentro do ficheiro fonte. As clases abstractas SourceFile e SourceConstruct implementan mecanismos xeneralizados para soportar o traballo con ficheiros fonte e os seus elementos, por exemplo, traballar con búfers de texto, vincularse ás coordenadas dun elemento no texto fonte, conciliar modelos co contido actual dun búfer de copia de traballo. , etc. Implementar estes mecanismos adoita ser todo un reto, e Handly pode reducir significativamente o esforzo de desenvolver modelos de linguaxe baseados en manexos proporcionando implementacións básicas de alta calidade.
Ademais dos mecanismos principais enumerados anteriormente, Handly ofrece unha infraestrutura para búfers de texto e instantáneas, soporte para a integración con editores de código fonte (incluída a integración lista co editor Xtext), así como algúns compoñentes comúns da IU que traballar con editores de código fonte Modelos prácticos como o marco de esquema. Para ilustrar as súas capacidades, o proxecto ofrece varios exemplos, incluíndo unha implementación do modelo Java en Handly. (En comparación coa implementación completa do modelo Java en JDT, este modelo simplifícase intencionalmente un pouco para unha maior claridade).
Como se indicou anteriormente, un foco principal durante o deseño inicial de Handly e o desenvolvemento posterior foi e segue sendo a escalabilidade e flexibilidade.
En principio, os modelos baseados en asa escalan bastante ben "por deseño". Por exemplo, a expresión de asa/corpo permítelle limitar a cantidade de memoria consumida por un modelo. Pero tamén hai matices. Así, ao probar a escalabilidade de Handly, descubriuse un problema na implementación do mecanismo de notificación: cando se cambiou un gran número de elementos, a construción de deltas levou demasiado tempo. Resultou que o mesmo problema estaba presente no modelo Java de JDT, do que unha vez se adaptou o código correspondente. Arranxamos o erro en Handly e preparamos un parche similar para JDT, que foi recibido con gratitude. Este é só un exemplo no que a introdución de Handly nas implementacións de modelos existentes podería ser potencialmente útil, porque neste caso tal erro podería solucionarse nun só lugar.
Para facer que a implementación de Handly nas implementacións de modelos existentes sexa tecnicamente viable, a biblioteca debe ter unha flexibilidade significativa. O principal problema é manter a compatibilidade con versións anteriores no modelo de API. Este problema resolveuse en separando claramente a API específica do modelo, definida e totalmente controlada polo programador, da API de metanivel unificada proporcionada pola biblioteca. Isto non só fai que tecnicamente sexa posible implementar Handly nas implementacións existentes, senón que tamén dá ao desenvolvedor do novo modelo unha liberdade significativa á hora de deseñar a API.
A flexibilidade tamén ten outros aspectos. Por exemplo, Handly case non impón restricións á estrutura do modelo e pódese usar para modelar linguaxes de propósito xeral e específicas de dominio. Ao construír a estrutura do ficheiro fonte, Handly non prescribe ningunha forma particular de representación AST e, en principio, nin sequera require a presenza dun propio AST, garantindo así a compatibilidade con case calquera mecanismo de análise. Finalmente, Handly admite a integración total co espazo de traballo Eclipse, pero tamén pode traballar directamente con sistemas de ficheiros grazas á súa integración con (EFS).
Versión actual saíu en decembro de 2016. A pesar de que o proxecto está actualmente en estado de incubación e a API aínda non se arranxou definitivamente, Handly xa se utiliza en dous grandes produtos comerciais que correron o risco de actuar como “early adopters” e, debo dicir, aínda non te arrepintes.
Como se indicou anteriormente, un destes produtos é 1C:Enterprise Development Tools, onde Handly se usa dende o principio para modelar elementos da estrutura de alto nivel de tales linguaxes 1C:Enterprise como a linguaxe de programación e a linguaxe de consulta incorporadas. . Outro produto é menos coñecido polo gran público. Isto , un entorno de deseño integrado para o procesador de conxuntos de instrucións específicos da aplicación (ASIP), utilizado tanto na propia empresa checa Codasip como polos seus clientes, incluíndo , , , . Codasip leva empregando Handly en produción desde 2015, comezando coa versión Handly 0.2. A última versión de Codasip Studio usa a versión 0.5, publicada en xuño de 2016. Ondřej Ilčík, que dirixe o desenvolvemento de IDE en Codasip, está en contacto co proxecto, proporcionando comentarios vitais en nome do "terceiro adoptador". Incluso puido atopar tempo libre para participar directamente no desenvolvemento do proxecto, implementando unha capa de IU (~4000 liñas de código) para un dos exemplos de Handly, un modelo Java. Na páxina pódese atopar información de primeira man máis detallada sobre o uso de Handly por parte dos adoptantes proxecto.
Agardamos que despois do lanzamento da versión 1.0 con garantía de estabilidade da API e que o proxecto abandone o estado de incubación, Handly teña novos adoptantes. Mentres tanto, o proxecto continúa probando e mellorando aínda máis a API, lanzando dous lanzamentos "principais" ao ano: en xuño (a mesma data que o lanzamento simultáneo de Eclipse) e decembro, proporcionando un calendario previsible no que os usuarios poden confiar. Tamén podemos engadir que a "taxa de erros" do proxecto permanece nun nivel constantemente baixo e Handly estivo traballando de forma fiable nos produtos dos primeiros usuarios desde as primeiras versións. Para explorar máis a fondo Eclipse Handly, podes usar и .
Fonte: www.habr.com