Probabilmente, non ha più bisogno di presentazioni particolari. Molti conoscono Eclipse grazie agli Eclipse Java development tools (). Questa popolare IDE Java open-source è associata da molti sviluppatori alla parola “Eclipse”. Tuttavia, Eclipse è anche una piattaforma estensibile per l'integrazione degli strumenti di sviluppo (Eclipse Platform), e una serie di IDE costruite su di essa, tra cui JDT. Eclipse è anche l'Eclipse Project, un progetto di alto livello che coordina lo sviluppo dell'Eclipse Platform e di JDT, e l'Eclipse SDK, il risultato di tale sviluppo. Infine, Eclipse è una Fondazione open-source con una vasta comunità di progetti, non tutti scritti in Java o correlati agli strumenti di sviluppo (ad esempio, progetti e ). Il mondo di Eclipse è molto variegato.
In questo articolo, di natura panoramica, cercheremo di esaminare alcune basi dell'architettura di Eclipse come piattaforma per la costruzione di strumenti di sviluppo integrati e fornire un'introduzione ai componenti di Eclipse che costituiscono la base della piattaforma tecnologica per il “nuovo Configuratore” 1C: Enterprise, . Naturalmente, tale esame sarà inevitabilmente superficiale e piuttosto limitato, anche perché ci rivolgiamo non solo agli sviluppatori Eclipse come pubblico target. Tuttavia, speriamo che anche gli sviluppatori Eclipse esperti possano trovare informazioni interessanti nell'articolo. Ad esempio, parleremo di uno dei “segreti di Eclipse”, un progetto relativamente nuovo e poco conosciuto fino ad ora, , che è stato fondato e sostenuto dalla società 1C.
Introduzione all'architettura di Eclipse
Iniziamo esaminando alcuni aspetti generali dell'architettura di Eclipse utilizzando come esempio (JDT). La scelta di JDT come esempio non è casuale. Questa è stata la prima integrazione dell'ambiente di sviluppo apparsa in Eclipse. Gli altri progetti *DT di Eclipse, come Eclipse C/C++ Development Tooling (CDT), sono stati creati in seguito e hanno preso in prestito sia i principi architetturali di base, sia frammenti di codice sorgente da JDT. Le basi architettoniche stabilite in JDT sono ancora oggi rilevanti per praticamente qualsiasi IDE costruita sopra l'Eclipse Platform, incluso 1C:Enterprise Development Tools.
Innanzitutto, va sottolineato che Eclipse presenta una netta separazione architettonica, con una distinzione tra le funzionalità indipendenti dal linguaggio e quelle destinate a supportare specifici linguaggi di programmazione, e una separazione tra i componenti "core" (nucleo) indipendenti dall'interfaccia utente e i componenti legati al supporto dell'interfaccia utente.
La piattaforma Eclipse definisce un'infrastruttura generale e indipendente dal linguaggio, mentre gli strumenti di sviluppo Java aggiungono a Eclipse un IDE Java completamente funzionale. Sia la piattaforma Eclipse che JDT sono composti da più componenti, ciascuna delle quali appartiene o al "nucleo" indipendente dall'interfaccia utente o allo strato dell'interfaccia utente (fig. 1).
Fig. 1. Piattaforma Eclipse e JDT
Elencare i componenti principali della piattaforma Eclipse:
- Runtime — Definisce l'infrastruttura dei plugin. Eclipse presenta un'architettura modulare. In sostanza, Eclipse è una raccolta di "punti di estensione" e "estensioni".
- Workspace — Gestisce uno o più progetti. Un progetto è composto da cartelle e file che si riflettono direttamente nel file system.
- Standard Widget Toolkit (SWT) — Fornisce gli elementi di base dell'interfaccia utente, integrati con il sistema operativo.
- JFace — Fornisce una serie di framework UI costruiti sopra SWT.
- Workbench — Definisce la paradigma UI di Eclipse: editor, viste, prospettive.
Vale la pena dire che la piattaforma Eclipse offre anche molti altri componenti utili per la realizzazione di strumenti di sviluppo integrati, tra cui Debug, Compare, Search e Team. È opportuno menzionare JFace Text, la base per la costruzione di "editor intelligenti" del codice sorgente. Purtroppo, anche una rapida panoramica di questi componenti, così come dei componenti dello strato UI, non è possibile in questo articolo, pertanto, nella restante parte di questa sezione ci limiteremo a fornire una panoramica dei principali componenti "core" della piattaforma Eclipse e di JDT.
Core Runtime
L'infrastruttura dei plugin di Eclipse si basa su ed è fornita dal progetto . Ogni plugin Eclipse è un bundle OSGi. La specifica OSGi definisce, tra le altre cose, i meccanismi di versioning e risoluzione delle dipendenze. Oltre a questi meccanismi standard, Equinox introduce il concetto di punto di estensione. Ogni plugin può definire i propri punti di estensione e aggiungere funzionalità al sistema («estensioni»), utilizzando i punti di estensione definiti dallo stesso o da altri plugin. Una descrizione dettagliata dei meccanismi OSGi e Equinox esula da questo articolo. Si noti solo che la modularizzazione in Eclipse è totale (ogni sottosistema, incluso il Runtime, è composto da uno o più plugin), e praticamente tutto in Eclipse è un'estensione. Questi principi erano già stati incorporati nell'architettura di Eclipse molto prima dell'implementazione di OSGi (all'epoca veniva utilizzata una tecnologia proprietaria, in gran parte analoga a OSGi).
Core Workspace
Quasi tutti gli ambienti di sviluppo integrati basati sulla Eclipse Platform funzionano con l'Eclipse workspace. È proprio lo workspace a contenere normalmente il codice sorgente dell'applicazione in fase di sviluppo nell'IDE. Lo workspace è direttamente mappato sul file system e consiste in progetti che contengono cartelle e file. Questi progetti, cartelle e file vengono definiti risorse workspace. L'implementazione dello workspace in Eclipse funge come una sorta di cache rispetto al file system, permettendo di accelerare notevolmente la navigazione nell'albero delle risorse. Inoltre, lo workspace offre una serie di servizi aggiuntivi, tra cui e .
La componente Core Resources (plugin org.eclipse.core.resources) è responsabile del supporto dello workspace e delle sue risorse. In particolare, questa componente fornisce accesso programmatico allo workspace sotto forma di modello di risorse. Per lavorare in modo efficace con questo modello, i client necessitano di un modo semplice per rappresentare un riferimento a una risorsa. Dovrebbe essere desiderabile nascondere l’oggetto che memorizza direttamente lo stato della risorsa nel modello dall'accesso ai client. Altrimenti, nel caso, ad esempio, di cancellazione di un file, il client potrebbe continuare a trattenere un oggetto che non è più presente nel modello, creando problemi. Eclipse risolve questo problema utilizzando il cosiddetto handle della risorsa. L’handle funge da chiave (conosce solo il percorso della risorsa nello workspace) e controlla completamente l'accesso all'oggetto interno del modello che memorizza direttamente le informazioni sullo stato della risorsa. Questo design è una variazione del pattern .
La figura 2 illustra l'idioma Handle/Body applicato al modello delle risorse. L'interfaccia IResource rappresenta l'handle della risorsa ed è un'API, a differenza della classe Resource, che implementa questa interfaccia, e della classe ResourceInfo, che rappresenta il body e che non è un'API. È importante sottolineare che l'handle conosce solo il percorso verso la risorsa rispetto alla radice del workspace e non contiene alcun riferimento alle informazioni sulla risorsa. Gli oggetti delle informazioni sulla risorsa formano il cosiddetto «albero degli elementi» (element tree). Questa struttura dati è completamente materializzata in memoria. Per trovare un'istanza delle informazioni sulla risorsa corrispondente a un determinato handle, si esegue una scansione dell'albero degli elementi secondo il percorso memorizzato in questo handle.
Fig. 2. IResource e ResourceInfo
Come vedremo in seguito, il design di base del modello delle risorse (che può essere definito come basato su handle) è utilizzato in Eclipse e anche in altri modelli. Per ora, elenchiamo alcune caratteristiche distintive di questo design:
- L'handle è un oggetto di valore (value object). Gli oggetti di valore sono oggetti immutabili (immutable) la cui uguaglianza non si basa sull'identità. Tali oggetti possono essere utilizzati in sicurezza come chiavi nei contenitori hash. Più istanze di handle possono riferirsi alla stessa risorsa. Per il loro confronto, è necessario utilizzare il metodo equals(Object).
- L'handle definisce il comportamento della risorsa, ma non contiene informazioni sullo stato della risorsa (le uniche informazioni che memorizza sono la «chiave», il percorso verso la risorsa).
- L'handle può riferirsi a una risorsa inesistente (o a una risorsa che deve ancora essere creata, o a una risorsa già eliminata). L'esistenza della risorsa può essere verificata tramite il metodo IResource.exists().
- Alcune operazioni possono essere implementate a partire unicamente dalle informazioni memorizzate nello stesso handle (le cosiddette operazioni handle-only). Esempi includono IResource.getParent(), getFullPath(), ecc. La risorsa non deve necessariamente esistere per il successo dell'esecuzione di tale operazione. Le operazioni che richiedono che la risorsa esista per essere eseguite correttamente generano un'eccezione (CoreException) se la risorsa non esiste.
Eclipse fornisce un meccanismo di notifica efficace per le modifiche alle risorse del workspace (fig. 3). Le risorse possono variare sia a seguito delle azioni eseguite all'interno della stessa Eclipse IDE, sia per effetto della sincronizzazione con il file system. In entrambi i casi, ai clienti iscritti alle notifiche viene fornita una dettagliata informazione sui cambiamenti sotto forma di "delta delle risorse" (resource delta). Il delta descrive le modifiche tra due stati (sub-)alberi delle risorse del workspace ed è esso stesso un albero, ogni nodo del quale descrive la modifica di una certa risorsa e contiene un elenco di delta di livello successivo, che descrivono le modifiche delle risorse figlie.
Fig. 3. IResourceChangeEvent e IResourceDelta
Il meccanismo di notifica basato sui delta delle risorse presenta le seguenti caratteristiche:
- Una singola modifica e molteplici modifiche si descrivono utilizzando la stessa struttura, poiché il delta è costruito secondo il principio della composizione ricorsiva. I clienti abbonati possono gestire le notifiche di modifica delle risorse attraverso una discesa ricorsiva nell'albero dei delta.
- Il delta contiene tutte le informazioni riguardanti la modifica di una risorsa, incluso il suo spostamento e/o le modifiche ai "marker" ad essa associati (i marker rappresentano, ad esempio, gli errori di compilazione).
- Poiché i riferimenti a una risorsa vengono effettuati tramite handle, il delta può naturalmente riferirsi a risorse remote.
Come vedremo tra poco, i principali componenti del design del meccanismo di notifica delle modifiche al modello delle risorse sono validi anche per altri modelli basati su handle.
JDT Core
Il modello delle risorse del workspace di Eclipse è un modello fondamentale indipendente dal linguaggio. Il componente JDT Core (plugin org.eclipse.jdt.core) fornisce un'API per la navigazione e l'analisi della struttura del workspace dal punto di vista di Java, il cosiddetto "modello Java" (modello Java). Questa API è definita in termini di elementi Java, a differenza dell'API sottostante del modello delle risorse, che è definita in termini di cartelle e file. Le principali interfacce dell'albero degli elementi Java sono illustrate nella fig. 4.
Fig. 4. Elementi del modello Java
Il modello Java utilizza la stessa idiom handle/body del modello delle risorse (fig. 5). IJavaElement è il handle, mentre JavaElementInfo gioca il ruolo di body. L'interfaccia IJavaElement definisce un protocollo comune a tutti gli elementi Java. Alcuni dei suoi metodi sono handle-only: getElementName(), getParent(), ecc. L'oggetto JavaElementInfo memorizza lo stato dell'elemento corrispondente: la sua struttura e gli attributi.
Fig. 5. IJavaElement e JavaElementInfo
Il modello Java presenta alcune differenze nell'implementazione del design di base handle/body rispetto al modello delle risorse. Come accennato in precedenza, nel modello delle risorse, l'albero degli elementi, i cui nodi sono oggetti di resource info, è completamente contenuto in memoria. Ma nel modello Java può esserci un numero significativamente maggiore di elementi rispetto all'albero delle risorse, poiché il modello rappresenta anche la struttura interna dei file .java e .class: tipi, campi e metodi.
Per evitare la completa materializzazione dell'intero albero degli elementi in memoria, l'implementazione del modello Java utilizza una cache LRU di dimensioni limitate per l'element info, dove la chiave è il handle IJavaElement. Gli oggetti element info vengono creati su richiesta mentre avviene la navigazione dell'albero degli elementi. In questo modo, gli elementi meno frequentemente utilizzati vengono espulsi dalla cache, mantenendo il consumo di memoria del modello limitato alla dimensione specificata della cache. Questo è un ulteriore vantaggio del design basato su handle, che nasconde completamente tali dettagli di implementazione dal codice client.
Il meccanismo di notifica per le modifiche agli elementi Java è, in generale, simile al meccanismo di monitoraggio delle modifiche alle risorse della workspace descritto in precedenza. Il client che desidera monitorare le modifiche nel modello Java si iscrive alle notifiche, che sono presentate sotto forma di oggetto ElementChangedEvent contenente IJavaElementDelta (fig. 6).
Fig. 6. ElementChangedEvent e IJavaElementDelta
Il modello Java non contiene informazioni sul corpo dei metodi o sulla risoluzione dei nomi, pertanto per un'analisi dettagliata del codice Java, JDT Core fornisce un ulteriore modello (non basato su handle): (abstract syntax tree, AST). L'AST rappresenta il risultato dell'analisi sintattica del testo sorgente. I nodi dell'AST corrispondono agli elementi della struttura del modulo sorgente (dichiarazioni, operatori, espressioni, ecc.) e contengono informazioni sulle coordinate dell'elemento corrispondente nel testo sorgente, oltre a (opzionalmente) informazioni sulla risoluzione dei nomi sotto forma di riferimenti a cosiddetti bindingsI binding sono oggetti che rappresentano entità nominate, come tipi, metodi e variabili, noti al compilatore. A differenza dei nodi AST che formano un albero, i binding supportano riferimenti incrociati e, in generale, formano un grafo. La classe astratta ASTNode è la classe base comune per tutti i nodi AST. Le sottoclassi di ASTNode corrispondono a specifiche costruzioni sintattiche del linguaggio Java.
Poiché gli alberi sintattici possono consumare una quantità significativa di memoria, JDT memorizza nella cache solo un AST per l'editor attivo. A differenza del modello Java, l'AST è generalmente considerato un modello "intermedio" o "temporaneo", i cui elementi i clienti non dovrebbero mantenere riferimenti al di fuori del contesto dell'operazione che ha portato alla creazione dell'AST.
I tre modelli elencati (modello Java, AST, binding) costituiscono insieme la base per la costruzione di "strumenti di sviluppo intelligenti" in JDT, tra cui un potente editor Java con vari "assistenti", diverse azioni per la manipolazione del codice sorgente (tra cui l'organizzazione dell'elenco di importazione dei nomi e la formattazione secondo lo stile impostato), strumenti di ricerca e refactoring. Il modello Java gioca un ruolo particolare, poiché è utilizzato come base per la rappresentazione visiva della struttura dell'applicazione in fase di sviluppo (ad esempio, in Package Explorer, Outline, Search, Call Hierarchy e Type Hierarchy).
Componenti Eclipse utilizzati in 1C:Enterprise Developments Tools
Nella figura 7 sono mostrati i componenti di Eclipse che formano le fondamenta della piattaforma tecnologica per 1C:Enterprise Development Tools.
Figura 7. Eclipse come piattaforma per 1C:Enterprise Development Tools
Piattaforma Eclipse fornisce l'infrastruttura di base. Abbiamo esaminato alcuni aspetti di questa infrastruttura nella sezione precedente.
(EMF) fornisce strumenti generali per la modellazione dei dati strutturati. EMF è integrato con Eclipse Platform, ma può essere utilizzato anche separatamente, in normali applicazioni Java. Piuttosto spesso, i principianti nello sviluppo di Eclipse sono già abbastanza familiari con EMF, anche se non comprendono del tutto le complessità di Eclipse Platform. Una delle ragioni di questa meritata popolarità è il design universale, che include, tra l'altro, un'API unificata di meta-livello, che consente di lavorare in modo generico con qualsiasi modello EMF. Le implementazioni di base fornite da EMF per gli oggetti modello e il sottosistema di generazione del codice modello da meta-modello aumentano notevolmente la velocità di sviluppo e riducono il numero di errori. Inoltre, EMF include meccanismi di serializzazione dei modelli, tracciamento delle modifiche nel modello, e molto altro.
Come qualsiasi strumento veramente universale, EMF è adatto a una vasta gamma di compiti legati alla modellazione, ma alcune classi di modelli (ad esempio, i modelli basati su handle discussi sopra) potrebbero avere bisogno di strumenti di modellazione più specializzati. Parlarne è un compito ingrato, specialmente nei limiti di un solo articolo, poiché è un argomento di un libro a sé, e piuttosto spesso. Notiamo solo che un sistema di astrazioni di qualità, alla base di EMF, ha permesso la nascita di una vasta gamma di progetti dedicati alla modellazione, che rientrano nel progetto di livello superiore insieme allo stesso EMF. Uno di questi progetti è Eclipse Xtext.
fornisce un'infrastruttura di «modellazione testuale». Xtext utilizza per l'analisi sintattica del testo sorgente e EMF per la rappresentazione del risultato ASG (grafo semantico astratto, che è fondamentalmente una combinazione di AST e bindings), chiamato anche "modello semantico". La grammatica del linguaggio modellato tramite Xtext è descritta nel proprio linguaggio Xtext. Questo consente non solo di generare una descrizione della grammatica per ANTLR, ma anche di ottenere un meccanismo di serializzazione dell'AST (cioè, Xtext fornisce sia il parser che l'unparser), suggerimenti contestuali e una serie di altri componenti linguistici. D'altro canto, il linguaggio di descrizione della grammatica utilizzato in Xtext è meno flessibile rispetto, per esempio, al linguaggio di descrizione della grammatica in ANTLR. Quindi, a volte è necessario "modellare" il linguaggio realizzato per Xtext, il che di solito non è un problema quando si tratta di un linguaggio sviluppato da zero, ma può essere inaccettabile per lingue con una sintassi già consolidata. Nonostante ciò, Xtext è attualmente lo strumento più maturo, completamente funzionale e versatile in Eclipse per la costruzione di linguaggi di programmazione e degli strumenti di sviluppo per essi. In particolare, è lo strumento ideale per il rapido prototipaggio. (domain-specific language, DSL). Oltre al "nucleo linguistico" menzionato sopra basato su ANTLR e EMF, Xtext offre molti componenti utili di livello superiore, inclusi meccanismi di indicizzazione, costruzione incrementale, "editor intelligente", e molto, molto altro, ma tralascia i modelli di lingua basati su handle. Come EMF, Xtext merita un libro a parte, e probabilmente non riusciremo nemmeno a dare una panoramica delle sue capacità.
1C:Enterprise Development Tools utilizza attivamente sia EMF in sé che una serie di altri progetti Eclipse Modeling. In particolare, Xtext è uno dei fondamenti degli strumenti di sviluppo per linguaggi 1C:Enterprise, come il linguaggio di programmazione embedded e il linguaggio delle query. Un altro fondamento di questi strumenti di sviluppo è il progetto Eclipse Handly, di cui parleremo più dettagliatamente (tra i componenti elencati di Eclipse è attualmente il meno conosciuto).
, sottoprogetto del progetto a livello superiore Eclipse Technology, è nato dal contributo iniziale di codice nella Eclipse Foundation fornito dall'azienda 1C nel 2014. Da allora, l'azienda 1C continua a supportare lo sviluppo del progetto: i committers di Handly sono dipendenti dell'azienda. Il progetto è piccolo, ma occupa una nicchia piuttosto unica in Eclipse: il suo obiettivo principale è supportare lo sviluppo di modelli basati su handle.
I principali principi architettonici dei modelli basati su handle, come l'idioma handle/body, sono stati discussi sopra utilizzando il modello delle risorse e il modello Java come esempi. È stato also notato che sia il modello delle risorse sia il modello Java sono fondamentali per gli strumenti di sviluppo Java di Eclipse (JDT). E poiché praticamente tutti i progetti *DT di Eclipse hanno un'architettura simile a quella di JDT, non sarebbe un'esagerazione affermare che i modelli basati su handle formano la base di molti, se non di tutti, gli IDE costruiti sopra la piattaforma Eclipse. Ad esempio, in Eclipse C/C++ Development Tooling (CDT) c'è un modello basato su handle per C/C++, che ha lo stesso ruolo nell'architettura di CDT che ha il modello Java in JDT.
Fino all'arrivo di Handly, Eclipse non offriva librerie specializzate per costruire modelli linguistici basati su handle. I modelli esistenti sono stati creati principalmente attraverso un'adattamento diretto del codice del modello Java (alias copia/incolla), in quei casi in cui ciò è permesso dalla Eclipse Public License (EPL). (È chiaro che, per progetti come quelli di Eclipse, questo di solito non rappresenta un problema dal punto di vista legale, il che non si può dire per i prodotti con codice sorgente chiuso.) Oltre alla tipica mancanza di sistematicità, questo approccio porta a problemi ben noti: duplicazione del codice, errori introdotti durante l'adattamento, ecc. Anche peggio, i modelli risultanti rimangono «un'entità a sé stante» e non sfruttano il potenziale esistente per l'unificazione. In effetti, l'estrazione di concetti e protocolli comuni per i modelli linguistici basati su handle potrebbe portare alla creazione di componenti riutilizzabili per lavorarci, molto simile a quanto è accaduto nel caso di EMF.
Non si può dire che in Eclipse non ci fosse una consapevolezza di questi problemi. Già nel 2005 , riassumendo l'esperienza di sviluppo del prototipo CDT, la necessità di creare un'infrastruttura comune per i modelli linguistici, comprese le modelli basate su handle. Ma, come spesso accade, a causa di compiti più prioritari non si è mai arrivati all'implementazione di queste idee. Nel frattempo, la fattorizzazione del codice dei *progetti DT rimane uno dei temi ancora poco sviluppati in Eclipse.
In un certo senso, il progetto Handly è destinato a risolvere più o meno gli stessi problemi di EMF, ma per modelli basati su handle, e prima di tutto per quelli linguistici (cioè rappresentanti gli elementi della struttura di un certo linguaggio di programmazione). Di seguito sono elencati gli obiettivi principali che sono stati posti nella progettazione di Handly:
- L'individuazione delle principali astrazioni del dominio.
- Ridurre gli sforzi e migliorare la qualità dell'implementazione dei modelli linguistici basati su handle attraverso il riutilizzo del codice.
- Fornire un'API unificata di meta-livello ai modelli risultanti, rendendo possibile la creazione di componenti IDE comuni che lavorano con i modelli linguistici basati su handle.
- Flessibilità e scalabilità.
- Integrazione con Xtext (in un livello separato).
Per identificare concetti e protocolli comuni, sono state analizzate implementazioni esistenti di modelli linguistici basati su handle. Le principali interfacce e le implementazioni di base fornite da Handly sono mostrati in Fig. 8.
Fig. 8. Interfacce comuni e implementazioni di base degli elementi Handly
L'interfaccia IElement rappresenta l'handle di un elemento ed è comune a tutti gli elementi dei modelli basati su Handly. La classe astratta Element implementa il meccanismo generico handle/body (Fig. 9).
Fig. 9. IElement e implementazione generica handle/body
Inoltre, Handly fornisce un meccanismo generico per la notifica delle modifiche agli elementi del modello (Fig. 10). Come si può vedere, in linea generale è analogo ai meccanismi di notifica implementati nel modello delle risorse e nel modello Java, e utilizza IElementDelta per una rappresentazione unificata delle informazioni riguardanti la modifica di un elemento.
Fig. 10. Interfacce comuni e implementazioni di base del meccanismo di notifica di Handly
La parte di Handly sopra discussa (Fig. 9 e 10) può essere usata per rappresentare praticamente qualsiasi modello basato su handle. Per creare modelli linguistici il progetto offre funzionalità aggiuntive – in particolare, interfacce comuni e implementazioni di base per gli elementi della struttura del testo sorgente, i cosiddetti source elements (fig. 8). L'interfaccia ISourceFile rappresenta il file sorgente, mentre ISourceConstruct è l'elemento all'interno del file sorgente. Le classi astratte SourceFile e SourceConstruct implementano meccanismi generali per supportare il lavoro con i file sorgenti e i loro elementi, come ad esempio la gestione dei buffer di testo, il collegamento alle coordinate dell'elemento nel testo sorgente, la riconciliazione del modello con il contenuto attuale del buffer working copy, e così via. L'implementazione di questi meccanismi è di solito un compito abbastanza complesso, e Handly può ridurre significativamente gli sforzi di sviluppo per modelli basati su handle grazie a fornitura di implementazioni di base di alta qualità.
Oltre ai meccanismi principali sopra menzionati, Handly fornisce un'infrastruttura di buffer di testo e 'istantanee' (snapshots), supporto per integrazioni con editor di codice sorgente (comprese le integrazioni 'out of the box' con l'editor Xtext), oltre a alcuni componenti UI generali che lavorano con i modelli basati su Handly, come il framework outline. Per illustrare le sue capacità, il progetto offre diversi esempi, inclusa l'implementazione di un modello Java su Handly. (Rispetto all'implementazione completa del modello Java in JDT, questo modello è intenzionalmente semplificato per maggiore chiarezza.)
Come già accennato, durante la progettazione iniziale di Handly e il suo sviluppo ulteriore è stata prestata e continua a essere prestata una seria attenzione alla scalabilità e flessibilità.
In linea di principio, i modelli basati su handle scalano abbastanza bene 'per design'. Ad esempio, l'idioma handle/body consente di limitare la quantità di memoria utilizzata dal modello. Tuttavia, ci sono delle sfumature. Durante i test di scalabilità di Handly è stato riscontrato un problema nell'implementazione del meccanismo di notifica: quando venivano modificati un gran numero di elementi, la costruzione delle delta richiedeva troppo tempo. È emerso che lo stesso problema era presente anche nel modello Java JDT, da cui è stato adattato il codice corrispondente. Abbiamo corretto l'errore in Handly e abbiamo preparato una patch analoga per JDT, che è stata accettata con gratitudine. Questo è solo uno dei tanti esempi in cui l'integrazione di Handly in implementazioni esistenti di modelli potrebbe rivelarsi potenzialmente utile, poiché in tal caso tale errore potrebbe essere corretto in un solo luogo.
Per rendere l'integrazione di Handly nelle implementazioni esistenti dei modelli tecnicamente possibile, la libreria deve possedere una notevole flessibilità. Il problema principale consiste nel mantenere la retrocompatibilità con l'API del modello. Questa sfida è stata risolta in attraverso una chiara separazione dell'API specifica del modello, definita e completamente controllata dallo sviluppatore, dall'API unificato a livello meta fornito dalla libreria. Questo non solo rende tecnicamente possibile l'integrazione di Handly nelle implementazioni esistenti, ma fornisce anche agli sviluppatori di nuovi modelli una notevole libertà nella progettazione dell'API.
La flessibilità ha anche altri aspetti. Ad esempio, Handly impone quasi nessuna restrizione sulla struttura del modello e può essere utilizzato sia per la modellazione di linguaggi di programmazione generali sia per linguaggi specifici. Nella costruzione della struttura del file sorgente, Handly non prescrive alcuna forma specifica per la rappresentazione dell'AST e in linea di principio non richiede nemmeno la presenza di un AST, garantendo così la compatibilità con praticamente qualsiasi meccanismo di analisi sintattica. Infine, Handly supporta un'integrazione completa con l'ambiente di lavoro di Eclipse, ma può anche funzionare direttamente con i file system, grazie all'integrazione con (EFS).
L'attuale versione è stata rilasciata nel dicembre 2016. Nonostante il progetto sia attualmente in fase di incubazione e l'API non sia ancora definitiva, Handly è già utilizzato in due grandi prodotti commerciali che hanno osato essere "primi adottatori" e, bisogna dire, finora non si sono pentiti di questa scelta.
Come menzionato in precedenza, uno di questi prodotti è 1C:Enterprise Development Tools, dove Handly è utilizzato fin dall'inizio per modellare gli elementi della struttura ad alto livello di linguaggi come il linguaggio di programmazione incorporato e il linguaggio di query. L'altro prodotto è meno noto al grande pubblico. Questo è , un ambiente integrato per la progettazione di processori specifici per applicazioni (application-specific instruction-set processor, ASIP), utilizzato sia all'interno della stessa azienda ceca Codasip che dai suoi clienti, tra cui , , , . Codasip utilizza Handly in produzione dal 2015, a partire dalla versione Handly 0.2. L'ultima versione di Codasip Studio attualmente rilasciata utilizza la versione 0.5, rilasciata a giugno 2016. Ondřej Ilčík, che guida lo sviluppo dell'IDE in Codasip, è in contatto con il progetto, fornendo feedback estremamente importante da parte di un «adattatore esterno». È riuscito anche a trovare un po' di tempo libero per partecipare direttamente allo sviluppo del progetto, implementando il livello UI (~ 4000 righe di codice) per uno degli esempi di Handly, un modello Java. Maggiori informazioni del progetto.
Speriamo che, dopo il rilascio della versione 1.0 con garanzia di stabilità dell'API e il termine dello stato di incubazione del progetto, Handly possa avere nuovi adattatori. Nel frattempo, il progetto continua a essere testato e a migliorare ulteriormente l'API, rilasciando due 'grandi' versioni all'anno – a giugno (nella stessa data del rilascio simultaneo di Eclipse) e a dicembre, garantendo un programma prevedibile su cui gli adattatori possono contare. Inoltre, va aggiunto che il tasso di bug del progetto rimane costantemente basso e Handly ha funzionato in modo affidabile nei prodotti dei primi adattatori fin dalle prime versioni. Per una maggiore familiarità con Eclipse Handly, puoi utilizzare e .
Fonte: habr.com
