Probabilmente, non ha più bisogno di presentazioni. Molti conoscono Eclipse grazie agli strumenti di sviluppo Java di Eclipse (). Questa popolare IDE open-source per Java è associata per la maggior parte degli sviluppatori alla parola “Eclipse”. Tuttavia, Eclipse è anche una piattaforma estensibile per l'integrazione degli strumenti di sviluppo (Eclipse Platform) e un insieme di IDE costruite su di essa, incluso JDT. Eclipse è anche il progetto Eclipse, un progetto di alto livello che coordina lo sviluppo dell'Eclipse Platform e di JDT, e l'Eclipse SDK – il risultato fornito di questo sviluppo. Infine, Eclipse è una fondazione open-source con una vasta comunità di progetti, non tutti dei quali sono scritti in Java o relativi agli strumenti di sviluppo (ad esempio, i progetti e ). Il mondo di Eclipse è molto variegato.
In questo articolo, di carattere panoramico, cercheremo di esplorare alcune basi dell'architettura di Eclipse come piattaforma per la costruzione di strumenti di sviluppo integrati e fornire una prima introduzione ai componenti di Eclipse che formano il fondamento della piattaforma tecnologica per il «nuovo Configuratore» 1C: Enterprise, . Certamente, questa analisi sarà inevitabilmente superficiale e piuttosto limitata, anche perché ci rivolgiamo non solo agli sviluppatori di Eclipse come pubblico di riferimento. Tuttavia, speriamo che anche gli sviluppatori esperti di Eclipse possano trovare informazioni interessanti nell'articolo. Ad esempio, parleremo di uno dei "segreti di Eclipse", un progetto relativamente nuovo e ancora poco conosciuto. , che è stato fondato e supportato dall'azienda 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. È il primo ambiente di sviluppo integrato apparso in Eclipse. Gli altri progetti *DT di Eclipse, come Eclipse C/C++ Development Tooling (CDT), sono stati creati successivamente e hanno preso in prestito sia i principi architettonici fondamentali che singoli frammenti di codice sorgente da JDT. I fondamenti dell'architettura stabiliti in JDT sono tutt'oggi rilevanti per praticamente qualsiasi IDE costruita sopra la Eclipse Platform, incluso 1C:Enterprise Development Tools.
In primo luogo, va notato che Eclipse presenta un'architettura sufficientemente chiara, con una separazione tra le funzionalità indipendenti dal linguaggio e quelle destinate al supporto di linguaggi di programmazione specifici, oltre alla separazione dei componenti "core" (nucleo) indipendenti dall'interfaccia utente da quelli 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 completo. Sia la piattaforma Eclipse che il JDT sono costituiti da diversi componenti, ognuno dei quali appartiene o al "nucleo" indipendente dall'interfaccia utente o allo strato UI (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 collezione di "punti di estensione" e "estensioni".
- Workspace — Gestisce uno o più progetti. Un progetto è composto da cartelle e file, che sono visualizzati direttamente sul filesystem.
- Standard Widget Toolkit (SWT) — Fornisce elementi di base dell'interfaccia utente, integrati con il sistema operativo.
- JFace — Offre una serie di framework UI costruiti su SWT.
- Workbench — Definisce la parodia UI di Eclipse: editor, viste, prospettive.
È importante notare che la Eclipse Platform offre anche molti altri componenti utili per la costruzione di strumenti di sviluppo integrati, tra cui Debug, Compare, Search e Team. Vale la pena menzionare separatamente JFace Text, la base per la creazione di ‘editor intelligenti’ di codice sorgente. Sfortunatamente, anche una rapida panoramica di questi componenti, così come dei componenti del livello UI non è possibile all'interno di questo articolo, pertanto, nella restante parte di questa sezione, ci limiteremo a una panoramica dei principali componenti ‘core’ della Eclipse Platform 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 l'altro, i meccanismi di versioning e di 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 tramite le estensioni non solo di questo ma anche di altri plugin. Una descrizione dettagliata dei meccanismi OSGi ed Equinox esula da questo articolo. È importante notare che la modularizzazione in Eclipse è totale (ogni sottosistema, incluso il Runtime, è composto da uno o più plugin) e praticamente tutto in Eclipse è un'estensione. Inoltre, questi principi erano già stati incorporati nella struttura di Eclipse molto prima dell'introduzione di OSGi (allora veniva utilizzata una tecnologia proprietaria, in gran parte simile a OSGi).
Core Workspace
Quasi tutti gli ambienti di sviluppo integrati basati su Eclipse Platform utilizzano l'Eclipse workspace. È proprio il workspace che di solito contiene il codice sorgente dell'applicazione in fase di sviluppo nell'IDE. Il workspace è direttamente mappato sul file system e consiste in progetti che contengono cartelle e file. Questi progetti, cartelle e file sono chiamati risorse workspace. L'implementazione del workspace in Eclipse funge da cache rispetto al filesystem, consentendo un notevole miglioramento della navigazione nell'albero delle risorse. Inoltre, il workspace offre una serie di servizi aggiuntivi, tra cui e .
La gestione del workspace e delle sue risorse è responsabilità del componente Core Resources (plugin org.eclipse.core.resources). In particolare, questo componente fornisce accesso programmatico al workspace sotto forma di modello delle risorse. Per lavorare in modo efficace con questo modello, i client necessitano di un modo semplice per rappresentare un riferimento a una risorsa. In questo contesto, sarebbe preferibile nascondere l'oggetto che conserva direttamente lo stato della risorsa nel modello dall'accesso diretto dei client. Altrimenti, in caso di cancellazione di un file, il client potrebbe continuare a mantenere l'oggetto che non esiste più nel modello, causando problemi. Eclipse risolve questa problematica utilizzando il cosiddetto handle Il handle funge da chiave (sa solo il percorso verso la risorsa nel 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 Fig. 2 illustra l'idioma Handle/Body in relazione al modello delle risorse. L'interfaccia IResource rappresenta il handle della risorsa ed è un'API, a differenza della classe Resource, che implementa questa interfaccia, e della classe ResourceInfo, che rappresenta il body, che non è un'API. È importante notare che il handle conosce solo il percorso verso la risorsa rispetto alla radice del workspace e non contiene un riferimento alle informazioni della risorsa. Gli oggetti di informazioni della risorsa formano il cosiddetto 'albero degli elementi' (element tree). Questa struttura dati è completamente materializzata in memoria. Per trovare un'istanza di informazioni della risorsa corrispondente a un certo handle, l'albero degli elementi viene attraversato in base al percorso memorizzato in questo handle.
Fig. 2. IResource e ResourceInfo
Come vedremo in seguito, il design di base del modello delle risorse (che possiamo chiamare basato su handle) è utilizzato in Eclipse e per altri modelli. Per ora, elenchiamo alcune proprietà distintive di questo design:
- Handle è un oggetto valore (value object). Gli oggetti valore sono oggetti immutabili (immutable) e la loro uguaglianza non si basa sull'identità. Questi oggetti possono essere utilizzati in sicurezza come chiave in contenitori hash. Più istanze di handle possono fare riferimento alla stessa risorsa. Per il loro confronto è necessario utilizzare il metodo equals(Object).
- Handle definisce il comportamento della risorsa, ma non contiene informazioni sullo stato della risorsa (l'unico dato che conserva è la "chiave", ovvero il percorso verso la risorsa).
- Handle può fare riferimento a una risorsa inesistente (o a una risorsa che non è ancora stata creata, o a una risorsa che è già stata eliminata). L'esistenza della risorsa può essere verificata utilizzando il metodo IResource.exists().
- Alcune operazioni possono essere realizzate esclusivamente sulla base delle informazioni memorizzate nell'handle stesso (le cosiddette operazioni solo handle). Esempi di queste operazioni includono IResource.getParent(), getFullPath(), ecc. La risorsa non deve necessariamente esistere per il corretto completamento di tale operazione. Le operazioni che richiedono l'esistenza della risorsa per essere completate generano un'eccezione (CoreException) se la risorsa non esiste.
Eclipse offre un meccanismo efficace per notificare le modifiche delle risorse del workspace (fig. 3). Le risorse possono cambiare sia a causa delle azioni eseguite all'interno della stessa IDE Eclipse, sia a causa della sincronizzazione con il file system. In entrambi i casi, i client iscritti alle notifiche ricevono informazioni dettagliate sui cambiamenti sotto forma di "delta delle risorse" (resource delta). Il delta descrive le modifiche tra due stati (sotto)albero delle risorse del workspace e costituisce esso stesso un albero, dove ogni nodo descrive una modifica di una certa risorsa e contiene un elenco dei delta di livello inferiore, 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 sono descritte utilizzando la stessa struttura, poiché il delta è costruito secondo il principio della composizione ricorsiva. I client abbonati possono elaborare le notifiche sulle modifiche delle risorse mediante un discesa ricorsiva nell'albero dei delta.
- La delta contiene tutte le informazioni sulla modifica della risorsa, inclusi il suo spostamento e/o la modifica dei «marker» associati (come ad esempio gli errori di compilazione, rappresentati come marker).
- Poiché i riferimenti alla risorsa sono effettuati tramite handle, la delta può naturalmente riferirsi a una risorsa remota.
Come vedremo presto, gli elementi principali del design del meccanismo di notifica delle modifiche al modello delle risorse sono rilevanti anche per altri modelli basati su handle.
JDT Core
Il modello delle risorse dell'workspace Eclipse è un modello fondamentale indipendente dal linguaggio. Il componente JDT Core (plug-in org.eclipse.jdt.core) fornisce un'API per la navigazione e l'analisi della struttura dell'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 è l'handle, mentre JavaElementInfo svolge il ruolo di body. L'interfaccia IJavaElement definisce il protocollo comune a tutti gli elementi Java. Alcuni dei suoi metodi sono specifici per l'handle: getElementName(), getParent(), e così via. L'oggetto JavaElementInfo conserva lo stato del corrispondente elemento: la sua struttura e i suoi 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 resource info, è completamente mantenuto in memoria. Tuttavia, nel modello Java potrebbe esserci un numero significativamente maggiore di elementi rispetto all'albero delle risorse, poiché rappresenta, tra l'altro, anche la struttura interna dei file .java e .class: tipi, campi e metodi.
Per evitare la materializzazione completa di tutto l'albero degli elementi in memoria, l'implementazione del modello Java utilizza una cache LRU di dimensioni limitate per le informazioni degli elementi, dove la chiave è l'handle di IJavaElement. Gli oggetti di informazioni sugli elementi vengono creati su richiesta mentre si naviga nell'albero degli elementi. In questo modo, gli elementi meno frequentemente utilizzati vengono espulsi dalla cache, mantenendo il consumo di memoria del modello entro la dimensione della cache specificata. Questo è un ulteriore vantaggio del design basato sugli handle, che nasconde completamente tali dettagli di implementazione dal codice client.
Il meccanismo di notifica per le modifiche agli elementi Java è in generale simile a quello del meccanismo di tracciamento delle modifiche alle risorse dell'workspace descritto sopra. Un cliente che desidera monitorare le modifiche nel modello Java si iscrive alle notifiche, che si presentano 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, quindi per un'analisi dettagliata del codice scritto in 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, e anche (facoltativamente) informazioni sulla risoluzione dei nomi sotto forma di riferimenti a quelli che vengono definiti bindings. I bindings sono oggetti che rappresentano entità nominate, come tipi, metodi e variabili, conosciuti dal compilatore. A differenza dei nodi dell'AST, che formano un albero, i bindings supportano riferimenti incrociati e in generale formano un grafo. La classe astratta ASTNode è la classe base comune per tutti i nodi dell'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 come un modello 'intermedio', 'temporaneo', i cui elementi non dovrebbero essere referenziati dai client al di fuori del contesto dell'operazione che ha portato alla creazione dell'AST.
I tre modelli elencati (modello Java, AST, binding) costituiscono la base per lo sviluppo di "strumenti di programmazione intelligenti" in JDT, tra cui un potente editor Java con diversi "assistenti", varie azioni di elaborazione 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. In particolare, il modello Java gioca un ruolo fondamentale, poiché è utilizzato come base per la rappresentazione visiva della struttura dell'applicazione in 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 Eclipse che costituiscono il fondamento 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 di dati strutturati. EMF è integrato con Eclipse Platform, ma può essere utilizzato anche separatamente, in normali applicazioni Java. Spesso, i neofiti dello sviluppo Eclipse hanno già una buona familiarità con EMF, anche se non comprendono ancora appieno le complessità di Eclipse Platform. Una delle ragioni della sua meritata popolarità è il design universale, che include anche un API unificata a livello meta, 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 dalla meta-modello aumentano sostanzialmente la velocità di sviluppo e riducono il numero di errori. Inoltre, EMF contiene meccanismi per la serializzazione dei modelli, il monitoraggio delle modifiche nel modello e molto altro.
Come qualsiasi strumento realmente versatile, EMF è adatto a risolvere un ampio spettro di compiti legati alla modellazione, ma alcune classi di modelli (come i modelli basati su handle sopra menzionati) possono necessitare di strumenti di modellazione più specializzati. Parlarne è un'impresa ingrata, specialmente nei limiti di un solo articolo, poiché si tratta di un argomento che meriterebbe un intero libro, e piuttosto corposo. Va dato atto che un solido sistema di astrazioni alla base di EMF ha dato vita a tutta una serie di progetti dedicati alla modellazione, che rientrano nel progetto di alto livello. insieme a EMF stesso. Uno di questi progetti è Eclipse Xtext.
fornisce un'infrastruttura per il «modelling testuale». Xtext utilizza per l'analisi sintattica del testo sorgente e EMF per rappresentare il risultato ASG (gruppo semantico astratto, che è essenzialmente una combinazione di AST e bindings), chiamato anche "modello semantico". La grammatica del linguaggio modellato tramite Xtext è descritta nel linguaggio Xtext stesso. Questo permette non solo di generare una descrizione della grammatica per ANTLR, ma anche di ottenere un meccanismo di serializzazione dell'AST (cioè Xtext fornisce sia parser che unparser), suggerimenti contestuali e una serie di altri componenti linguistici. D'altra parte, il linguaggio di descrizione grammaticale usato in Xtext è meno flessibile rispetto al linguaggio di descrizione grammaticale in ANTLR. Pertanto, a volte è necessario "adaptare" il linguaggio realizzato per Xtext, il che di solito non è un problema se si tratta di un linguaggio sviluppato da zero, ma potrebbe essere inaccettabile per linguaggi con una sintassi già consolidata. Nonostante ciò, Xtext è attualmente lo strumento più maturo, funzionalmente completo e versatile in Eclipse per la costruzione di linguaggi di programmazione e strumenti per il loro sviluppo. In particolare, è lo strumento ideale per il prototipo rapido. (domain-specific language, DSL). Oltre al già menzionato "nucleo linguistico" basato su ANTLR ed EMF, Xtext offre numerosi componenti utili di livello superiore, comprese le meccanismi di indicizzazione, costruzione incrementale, "editor intelligente" e molto altro, ma tralascia i modelli linguistici basati su handle. Come EMF, Xtext merita un libro a sé stante, e sarà difficile anche solo accennare a tutte le sue potenzialità ora.
1C:Enterprise Development Tools fanno ampio uso sia di EMF stesso che di una serie di altri progetti di Eclipse Modeling. In particolare, Xtext è uno dei fondamenti degli strumenti di sviluppo per i linguaggi 1C:Enterprise, come il linguaggio di programmazione integrato e il linguaggio delle query. Un altro fondamento di questi strumenti di sviluppo è il progetto Eclipse Handly, che esamineremo più in dettaglio (tra i componenti di Eclipse, è attualmente il meno conosciuto).
, un sottoprogetto del progetto di alto livello Eclipse Technology, è emerso come risultato della prima contribuzione di codice alla Eclipse Foundation, effettuata dall'azienda 1C nel 2014. Da allora, l'azienda 1C continua a sostenere 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 principi architettonici fondamentali dei modelli basati su handle, come l'idioma handle/body, sono stati discussi in precedenza con l'esempio del modello delle risorse e del modello Java. È stato notato che sia il modello delle risorse che il modello Java sono basi importanti per gli strumenti di sviluppo Java di Eclipse (JDT). Poiché praticamente tutti i progetti *DT di Eclipse hanno un'architettura simile a quella di JDT, non sarà un grande esagerazione dire che i modelli basati su handle sono alla base di molti, se non di tutti, gli IDE costruiti sopra la Eclipse Platform. Ad esempio, in Eclipse C/C++ Development Tooling (CDT) esiste un modello basato su handle per C/C++, che gioca nella architettura del CDT lo stesso ruolo che ha il modello Java nel JDT.
Prima dell'arrivo di Handly, Eclipse non offriva librerie specializzate per la costruzione di modelli linguistici basati su handle. I modelli esistenti oggi sono stati creati principalmente tramite l'adattamento diretto del codice del modello Java (a.k.a. copia/incolla), nei casi in cui ciò è consentito dalla Eclipse Public License (EPL). (È evidente che, ad esempio, per i progetti dello stesso Eclipse ciò di solito non rappresenta un problema dal punto di vista legale, a differenza dei prodotti con codice sorgente chiuso.) Oltre alla sua tipica mancanza di sistematicità, questo approccio porta a problemi ben noti: duplicazione del codice, errori introdotti durante l'adattamento, ecc. Peggio ancora, i modelli risultanti rimangono "cose a sé stanti" e non sfruttano il potenziale esistente per l'unificazione. Eppure, l'estrazione di concetti e protocolli comuni per modelli linguistici basati su handle potrebbe portare alla creazione di componenti riutilizzabili per lavorarci, analogamente a quanto accaduto con EMF.
Non si può dire che in Eclipse non ci fosse consapevolezza di questi problemi. Già nel 2005 , riassumendo l'esperienza dello sviluppo del prototipo CDT, la necessità di creare un'infrastruttura comune per i modelli linguistici, comprese le modalità basate su handle. Tuttavia, come spesso accade, a causa di compiti di priorità superiore, queste idee non sono mai state realizzate. Nel frattempo, la fattorizzazione del codice dei progetti *DT rimane ancora uno dei temi poco esplorati in Eclipse.
In un certo senso, il progetto Handly è destinato a risolvere compiti simili a quelli di EMF, ma per i modelli basati su handle, e in particolare per quelli linguistici (cioè che rappresentano elementi della struttura di un linguaggio di programmazione). Di seguito sono elencati i principali obiettivi stabiliti durante la progettazione di Handly:
- Identificazione delle principali astrazioni del dominio.
- Riduzione degli sforzi e miglioramento della qualità dell'implementazione dei modelli linguistici basati su handle attraverso il riutilizzo del codice.
- Fornire un'API unificata a livello meta per i modelli risultanti, che consenta la creazione di componenti IDE comuni che lavorano con modelli linguistici basati su handle.
- Flessibilità e scalabilità.
- Integrazione con Xtext (in un livello separato).
Per evidenziare concetti e protocolli comuni, sono state analizzate le implementazioni esistenti dei modelli linguistici basati su handle. Le principali interfacce e implementazioni di base fornite da Handly sono mostrate nella 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 un meccanismo generico handle/body (Fig. 9).
Fig. 9. IElement e implementazione generica di handle/body
Inoltre, Handly fornisce un meccanismo generico di notifica per la modifica degli 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 sulla modifica dell'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 utilizzata per rappresentare praticamente qualsiasi modello basato su handle. Per la creazione linguistica Il modello offre funzionalità aggiuntive, in particolare interfacce generali e implementazioni di base per gli elementi della struttura del testo sorgente, noti come elementi sorgente (fig. 8). L'interfaccia ISourceFile rappresenta il file sorgente, mentre ISourceConstruct rappresenta un 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, ad esempio, la gestione di buffer di testo, il legame con le coordinate di un elemento nel testo sorgente, la riconciliazione dei modelli con il contenuto attuale del buffer della copia di lavoro, e così via. L'implementazione di questi meccanismi è solitamente una sfida non indifferente, e Handly può ridurre in modo significativo gli sforzi per lo sviluppo di modelli basati su gestori linguistici fornendo implementazioni di base di alta qualità.
Oltre ai meccanismi principali elencati sopra, Handly offre un'infrastruttura di buffer di testo e di "istantanee" (snapshots), supporto per l'integrazione con gli editor di codice sorgente (inclusa l'integrazione "out of the box" con l'editor Xtext), nonché alcuni componenti UI generali che funzionano con modelli basati su Handly, come il framework outline. Per illustrare le proprie capacità, il progetto fornisce diversi esempi, tra cui l'implementazione di un modello Java su Handly. (Rispetto all'implementazione completa del modello Java in JDT, questo modello è deliberatamente semplificato per una maggiore chiarezza.)
Come menzionato in precedenza, grande attenzione è stata data alla scalabilità e alla flessibilità durante la progettazione iniziale di Handly e continua a essere enfatizzata nel suo sviluppo.
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 consumata dal modello. Tuttavia, ci sono delle sfide. Durante i test della scalabilità di Handly, è emerso un problema nell'implementazione del meccanismo di notifica: nel caso di modifiche a un alto numero di elementi, la costruzione delle delta richiedeva troppo tempo. È risultato che lo stesso problema era presente anche nel modello Java JDT, da cui era stato originariamente adattato il codice corrispondente. Abbiamo corretto l'errore in Handly e preparato una patch analoga per JDT, che è stata accettata con gratitudine. Questo è solo uno dei tanti esempi in cui l'integrazione di Handly nelle implementazioni esistenti dei modelli potrebbe rivelarsi potenzialmente utile, poiché in questo caso tale errore potrebbe essere corretto in un solo luogo.
Per rendere tecnicamente possibile l'integrazione di Handly nelle implementazioni esistenti dei modelli, la libreria deve possedere una notevole flessibilità. Il problema principale è mantenere la retrocompatibilità tramite l'API del modello. Questa sfida è stata affrontata in attraverso una netta separazione dell'API specifico per modello, definito e completamente controllato dallo sviluppatore, dall'API unificata a livello meta fornita dalla libreria. Questo non solo rende tecnicamente possibile l'integrazione di Handly in implementazioni esistenti, ma offre anche allo sviluppatore di un nuovo modello una notevole libertà nella progettazione dell'API.
La flessibilità presenta anche altri aspetti. Ad esempio, Handly impone quasi nessun vincolo sulla struttura del modello e può essere utilizzato sia per la modellazione di linguaggi di programmazione generali che di linguaggi orientati a specifici domini. Quando si costruisce la struttura del file sorgente, Handly non prescrive alcuna forma specifica per la rappresentazione dell'AST e non richiede nemmeno la presenza stessa dell'AST, garantendo così compatibilità con praticamente qualsiasi meccanismo di analisi sintattica. Infine, Handly supporta un'integrazione completa con l'ambiente di lavoro Eclipse, ma può anche lavorare direttamente con i file system, grazie all'integrazione con (EFS).
Versione attuale è stato rilasciato a dicembre 2016. Sebbene attualmente il progetto sia in fase di incubazione e l'API non sia ancora definita, Handly è già utilizzato in due importanti prodotti commerciali che hanno osato essere i 'primi adottanti', e, va detto, finora non se ne pentono.
Come accennato in precedenza, uno di questi prodotti è 1C:Enterprise Development Tools, dove Handly è utilizzato fin dall'inizio per modellare gli elementi della struttura di alto livello di linguaggi come 1C:Enterprise, incluso il linguaggio di programmazione integrato e il linguaggio delle query. L'altro prodotto è meno noto al grande pubblico. È , 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 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 persino a trovare un po' di tempo libero per partecipare attivamente allo sviluppo del progetto, realizzando il layer UI (~ 4000 righe di codice) per uno degli esempi di Handly, un modello Java. Maggiori informazioni 'direttamente' sull'uso di Handly da parte degli adattatori possono essere trovate sulla pagina progetto.
Ci auguriamo che, dopo il rilascio della versione 1.0 con garanzia di stabilità API e l’uscita del progetto dallo stato di incubazione, Handly possa acquisire nuovi adattatori. Per ora, il progetto continua a testare e 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 calendario prevedibile su cui gli adattatori possono contare. Vale la pena aggiungere che il tasso di bug del progetto rimane costantemente basso e Handly funziona affidabilmente nei prodotti dei primi adottanti sin dalle sue versioni iniziali. Per ulteriori informazioni su Eclipse Handly, puoi utilizzare e .
Fonte: habr.com
