Provavelmente, já não precisa de apresentações especiais. Muitos conhecem o Eclipse graças às ferramentas de desenvolvimento Java do Eclipse (). É esta popular IDE Java de código aberto que a maioria dos desenvolvedores associa à palavra “Eclipse”. No entanto, o Eclipse também é uma plataforma extensível para integração de ferramentas de desenvolvimento (Eclipse Platform) e uma série de IDEs construídas sobre sua base, incluindo o JDT. O Eclipse abrange o Eclipse Project, um projeto de alto nível que coordena o desenvolvimento do Eclipse Platform e do JDT, e o Eclipse SDK – o resultado desta pesquisa. Finalmente, o Eclipse é uma Fundação open-source com uma enorme comunidade de projetos, muitos dos quais não são escritos em Java ou não estão relacionados a ferramentas de desenvolvimento (por exemplo, projetos e ). O mundo do Eclipse é muito diversificado.
Neste artigo, que tem um caráter de visão geral, tentaremos abordar algumas das bases da arquitetura do Eclipse como plataforma para a construção de ferramentas de desenvolvimento integradas e dar uma visão inicial sobre os componentes do Eclipse que formam a base da plataforma tecnológica para o ‘novo Configurador’ 1C: Enterprise, . Claro, tal análise será inevitavelmente superficial e bastante limitada, também porque estamos mirando não apenas os desenvolvedores do Eclipse como público-alvo. No entanto, esperamos que até mesmo desenvolvedores experientes do Eclipse possam encontrar informações interessantes no artigo. Por exemplo, falaremos sobre um dos 'segredos do Eclipse', um projeto relativamente novo e pouco conhecido até agora, , que foi fundado e mantido pela empresa 1C.
Introdução à arquitetura do Eclipse
Vamos começar por examinar alguns aspectos gerais da arquitetura do Eclipse usando como exemplo (JDT). A escolha do JDT como exemplo não é acidental. Esta foi a primeira plataforma de desenvolvimento integrada a surgir no Eclipse. Os outros projetos *DT do Eclipse, como o Eclipse C/C++ Development Tooling (CDT), foram criados posteriormente e tomaram emprestados tanto os princípios arquiteturais fundamentais quanto fragmentos específicos do código-fonte do JDT. As bases da arquitetura estabelecidas no JDT permanecem relevantes até hoje para praticamente qualquer IDE construída sobre a Eclipse Platform, incluindo o 1C:Enterprise Development Tools.
Em primeiro lugar, é importante notar que o Eclipse apresenta uma arquitetura bem definida, com a separação da funcionalidade independente de linguagem da funcionalidade destinada ao suporte de linguagens de programação específicas e a separação dos componentes "core" independentes da UI dos componentes relacionados ao suporte da interface do usuário.
Assim, a Eclipse Platform define uma infraestrutura geral e independente de linguagem, enquanto as ferramentas de desenvolvimento Java adicionam ao Eclipse uma IDE Java totalmente funcional. Tanto a Eclipse Platform quanto o JDT consistem em vários componentes, cada um dos quais pertence ao "núcleo" independente de UI ou à camada de UI (Fig. 1).
Fig. 1. Eclipse Platform e JDT
Vamos listar os principais componentes da Eclipse Platform:
- Runtime — Define a infraestrutura de plugins. O Eclipse é caracterizado por uma arquitetura modular. Basicamente, o Eclipse é uma coleção de "pontos de extensão" e "extensões".
- Workspace — Gerencia um ou vários projetos. Um projeto consiste em pastas e arquivos que são mapeados diretamente para o sistema de arquivos.
- Standard Widget Toolkit (SWT) — Fornece os elementos básicos da interface do usuário, integrados ao sistema operacional.
- JFace — Fornece uma série de frameworks UI construídos sobre o SWT.
- Workbench — Define a paradigma de UI do Eclipse: editores, visões, perspectivas.
É necessário mencionar que a Eclipse Platform também fornece muitos outros componentes úteis para a construção de ferramentas de desenvolvimento integradas, entre os quais se destacam Debug, Compare, Search e Team. Vale a pena mencionar o JFace Text - a base para a construção de "editores inteligentes" de código fonte. Infelizmente, mesmo uma visão rápida desses componentes, assim como dos componentes da camada de UI, não é possível dentro do escopo deste artigo, portanto, na parte restante desta seção, limitaremos nossa discussão aos principais componentes "core" da Eclipse Platform e do JDT.
Core Runtime
A infraestrutura de plugins do Eclipse é baseada em e é fornecida pelo projeto . Cada plugin do Eclipse é um bundle OSGi. A especificação OSGi define, entre outras coisas, mecanismos de versionamento e resolução de dependências. Além desses mecanismos padrão, o Equinox introduz o conceito de ponto de extensão. Cada plugin pode definir seus próprios pontos de extensão, além de trazer funcionalidade adicional ao sistema ("extensões"), utilizando pontos de extensão definidos por esse ou outros plugins. Uma descrição mais detalhada dos mecanismos OSGi e Equinox vai além do escopo deste artigo. Vale ressaltar que a modularização no Eclipse é total (qualquer subsistema, incluindo o Runtime, consiste em um ou mais plugins), e praticamente tudo no Eclipse é uma extensão. Além disso, esses princípios foram incorporados à arquitetura do Eclipse muito antes da implementação do OSGi (naquela época, uma tecnologia própria, em grande parte análoga ao OSGi, era utilizada).
Espaço de Trabalho Principal
Praticamente qualquer ambiente de desenvolvimento integrado baseado na Eclipse Platform opera com o espaço de trabalho do Eclipse. É neste espaço de trabalho que o código-fonte do aplicativo desenvolvido na IDE geralmente reside. O espaço de trabalho se reflete diretamente no sistema de arquivos e consiste em projetos, que contêm pastas e arquivos. Esses projetos, pastas e arquivos são chamados de recursos O espaço de trabalho. A implementação do espaço de trabalho no Eclipse funciona como um cache em relação ao sistema de arquivos, o que permite acelerar significativamente a travessia da árvore de recursos. Além disso, o espaço de trabalho fornece uma série de serviços adicionais, incluindo e .
A manutenção do espaço de trabalho e seus recursos é responsabilidade do componente Core Resources (plugin org.eclipse.core.resources). Em particular, esse componente fornece acesso programático ao espaço de trabalho na forma de um modelo de recursos. Para um trabalho eficiente com esse modelo, os clientes precisam de uma maneira simples de representar uma referência a um recurso. Ao mesmo tempo, seria desejável esconder o objeto que armazena diretamente o estado do recurso no modelo do acesso do cliente. Caso contrário, em caso de, por exemplo, exclusão de um arquivo, o cliente poderia continuar segurando um objeto que já não existe no modelo, causando problemas subsequentes. O Eclipse resolve essa questão usando o chamado handle do recurso. O handle atua como uma chave (ele conhece apenas o caminho para o recurso no espaço de trabalho) e controla completamente o acesso ao objeto interno do modelo que armazena diretamente as informações sobre o estado do recurso. Esse design é uma variação do padrão .
A Figura 2 ilustra a expressão Handle/Body em relação ao modelo de recursos. A interface IResource representa o handle do recurso e é uma API, ao contrário da classe Resource, que implementa essa interface, e da classe ResourceInfo, que representa o body e não é uma API. É importante ressaltar que o handle apenas conhece o caminho para o recurso em relação à raiz do workspace e não contém referência à resource info. Os objetos de resource info formam a chamada "árvore de elementos" (element tree). Essa estrutura de dados é completamente materializada na memória. Para encontrar uma instância de resource info correspondente a um determinado handle, a árvore de elementos é percorrida de acordo com o caminho armazenado nesse handle.
Figura 2. IResource e ResourceInfo
Como veremos a seguir, o design básico do modelo de recursos (que pode ser chamado de baseado em handle) é utilizado no Eclipse e em outros modelos. Por enquanto, vamos listar algumas propriedades distintas desse design:
- O handle é um objeto-valor (value object). Objetos-valor são objetos imutáveis (immutable), cuja igualdade não se baseia na identidade. Esses objetos podem ser usados com segurança como chave em contêineres hash. Vários instâncias de handle podem referenciar o mesmo recurso. Para compará-los, deve-se usar o método equals(Object).
- O handle define o comportamento do recurso, mas não contém informações sobre o estado do recurso (os únicos dados que ele armazena são a "chave", o caminho para o recurso).
- O handle pode referenciar um recurso inexistente (ou seja, um recurso que ainda não foi criado ou um recurso que já foi deletado). A existência do recurso pode ser verificada usando o método IResource.exists().
- Algumas operações podem ser implementadas com base exclusivamente nas informações armazenadas no próprio handle (as chamadas operações somente de handle). Exemplos incluem IResource.getParent(), getFullPath(), etc. O recurso não precisa existir para que essa operação seja realizada com sucesso. Operações que exigem que o recurso exista para serem executadas com sucesso lançam uma exceção (CoreException) se o recurso não existir.
Eclipse oferece um mecanismo eficiente de notificação sobre alterações nos recursos do workspace (fig. 3). Os recursos podem ser alterados tanto devido a ações realizadas na própria IDE Eclipse quanto em decorrência da sincronização com o sistema de arquivos. Em ambos os casos, os clientes que se inscreveram para as notificações recebem informações detalhadas sobre as alterações na forma de "deltas de recurso" (resource delta). Um delta descreve as mudanças entre dois estados de uma (sub)árvore de recursos do workspace e é, ele mesmo, uma árvore, onde cada nó descreve a alteração de um recurso e contém uma lista de deltas de nível inferior que descrevem as alterações dos recursos filhos.
Fig. 3. IResourceChangeEvent e IResourceDelta
O mecanismo de notificação baseado em deltas de recurso possui as seguintes características:
- Uma única alteração e múltiplas alterações são descritas com a mesma estrutura, uma vez que o delta é construído com base na composição recursiva. Os clientes assinantes podem processar notificações de alteração de recursos através de uma descida recursiva pela árvore de deltas.
- O delta contém informações completas sobre a alteração do recurso, incluindo seu deslocamento e/ou alteração dos "marcadores" associados (por exemplo, erros de compilação se apresentam na forma de marcadores).
- Como as referências ao recurso são feitas através de um handle, o delta pode naturalmente referenciar um recurso remoto.
Como veremos em breve, os principais componentes do design do mecanismo de notificação de alteração do modelo de recursos são relevantes também para outros modelos baseados em handle.
JDT Core
O modelo de recursos do Eclipse workspace é um modelo fundamental independente de linguagem. O componente JDT Core (plugin org.eclipse.jdt.core) fornece uma API para navegação e análise da estrutura do workspace do ponto de vista do Java, a chamada "modelo Java" (modelo Java). Esta API é definida em termos de elementos Java, ao contrário da API subjacente do modelo de recursos, que é definida em termos de pastas e arquivos. As principais interfaces da árvore de elementos Java estão ilustradas na fig. 4.
Fig. 4. Elementos do modelo Java
O modelo Java utiliza a mesma idiomática handle/body que o modelo de recursos (fig. 5). IJavaElement é o handle, enquanto JavaElementInfo desempenha o papel de body. A interface IJavaElement define o protocolo comum a todos os elementos Java. Alguns de seus métodos são apenas handle: getElementName(), getParent(), etc. O objeto JavaElementInfo armazena o estado do respectivo elemento: sua estrutura e atributos.
Fig. 5. IJavaElement e JavaElementInfo
O modelo Java apresenta algumas diferenças na implementação do design básico handle/body em comparação com o modelo de recursos. Como mencionado anteriormente, no modelo de recursos, a árvore de elementos, cujos nós são objetos de informações de recursos, é totalmente mantida na memória. Mas no modelo Java, pode haver um número significativamente maior de elementos do que na árvore de recursos, uma vez que ele também representa a estrutura interna dos arquivos .java e .class: tipos, campos e métodos.
Para evitar a materialização completa de toda a árvore de elementos na memória, a implementação do modelo Java utiliza um cache de informações de elementos LRU de tamanho limitado, onde a chave é o handle IJavaElement. Objetos de informações de elementos são criados sob demanda conforme a navegação pela árvore de elementos ocorre. Os elementos menos frequentemente usados são expulsos do cache, e o consumo de memória pelo modelo permanece limitado ao tamanho definido do cache. Esta é mais uma vantagem do design baseado em handle, que oculta totalmente esses detalhes de implementação do código do cliente.
O mecanismo de notificação de alterações nos elementos Java é, em linhas gerais, análogo ao mecanismo de rastreamento de alterações de recursos do workspace mencionado acima. Um cliente que deseja monitorar alterações no modelo Java inscreve-se nas notificações, que são apresentadas como um objeto ElementChangedEvent, contendo IJavaElementDelta (fig. 6).
Fig. 6. ElementChangedEvent e IJavaElementDelta
O modelo Java não contém informações sobre o corpo dos métodos ou sobre a resolução de nomes, portanto, para uma análise detalhada do código escrito em Java, o JDT Core fornece um modelo adicional (não baseado em handle): (árvore de sintaxe abstrata, AST). AST representa o resultado da análise sintática do texto-fonte. Os nós da AST correspondem aos elementos da estrutura do módulo-fonte (declarações, operadores, expressões, etc.) e contêm informações sobre as coordenadas do respectivo elemento no texto-fonte, além de (opcionalmente) informações sobre a resolução de nomes na forma de referências aos chamados binds. Os binds são objetos que representam entidades nomeadas, como tipos, métodos e variáveis conhecidos pelo compilador. Ao contrário dos nós da AST, que formam uma árvore, os binds suportam referências cruzadas e, em geral, formam um grafo. A classe abstrata ASTNode é a classe base comum para todos os nós da AST. Os subclasses de ASTNode correspondem a construções sintáticas específicas da linguagem Java.
Como as árvores sintáticas podem consumir uma quantidade significativa de memória, o JDT armazena em cache apenas um AST para o editor ativo. Ao contrário do modelo Java, a AST geralmente é vista como um modelo "intermediário", "temporário", cujos elementos não devem ser referenciados fora do contexto da operação que levou à criação da AST.
Os três modelos listados (modelo Java, AST, binds) juntos formam a base para a construção de "ferramentas de desenvolvimento inteligentes" no JDT, incluindo um poderoso editor Java com diversos "assistentes", várias ações para processamento de código-fonte (incluindo organização da lista de importação de nomes e formatação de acordo com o estilo configurado), ferramentas de busca e refatoração. O modelo Java desempenha um papel especial, pois é utilizado como base para a representação visual da estrutura do aplicativo em desenvolvimento (por exemplo, no Package Explorer, Outline, Search, Call Hierarchy e Type Hierarchy).
Componentes do Eclipse utilizados em Ferramentas de Desenvolvimento 1C:Enterprise
Na Fig. 7, os componentes do Eclipse que formam a fundação da plataforma tecnológica para Ferramentas de Desenvolvimento 1C:Enterprise são mostrados.
Fig. 7. Eclipse como plataforma para Ferramentas de Desenvolvimento 1C:Enterprise
Plataforma Eclipse fornece a infraestrutura básica. Discutimos alguns aspectos dessa infraestrutura na seção anterior.
(EMF) fornece ferramentas gerais para modelagem de dados estruturados. O EMF está integrado à plataforma Eclipse, mas pode ser usado separadamente em aplicações Java comuns. Muitas vezes, desenvolvedores iniciantes do Eclipse já estão bem familiarizados com o EMF, embora ainda não compreendam completamente as sutilezas da plataforma Eclipse. Uma das razões para essa merecida popularidade é o design universal, que inclui, entre outras coisas, uma API unificada de nível meta, permitindo trabalhar de forma generalizada com qualquer modelo EMF. As implementações básicas do EMF para objetos de modelo e o subsistema de geração de código de modelo a partir da meta-modelagem aumentam significativamente a velocidade de desenvolvimento e reduzem a quantidade de erros. O EMF também contém mecanismos de serialização de modelos, monitoramento de alterações no modelo, entre muitas outras funcionalidades.
Como qualquer ferramenta realmente universal, o EMF é adequado para resolver uma ampla gama de tarefas relacionadas à modelagem, mas algumas classes de modelos (por exemplo, os modelos baseados em handle discutidos acima) podem precisar de ferramentas de modelagem mais especializadas. Falar sobre o EMF é uma tarefa ingrata, especialmente nos limites de um único artigo, pois este é um tema para um livro inteiramente separado e bastante extenso. Devemos apenas mencionar que um sistema de generalizações de alta qualidade, que serve de base para o EMF, possibilitou o surgimento de uma ampla gama de projetos dedicados à modelagem, que fazem parte do projeto de alto nível. juntamente com o próprio EMF. Um desses projetos é o Eclipse Xtext.
fornece infraestrutura de "modelagem textual". O Xtext utiliza para a análise sintática do texto fonte e EMF para representar o ASG resultante (grafo semântico abstrato, que, essencialmente, é uma combinação de AST e bindings), também chamado de "modelo semântico". A gramática da linguagem modelada com Xtext é descrita em sua própria linguagem Xtext. Isso permite não apenas gerar uma descrição da gramática para ANTLR, mas também obter um mecanismo de serialização do AST (ou seja, o Xtext fornece tanto o parser quanto o unparser), sugestões contextuais e uma série de outros componentes linguísticos. Por outro lado, a linguagem de descrição da gramática usada no Xtext é menos flexível em comparação, digamos, com a linguagem de descrição da gramática no ANTLR. Portanto, às vezes é necessário "adaptar" a linguagem implementada para o Xtext, o que geralmente não é um problema se se trata de uma linguagem desenvolvida do zero, mas pode ser inaceitável para linguagens com uma sintaxe já estabelecida. Apesar disso, o Xtext é atualmente a ferramenta mais madura, funcionalmente completa e versátil no Eclipse para construir linguagens de programação e ferramentas de desenvolvimento para elas. Em particular, é a ferramenta ideal para prototipagem rápida. (linguagem específica de domínio, DSL). Além do "núcleo linguístico" mencionado acima, baseado em ANTLR e EMF, o Xtext fornece muitos componentes úteis de nível mais alto, incluindo mecanismos de indexação, construção incremental, "editor inteligente" e muito, muito mais, mas deixa de lado modelos baseados em handle. Assim como o EMF, o Xtext é um tema que mereceria um livro à parte, e é improvável que consigamos sequer abordar rapidamente todas as suas capacidades agora.
1С:Enterprise Development Tools utiliza ativamente tanto o EMF em si, quanto uma série de outros projetos da Eclipse Modeling. Em particular, o Xtext é uma das bases das ferramentas de desenvolvimento para linguagens como 1С:Предприятие, como a linguagem de programação embutida e a linguagem de consultas. Outra base dessas ferramentas de desenvolvimento é o projeto Eclipse Handly, sobre o qual falaremos com mais detalhes (dos componentes listados do Eclipse, este é o menos conhecido até agora).
, um subprojeto do projeto de alto nível Eclipse Technology, surgiu a partir da contribuição inicial de código para a Eclipse Foundation, feita pela empresa 1C em 2014. Desde então, a empresa 1C continua a apoiar o desenvolvimento do projeto: os committers do Handly são funcionários da empresa. O projeto é pequeno, mas ocupa uma nicho bastante único no Eclipse: seu principal objetivo é apoiar o desenvolvimento de modelos baseados em handle.
Os principais princípios arquitetônicos dos modelos baseados em handle, como a idiomática handle/body, foram discutidos anteriormente usando o exemplo do modelo de recursos e do modelo Java. Também foi observado que tanto o modelo de recursos quanto o modelo Java são bases importantes para as ferramentas de desenvolvimento Java do Eclipse (JDT). E como praticamente todos os projetos *DT do Eclipse têm uma arquitetura semelhante à do JDT, não seria uma grande exageração afirmar que os modelos baseados em handle estão na base de muitos, se não todos, os IDEs construídos sobre a Eclipse Platform. Por exemplo, no Eclipse C/C++ Development Tooling (CDT), há um modelo baseado em handle para C/C++, que desempenha na arquitetura do CDT o mesmo papel que o modelo Java no JDT.
Antes da chegada do Handly, o Eclipse não oferecia bibliotecas especializadas para a construção de modelos de linguagem baseados em handle. Os modelos existentes agora foram criados principalmente por meio da adaptação direta do código do modelo Java (ou seja, copiar/colar), nos casos em que isso é permitido pela Eclipse Public License (EPL). (É claro que, por exemplo, para os projetos da própria Eclipse isso normalmente não representa um problema do ponto de vista jurídico, o que não pode ser dito sobre produtos de código fechado.) Além da falta de sistematicidade, essa abordagem leva a problemas bem conhecidos: duplicação de código, erros introduzidos durante a adaptação, etc. O que é ainda pior, os modelos resultantes permanecem como 'coisas em si' e não utilizam o potencial existente para unificação. E a identificação de conceitos e protocolos comuns para modelos de linguagem baseados em handle poderia levar à criação de componentes reutilizáveis para trabalhar com eles, assim como ocorreu no caso do EMF.
Não se pode dizer que no Eclipse não houvesse uma compreensão desses problemas. Já em 2005 , resumindo a experiência de desenvolvimento do protótipo do CDT, a necessidade de criar uma infraestrutura comum para modelos de linguagem, incluindo modelos baseados em identificadores. Mas, como muitas vezes acontece, devido a tarefas mais prioritárias, essas ideias não foram implementadas na época. Entretanto, a fatoração de código *DT-projetos ainda permanece um dos temas pouco explorados no Eclipse.
De certa forma, o projeto Handly se propõe a resolver tarefas semelhantes às do EMF, mas para modelos baseados em identificadores, e, em primeiro lugar, modelos linguísticos (ou seja, representando elementos da estrutura de alguma linguagem de programação). Abaixo estão listados os principais objetivos que foram estabelecidos durante o projeto do Handly:
- Identificar as principais abstrações da área de domínio.
- Reduzir esforços e aumentar a qualidade da implementação de modelos linguísticos baseados em identificadores através da reutilização de código.
- Fornecer uma API unificada em nível meta para os modelos resultantes, permitindo a criação de componentes IDE comuns que trabalham com modelos linguísticos baseados em identificadores.
- Flexibilidade e escalabilidade.
- Integração com o Xtext (em uma camada separada).
Para identificar conceitos e protocolos comuns, foram analisadas implementações existentes de modelos linguísticos baseados em identificadores. As principais interfaces e implementações básicas fornecidas pelo Handly são mostradas na Fig. 8.
Fig. 8. Interfaces comuns e implementações básicas dos elementos Handly
A interface IElement representa o identificador de um elemento e é comum a elementos de todos os modelos baseados no Handly. A classe abstrata Element implementa um mecanismo genérico de identificador/corpo (Fig. 9).
Fig. 9. IElement e implementação genérica de identificador/corpo
Além disso, o Handly fornece um mecanismo genérico de notificação sobre alterações de elementos do modelo (Fig. 10). Como pode ser visto, em linhas gerais, é análogo aos mecanismos de notificação implementados no modelo de recursos e no modelo Java, e utiliza IElementDelta para uma representação unificada das informações sobre a alteração de um elemento.
Fig. 10. Interfaces comuns e implementações básicas do mecanismo de notificação do Handly
A parte do Handly discutida acima (Fig. 9 e 10) pode ser usada para representar praticamente qualquer modelo baseado em identificadores. Para a criação modelos linguísticos o projeto oferece funcionalidade adicional – em particular, interfaces comuns e implementações básicas para elementos da estrutura do texto fonte, os chamados source elements (fig. 8). A Interface ISourceFile representa o arquivo de origem, enquanto ISourceConstruct é um elemento dentro do arquivo de origem. As classes abstratas SourceFile e SourceConstruct implementam mecanismos genéricos para suportar o trabalho com arquivos de origem e seus elementos, como a manipulação de buffers de texto, ligação às coordenadas do elemento no texto original, reconciliando o modelo com o conteúdo atual do buffer de cópia de trabalho, etc. A implementação desses mecanismos é geralmente uma tarefa bastante complexa, e o Handly pode reduzir significativamente os esforços de desenvolvimento de modelos baseados em handle, fornecendo implementações básicas de qualidade.
Além dos mecanismos principais mencionados acima, o Handly oferece uma infraestrutura de buffers de texto e "snapshots", suporte à integração com editores de código-fonte (incluindo integração pronta para uso com o editor Xtext), além de alguns componentes de UI gerais que funcionam com modelos baseados no Handly, como o framework de outline. Para ilustrar suas capacidades, o projeto fornece vários exemplos, incluindo a implementação de um modelo Java no Handly. (Em comparação com a implementação completa do modelo Java no JDT, este modelo é intencionalmente simplificado para maior clareza.)
Como mencionado anteriormente, atenção considerável foi dada ao escalonamento e flexibilidade durante o design inicial do Handly e continua a ser uma prioridade no seu desenvolvimento.
Em princípio, modelos baseados em handle escalam bem "por design". Por exemplo, a idiom handle/body permite limitar a quantidade de memória consumida pelo modelo. No entanto, existem nuances. Durante os testes de escalabilidade do Handly, foi identificada uma questão na implementação do mecanismo de notificação – ao alterar um grande número de elementos, a construção de deltas tomou muito tempo. Descobriu-se que o mesmo problema também estava presente no modelo Java do JDT, do qual o código correspondente foi anteriormente adaptado. Corrigimos o erro no Handly e preparámos um patch semelhante para o JDT, que foi aceito com agradecimento. Este é apenas um dos exemplos em que a implementação do Handly em implementações existentes de modelos poderia ser potencialmente útil, pois, nesse caso, tal erro poderia ser corrigido em um único lugar.
Para tornar a implementação do Handly em modelos existentes tecnicamente viável, a biblioteca precisa ter uma flexibilidade significativa. O principal desafio é manter a compatibilidade retroativa da API do modelo. Essa tarefa foi resolvida em por meio da clara separação da API específica do modelo, definida e totalmente controlada pelo desenvolvedor, da API unificada de meta-nível fornecida pela biblioteca. Isso não apenas torna tecnicamente possível a implementação do Handly em implementações existentes, mas também oferece ao desenvolvedor do novo modelo uma liberdade significativa ao projetar a API.
A flexibilidade tem outros aspectos. Por exemplo, o Handly praticamente não impõe restrições à estrutura do modelo e pode ser utilizado tanto para modelar linguagens de propósito geral quanto linguagens orientadas a domínio. Ao construir a estrutura do arquivo de origem, o Handly não impõe uma forma específica de representação da AST e, de fato, não requer a presença da AST, garantindo assim compatibilidade com praticamente qualquer mecanismo de análise sintática. Por fim, o Handly suporta integração completa com o eclipse workspace, mas também pode operar diretamente com sistemas de arquivos, devido à sua integração com (EFS).
A versão atual foi lançada em dezembro de 2016. Embora o projeto esteja atualmente em estado de incubação e a API ainda não esteja oficialmente finalizada, o Handly já está sendo utilizado em dois grandes produtos comerciais que se aventuraram a ser 'early adopters', e, devo dizer, até agora não se arrependem disso.
Como mencionado anteriormente, um desses produtos é o 1C:Enterprise Development Tools, onde o Handly é utilizado desde o início para modelar elementos de uma estrutura de alto nível de linguagens como o 1C:Enterprise, incluindo a linguagem de programação embutida e a linguagem de consulta. O outro produto é menos conhecido pelo grande público. É , um ambiente integrado de design para processadores orientados a problemas (application-specific instruction-set processor, ASIP), utilizado tanto dentro da própria empresa checa Codasip quanto por seus clientes, entre eles , , , . A Codasip utiliza o Handly em produção desde 2015, começando com a versão Handly 0.2. A última versão do Codasip Studio utiliza a versão 0.5, lançada em junho de 2016. Ondřej Ilčík, que lidera o desenvolvimento do IDE na Codasip, mantém contato com o projeto, fornecendo feedback extremamente importante do ponto de vista de um 'adotante externo'. Ele até conseguiu encontrar um pouco de tempo livre para participar diretamente do desenvolvimento do projeto, implementando uma camada de UI (~ 4000 linhas de código) para um dos exemplos do Handly, modelo Java. Mais informações 'de primeira mão' sobre o uso do Handly por adotantes podem ser encontradas na página do projeto.
Esperamos que, após o lançamento da versão 1.0 com garantia de estabilidade da API e a saída do projeto do estado de incubação, o Handly conte com novos adotantes. Enquanto isso, o projeto continua a ser testado e a API está sendo aperfeiçoada, com dois 'grandes' lançamentos a cada ano – em junho (na mesma data do lançamento simultâneo do Eclipse) e em dezembro, garantindo um cronograma previsível no qual os adotantes podem confiar. Vale mencionar também que a taxa de falhas do projeto permanece estável e baixa, e o Handly tem funcionado de forma confiável nos produtos dos primeiros adotantes desde suas versões iniciais. Para mais informações sobre o Eclipse Handly, você pode usar e .
Fonte: habr.com
