Pot ser, fa temps que no necessita cap presentació especial. Molta gent està familiaritzada amb Eclipse gràcies a les eines de desenvolupament Java d'Eclipse (). És aquest popular IDE Java de codi obert que la majoria de desenvolupadors associen amb la paraula "Eclipse". Tanmateix, Eclipse és alhora una plataforma extensible per integrar eines de desenvolupament (Eclipse Platform) i una sèrie d'IDE construïts sobre la seva base, inclòs JDT. Eclipse és alhora el projecte Eclipse, el projecte de primer nivell que coordina el desenvolupament de la plataforma Eclipse i el JDT, i l'SDK d'Eclipse, el resultat d'aquest desenvolupament. Finalment, Eclipse és una Fundació de codi obert amb una gran comunitat de projectes, no tots escrits en Java o relacionats amb eines de desenvolupament (per exemple, projectes). и ). El món d'Eclipse és molt divers.
En aquest article, que és de caràcter general, intentarem analitzar alguns dels conceptes bàsics de l'arquitectura Eclipse com a plataforma per construir eines de desenvolupament integrades i donar-nos una idea inicial dels components d'Eclipse que formen la base de la tecnologia. plataforma per al “nou Configurador” 1C: Enterprise. . Per descomptat, aquesta revisió serà inevitablement en gran mesura superficial i força limitada, inclòs perquè ens centrem no només en els desenvolupadors d'Eclipse com a públic objectiu. Tanmateix, esperem que fins i tot els desenvolupadors experimentats d'Eclipse puguin trobar informació interessant a l'article. Per exemple, parlarem d'un dels "secrets d'Eclipse", un projecte relativament nou i poc conegut. , que va ser fundada i recolzada per 1C.
Introducció a l'Arquitectura Eclipse
Vegem primer alguns aspectes generals de l'arquitectura Eclipse utilitzant l'exemple (JDT). L'elecció de JDT com a exemple no és casual. Aquest és el primer entorn de desenvolupament integrat que apareix a Eclipse. Altres projectes *DT Eclipse, com Eclipse C/C++ Development Tooling (CDT), es van crear més tard i prenen prestats tant principis arquitectònics bàsics com fragments de codi font individuals de JDT. Els fonaments de l'arquitectura establerts a JDT són rellevants fins avui per a gairebé qualsevol IDE construït sobre la plataforma Eclipse, inclosa 1C: Eines de desenvolupament empresarial.
En primer lloc, cal tenir en compte que Eclipse es caracteritza per una capa arquitectònica força clara, amb la separació de la funcionalitat independent del llenguatge de la funcionalitat dissenyada per suportar llenguatges de programació específics, i la separació dels components "nuclis" independents de la IU dels components associats. amb interfície d'usuari compatible.
Així, la plataforma Eclipse defineix una infraestructura comuna i independent del llenguatge, i les eines de desenvolupament de Java afegeixen un IDE Java amb totes les funcions a Eclipse. Tant la plataforma Eclipse com el JDT consten de diversos components, cadascun dels quals pertany a un "nucli" independent de la IU o a una capa d'IU (figura 1).
Arròs. 1. Plataforma Eclipse i JDT
Enumerem els components principals de la plataforma Eclipse:
- Temps d’execució — Defineix la infraestructura del connector. Eclipse es caracteritza per una arquitectura modular. Essencialment, Eclipse és una col·lecció de "punts d'extensió" i "extensions".
- Espai de treball — Gestiona un o més projectes. Un projecte consta de carpetes i fitxers que s'assignen directament al sistema de fitxers.
- Kit d'eines de widget estàndard (SWT) - Proporciona elements bàsics d'interfície d'usuari integrats amb el sistema operatiu.
- JFace — Proporciona una sèrie de marcs d'interfície d'usuari construïts a la part superior de SWT.
- Workbench — Defineix el paradigma d'interfície d'usuari d'Eclipse: editors, vistes, perspectives.
Cal dir que la plataforma Eclipse també proporciona molts altres components útils per crear eines de desenvolupament integrades, com ara Depuració, Comparació, Cerca i Equip. Cal fer una menció especial a JFace Text, la base per construir "editors intel·ligents" del codi font. Malauradament, fins i tot un examen superficial d'aquests components, així com dels components de la capa d'interfície d'usuari, no és possible dins de l'àmbit d'aquest article, de manera que a la resta d'aquesta secció ens limitarem a una visió general dels principals components "bàsics" de la Plataforma Eclipse i JDT.
Temps d'execució del nucli
Es basa la infraestructura del connector Eclipse i proporcionada pel projecte . Cada connector d'Eclipse és un paquet OSGi. L'especificació OSGi defineix, en particular, mecanismes per al control de versions i la resolució de dependències. A més d'aquests mecanismes estàndard, Equinox introdueix el concepte punts d'expansió. Cada connector pot definir els seus propis punts d'extensió, i també introduir funcionalitats addicionals ("extensions") al sistema mitjançant punts d'extensió definits pel mateix o altres connectors. Qualsevol descripció detallada dels mecanismes OSGi i Equinox està fora de l'abast d'aquest article. Observem només que la modularització a Eclipse és total (qualsevol subsistema, inclòs Runtime, consta d'un o més connectors) i gairebé tot a Eclipse és una extensió. A més, aquests principis estaven integrats a l'arquitectura Eclipse molt abans de la introducció d'OSGi (aleshores utilitzaven la seva pròpia tecnologia, molt semblant a l'OSGi).
Espai de treball bàsic
Gairebé qualsevol entorn de desenvolupament integrat construït sobre la plataforma Eclipse funciona amb l'espai de treball Eclipse. És l'espai de treball que sol contenir el codi font de l'aplicació desenvolupada a l'IDE. L'espai de treball s'assigna directament al sistema de fitxers i consta de projectes, que contenen carpetes i fitxers. Aquests projectes, carpetes i fitxers s'anomenen recursos espai de treball. La implementació de l'espai de treball a Eclipse serveix com a memòria cau en relació amb el sistema de fitxers, cosa que permet accelerar significativament el recorregut de l'arbre de recursos. A més, l'espai de treball ofereix una sèrie de serveis addicionals, com ara и .
El component Core Resources (connector org.eclipse.core.resources) és responsable de donar suport a l'espai de treball i als seus recursos. En particular, aquest component proporciona accés programàtic a l'espai de treball en el formulari models de recursos. Per treballar eficaçment amb aquest model, els clients necessiten una manera senzilla de presentar un enllaç a un recurs. En aquest cas, seria desitjable amagar l'objecte que emmagatzema directament l'estat del recurs al model de l'accés del client. En cas contrari, en el cas, per exemple, d'esborrar un fitxer, el client podria continuar mantenint un objecte que ja no es troba al model, amb els problemes consegüents. Eclipse resol aquest problema utilitzant una cosa anomenada gestionar recurs. Handle actua com a clau (només coneix el camí al recurs a l'espai de treball) i controla completament l'accés a l'objecte del model intern, que emmagatzema directament informació sobre l'estat del recurs. Aquest disseny és una variació del patró .
Arròs. La figura 2 il·lustra l'idioma Handle/Body aplicat al model de recursos. La interfície IResource representa el controlador d'un recurs i és una API, a diferència de la classe Resource, que implementa aquesta interfície, i la classe ResourceInfo, que representa el cos, que no són API. Destaquem que el handle només coneix el camí al recurs en relació amb l'arrel de l'espai de treball i no conté un enllaç a la informació del recurs. Els objectes d'informació de recursos formen l'anomenat "arbre d'elements". Aquesta estructura de dades es materialitza completament en la memòria. Per trobar la instància d'informació del recurs corresponent a un identificador, es recorre l'arbre d'elements segons el camí emmagatzemat en aquest identificador.
Arròs. 2. IResource i ResourceInfo
Com veurem més endavant, el disseny bàsic del model de recursos (podríem anomenar-lo basat en mànec) també s'utilitza a Eclipse per a altres models. De moment, enumerem algunes de les propietats distintives d'aquest disseny:
- Handle és un objecte de valor. Els objectes de valor són objectes immutables la igualtat dels quals no es basa en la identitat. Aquests objectes es poden utilitzar de manera segura com a clau en contenidors triturats. Diverses instàncies de maneig poden fer referència al mateix recurs. Per comparar-los, heu d'utilitzar el mètode equals(Object).
- L'handle defineix el comportament d'un recurs, però no conté informació sobre l'estat del recurs (les úniques dades que emmagatzema són la "clau", el camí al recurs).
- El maneig pot fer referència a un recurs que no existeix (ja sigui un recurs que encara no s'ha creat o un recurs que ja s'ha suprimit). L'existència d'un recurs es pot comprovar mitjançant el mètode IResource.exists().
- Algunes operacions es poden implementar basant-se únicament en la informació emmagatzemada al mateix controlador (les anomenades operacions només de maneig). Alguns exemples són IResource.getParent(), getFullPath(), etc. No cal que el recurs existeixi perquè aquesta operació tingui èxit. Les operacions que requereixen que un recurs existeixi per tenir èxit produeixen una CoreException si el recurs no existeix.
Eclipse proporciona un mecanisme eficient per notificar els canvis dels recursos de l'espai de treball (figura 3). Els recursos poden canviar com a resultat de les accions realitzades dins del propi IDE d'Eclipse o com a resultat de la sincronització amb el sistema de fitxers. En ambdós casos, els clients que es subscriuen a les notificacions reben informació detallada sobre els canvis en forma de "deltas de recursos". Un delta descriu els canvis entre dos estats d'un (sub)arbre de recursos d'espai de treball i és en si mateix un arbre, cada node del qual descriu un canvi a un recurs i conté una llista de deltes al nivell següent que descriuen els canvis als recursos secundaris.
Arròs. 3. IResourceChangeEvent i IResourceDelta
El mecanisme de notificació basat en deltas de recursos té les característiques següents:
- Un sol canvi i molts canvis es descriuen utilitzant la mateixa estructura, ja que el delta es construeix utilitzant el principi de composició recursiva. Els clients subscriptors poden processar les notificacions de canvi de recursos mitjançant un descens recursiu a través d'un arbre de deltes.
- El delta conté informació completa sobre els canvis al recurs, inclòs el seu moviment i/o els canvis en els "marcadors" associats a aquest (per exemple, els errors de compilació es representen com a marcadors).
- Com que les referències de recursos es fan a través de la maneta, delta pot fer referència naturalment a un recurs remot.
Com veurem aviat, els components principals del disseny del mecanisme de notificació de canvis en el model de recursos també són rellevants per a altres models basats en maneig.
Nucli JDT
El model de recursos d'espai de treball Eclipse és un model fonamental independent del llenguatge. El component JDT Core (plugin org.eclipse.jdt.core) proporciona una API per navegar i analitzar l'estructura de l'espai de treball des d'una perspectiva Java, l'anomenat "model Java" (Model Java). Aquesta API es defineix en termes d'elements Java, a diferència de l'API del model de recursos subjacent, que es defineix en termes de carpetes i fitxers. Les principals interfícies de l'arbre d'elements Java es mostren a la Fig. 4.
Arròs. 4. Elements del model Java
El model Java utilitza el mateix llenguatge de mànec/cos que el model de recursos (figura 5). IJavaElement és el maneig i JavaElementInfo fa el paper de cos. La interfície IJavaElement defineix un protocol comú a tots els elements Java. Alguns dels seus mètodes són només de maneig: getElementName(), getParent(), etc. L'objecte JavaElementInfo emmagatzema l'estat de l'element corresponent: la seva estructura i atributs.
Arròs. 5. IJavaElement i JavaElementInfo
El model Java té algunes diferències en la implementació del disseny bàsic del mànec/cos en comparació amb el model de recursos. Com s'ha indicat anteriorment, al model de recursos, l'arbre d'elements, els nodes del qual són objectes d'informació de recursos, està totalment contingut a la memòria. Però el model Java pot tenir un nombre significativament més gran d'elements que l'arbre de recursos, perquè també representa l'estructura interna dels fitxers .java i .class: tipus, camps i mètodes.
Per evitar materialitzar completament tot l'arbre d'elements a la memòria, la implementació del model Java utilitza una memòria cau LRU de mida limitada d'informació d'elements, on la clau és handle IJavaElement. Els objectes d'informació d'elements es creen a demanda mentre es navega per l'arbre d'elements. En aquest cas, els elements que s'utilitzen menys sovint s'eliminen de la memòria cau i el consum de memòria del model es manté limitat a la mida de memòria cau especificada. Aquest és un altre avantatge del disseny basat en mànec, que amaga completament aquests detalls d'implementació del codi del client.
El mecanisme per notificar els canvis als elements Java és, en general, similar al mecanisme de seguiment dels canvis als recursos de l'espai de treball comentat anteriorment. Un client que vulgui supervisar els canvis en el model Java es subscriu a les notificacions, que es representen com un objecte ElementChangedEvent que conté un IJavaElementDelta (figura 6).
Arròs. 6. ElementChangedEvent i IJavaElementDelta
El model Java no conté informació sobre els cossos de mètodes o la resolució de noms, de manera que per a l'anàlisi detallada del codi escrit en Java, JDT Core proporciona un model addicional (no basat en maneig): (arbre de sintaxi abstracta, AST). AST representa el resultat de l'anàlisi del text font. Els nodes AST corresponen a elements de l'estructura del mòdul font (declaracions, operadors, expressions, etc.) i contenen informació sobre les coordenades de l'element corresponent en el text font, així com (com a opció) informació sobre la resolució de noms en la forma d'enllaços als anomenats enquadernacions. Els enllaços són objectes que representen entitats amb nom, com ara tipus, mètodes i variables, conegudes pel compilador. A diferència dels nodes AST, que formen un arbre, els enllaços admeten les referències creuades i generalment formen un gràfic. La classe abstracta ASTNode és la classe base comuna per a tots els nodes AST. Les subclasses ASTNode corresponen a construccions sintàctiques específiques del llenguatge Java.
Com que els arbres de sintaxi poden consumir una quantitat important de memòria, JDT només guarda a la memòria cau un AST per a l'editor actiu. A diferència del model Java, l'AST normalment es veu com un model "intermedi", "temporal", els elements dels quals els clients no haurien de tenir referències fora del context de l'operació que va portar a la creació de l'AST.
Els tres models enumerats (model Java, AST, enllaços) junts formen la base per construir "eines de desenvolupament intel·ligents" a JDT, inclòs un potent editor de Java amb diversos "ajudants", diverses accions per processar el codi font (inclosa l'organització d'una llista d'importació). noms i format segons l'estil personalitzat), eines de cerca i refactorització. En aquest cas, el model Java juga un paper especial, ja que és el que s'utilitza com a base per a una representació visual de l'estructura de l'aplicació que s'està desenvolupant (per exemple, a l'Explorador de paquets, Esquema, Cerca, Jerarquia de trucades i Jerarquia de tipus).
Components d'Eclipse utilitzats a 1C:Eines de desenvolupament empresarial
A la Fig. La figura 7 mostra els components d'Eclipse que formen la base de la plataforma tecnològica per a 1C:Eines de desenvolupament empresarial.
Arròs. 7. Eclipse com a plataforma per a 1C:Eines de desenvolupament empresarial
Plataforma Eclipse ofereix una infraestructura bàsica. Hem analitzat alguns aspectes d'aquesta infraestructura a l'apartat anterior.
(EMF) proporciona un mitjà general per modelar dades estructurades. EMF està integrat amb la plataforma Eclipse, però també es pot utilitzar per separat en aplicacions Java habituals. Molt sovint, els nous desenvolupadors d'Eclipse ja coneixen bé l'EMF, tot i que encara no entenen completament les complexitats de la plataforma Eclipse. Un dels motius d'una popularitat tan merescuda és el disseny universal, que inclou, entre altres coses, una API unificada de metanivell, que permet treballar amb qualsevol model EMF de manera general. Les implementacions bàsiques per als objectes model proporcionades per EMF i el subsistema per generar codi de model basat en el metamodel augmenten significativament la velocitat de desenvolupament i redueixen el nombre d'errors. EMF també conté mecanismes per serialitzar models, fer el seguiment dels canvis al model i molt més.
Com qualsevol eina de propòsit general veritable, EMF és adequada per resoldre una àmplia gamma de problemes de modelatge, però algunes classes de models (per exemple, els models basats en mànecs comentats anteriorment) poden requerir eines de modelatge més especialitzades. Parlar d'EMF és una tasca ingrata, sobretot dins dels límits limitats d'un article, ja que aquest és el tema d'un llibre a part, i un de més gruixut. Recordem només que el sistema de generalitzacions d'alta qualitat subjacent a l'EMF va permetre el naixement de tota una sèrie de projectes dedicats al modelatge, que s'inclouen en el projecte de primer nivell. juntament amb el mateix EMF. Un d'aquests projectes és Eclipse Xtext.
proporciona una infraestructura de "modelació de text". Xtext utilitza per analitzar el text font i EMF per representar l'ASG resultant (gràfic semàntic abstracte, que és essencialment una combinació d'AST i enllaços), també anomenat "model semàntic". La gramàtica del llenguatge modelat per Xtext es descriu en el llenguatge propi d'Xtext. Això us permet no només generar una descripció gramatical per a ANTLR, sinó també obtenir un mecanisme de serialització AST (és a dir, Xtext proporciona un analitzador i un analitzador), una pista de context i una sèrie d'altres components del llenguatge. D'altra banda, el llenguatge gramatical utilitzat a Xtext és menys flexible que, per exemple, el llenguatge gramatical utilitzat a ANTLR. Per tant, de vegades cal “doblar” el llenguatge implementat a Xtext, cosa que no sol ser un problema si parlem d'un llenguatge que s'està desenvolupant des de zero, però pot ser inacceptable per a llengües amb una sintaxi ja establerta. Malgrat això, Xtext és actualment l'eina més madura, rica en funcions i versàtil d'Eclipse per crear llenguatges de programació i eines de desenvolupament per a ells. En particular, és una eina ideal per al prototipat ràpid (llenguatge específic del domini, DSL). A més del "nucli de llenguatge" esmentat anteriorment basat en ANTLR i EMF, Xtext ofereix molts components útils de nivell superior, inclosos mecanismes d'indexació, construcció incremental, un "editor intel·ligent" i molt, molt més, però deixa de banda els maneigs. models lingüístics basats. Igual que EMF, Xtext és un tema digne d'un llibre a part, i ara mateix difícilment podem parlar breument de totes les seves capacitats.
1C: Les eines de desenvolupament empresarial utilitzen activament tant el propi EMF com una sèrie d'altres projectes de modelització d'Eclipse. En particular, Xtext és una de les bases de les eines de desenvolupament per a llenguatges 1C: Enterprise com el llenguatge de programació integrat i el llenguatge de consulta. Una altra base d'aquestes eines de desenvolupament és el projecte Eclipse Handly, del qual parlarem amb més detall (dels components d'Eclipse enumerats, encara és el menys conegut).
, un subprojecte del projecte de primer nivell Eclipse Technology, va sorgir com a resultat d'una contribució inicial de codi a la Fundació Eclipse feta per 1C el 2014. Des de llavors, 1C ha continuat donant suport al desenvolupament del projecte: els Handly Committers són empleats de l'empresa. El projecte és petit, però ocupa un nínxol força únic a Eclipse: el seu objectiu principal és donar suport al desenvolupament de models basats en mànec.
Els principis arquitectònics bàsics dels models basats en mànec, com ara l'idioma mànec/cos, es van discutir anteriorment utilitzant el model de recursos i el model Java com a exemples. També va assenyalar que tant el model de recursos com el model Java són fonaments importants per a les eines de desenvolupament Java (JDT) d'Eclipse. I com que gairebé tots els projectes *DT Eclipse tenen una arquitectura similar a JDT, no seria una gran exageració dir que els models basats en mànecs subjacent a molts, si no tots, els IDE construïts sobre la plataforma Eclipse. Per exemple, l'Eclipse C/C++ Development Tooling (CDT) té un model C/C++ basat en mànecs que juga el mateix paper a l'arquitectura CDT que el model Java al JDT.
Abans de Handly, Eclipse no oferia biblioteques especialitzades per construir models de llenguatge basats en manetes. Els models que existeixen actualment es van crear principalment adaptant directament el codi del model Java (també conegut com copiar/enganxar), en els casos en què ho permet Eclipse Public License (EPL). (Òbviament, normalment no és un problema legal per, per exemple, els projectes d'Eclipse en si, però no per als productes de codi tancat.) A més de la seva casualitat inherent, aquesta tècnica introdueix problemes coneguts: la duplicació de codi introduïda per l'adaptació als errors, etc. El pitjor és que els models resultants segueixen sent "coses en si mateixes" i no aprofiten el potencial d'unificació. Però aïllar conceptes i protocols comuns per als models de llenguatge basats en manetes podria conduir a la creació de components reutilitzables per treballar-hi, de manera similar al que va passar en el cas de l'EMF.
No és que Eclipse no entengués aquests problemes. L'any 2005 , resumint l'experiència de desenvolupament del prototip CDT, la necessitat de crear una infraestructura comuna per als models lingüístics, inclosos els models basats en manetes. Però, com passa sovint, a causa de les tasques de major prioritat, la implementació d'aquestes idees no va arribar mai a cap. Mentrestant, la factorització del codi *DT encara és un dels temes poc desenvolupats a Eclipse.
En cert sentit, el projecte Handly està dissenyat per resoldre aproximadament els mateixos problemes que l'EMF, però per a models basats en mànecs, i principalment els de llenguatge (és a dir, que representen elements de l'estructura d'algun llenguatge de programació). Els objectius principals establerts a l'hora de dissenyar Handly s'enumeren a continuació:
- Identificació de les principals abstraccions de l'àrea temàtica.
- Reduir l'esforç i millorar la qualitat d'implementació dels models de llenguatge basats en maneig mitjançant la reutilització del codi.
- Proporcionar una API de metanivell unificada als models resultants, fent possible crear components IDE comuns que funcionin amb models basats en maneigs de llenguatge.
- Flexibilitat i escalabilitat.
- Integració amb Xtext (en una capa separada).
Per destacar conceptes i protocols comuns, es van analitzar les implementacions existents de models basats en maneigs de llenguatge. Les principals interfícies i implementacions bàsiques proporcionades per Handly es mostren a la Fig. 8.
Arròs. 8. Interfícies comunes i implementacions bàsiques dels elements Handly
La interfície IElement representa el maneig d'un element i és comuna als elements de tots els models basats en Handly. La classe abstracta Element implementa el mecanisme de mànec/cos generalitzat (Fig. 9).
Arròs. 9. Implementació IElement i handle/body genèric
A més, Handly proporciona un mecanisme generalitzat per notificar canvis en els elements del model (Fig. 10). Com podeu veure, és àmpliament similar als mecanismes de notificació implementats en el model de recursos i en el model Java, i utilitza IElementDelta per proporcionar una representació unificada de la informació de canvi d'element.
Arròs. 10. Interfícies generals i implementacions bàsiques del mecanisme de notificació Handly
La part Handly comentada anteriorment (Fig. 9 i 10) es pot utilitzar per representar gairebé qualsevol model basat en mànec. Per crear lingüística models, el projecte ofereix funcionalitats addicionals, en particular, interfícies comunes i implementacions bàsiques per als elements de l'estructura del text font, l'anomenada elements font (Fig. 8). La interfície ISourceFile representa un fitxer font i ISourceConstruct representa un element dins del fitxer font. Les classes abstractes SourceFile i SourceConstruct implementen mecanismes generalitzats per donar suport al treball amb fitxers font i els seus elements, per exemple, treballar amb memòries intermèdies de text, vincular-se a les coordenades d'un element del text font, conciliar models amb el contingut actual d'un buffer de còpia de treball. , etc. La implementació d'aquests mecanismes sol ser tot un repte, i Handly pot reduir significativament l'esforç de desenvolupar models de llenguatge basats en maneigs proporcionant implementacions de base d'alta qualitat.
A més dels mecanismes bàsics enumerats anteriorment, Handly ofereix una infraestructura per a búfers de text i instantànies, suport per a la integració amb editors de codi font (inclosa la integració immediata amb l'editor Xtext), així com alguns components d'interfície d'usuari comuns que treballar amb editors de codi font, com ara el marc d'esquema. Per il·lustrar les seves capacitats, el projecte ofereix diversos exemples, inclosa una implementació del model Java a Handly. (En comparació amb la implementació completa del model Java a JDT, aquest model es simplifica intencionadament una mica per a una major claredat).
Com s'ha assenyalat anteriorment, un enfocament important durant el disseny inicial de Handly i el desenvolupament posterior va ser i continua sent l'escalabilitat i la flexibilitat.
En principi, els models basats en mànec s'escalen força bé "per disseny". Per exemple, l'idioma mànec/cos us permet limitar la quantitat de memòria que consumeix un model. Però també hi ha matisos. Així, quan es va provar Handly per a l'escalabilitat, es va descobrir un problema en la implementació del mecanisme de notificació: quan es van canviar un gran nombre d'elements, la construcció de deltes va trigar massa temps. Va resultar que el mateix problema estava present en el model JDT Java, del qual es va adaptar el codi corresponent. Vam solucionar l'error a Handly i vam preparar un pedaç similar per a JDT, que va ser rebut amb gratitud. Aquest és només un exemple on introduir Handly a les implementacions de models existents podria ser potencialment útil, perquè en aquest cas aquest error es podria solucionar en un sol lloc.
Perquè la implementació de Handly en les implementacions de models existents sigui tècnicament factible, la biblioteca ha de tenir una flexibilitat important. El principal problema és mantenir la compatibilitat enrere en tot el model d'API. Aquest problema es va resoldre a separant clarament l'API específica del model, definida i totalment controlada pel desenvolupador, de l'API de metanivell unificada proporcionada per la biblioteca. Això no només fa que tècnicament sigui possible implementar Handly a les implementacions existents, sinó que també ofereix al desenvolupador del nou model una gran llibertat a l'hora de dissenyar l'API.
La flexibilitat també té altres aspectes. Per exemple, Handly no imposa gairebé cap restricció a l'estructura del model i es pot utilitzar per modelar llenguatges de propòsit general i específics de domini. Quan es construeix l'estructura del fitxer font, Handly no prescriu cap forma particular de representació AST i, en principi, ni tan sols requereix la presència d'un AST en si, garantint així la compatibilitat amb gairebé qualsevol mecanisme d'anàlisi. Finalment, Handly admet la integració completa amb l'espai de treball Eclipse, però també pot treballar directament amb sistemes de fitxers gràcies a la seva integració amb (EFS).
Versió actual va sortir el desembre de 2016. Malgrat que el projecte es troba actualment en estat d'incubació i l'API encara no s'ha solucionat definitivament, Handly ja s'utilitza en dos grans productes comercials que s'arriscaven a actuar com a “early adopters” i, he de dir, no et penedeixis encara.
Com s'ha indicat anteriorment, un d'aquests productes és 1C:Eines de desenvolupament empresarial, on Handly s'utilitza des del principi per modelar elements de l'estructura d'alt nivell d'aquests llenguatges 1C:Enterprise com el llenguatge de programació integrat i el llenguatge de consulta. . Un altre producte és menys conegut pel gran públic. Això , un entorn de disseny integrat per al processador de conjunts d'instruccions específics d'aplicació (ASIP), utilitzat tant a la pròpia empresa txeca Codasip com als seus clients, incloent , , , . Codasip fa servir Handly en producció des del 2015, començant amb la versió Handly 0.2. La darrera versió de Codasip Studio utilitza la versió 0.5, publicada el juny de 2016. Ondřej Ilčík, que lidera el desenvolupament de l'IDE a Codasip, està en contacte amb el projecte, proporcionant comentaris vitals en nom del "tercer adoptant". Fins i tot va poder trobar una mica de temps lliure per participar directament en el desenvolupament del projecte, implementant una capa d'IU (~4000 línies de codi) per a un dels exemples de Handly, un model Java. Podeu trobar informació de primera mà més detallada sobre l'ús de Handly per part dels adoptants a la pàgina projecte.
Esperem que després del llançament de la versió 1.0 amb garantia d'estabilitat de l'API i que el projecte surti de l'estat d'incubació, Handly tingui nous adoptants. Mentrestant, el projecte continua provant i millorant encara més l'API, llançant dues versions "principals" a l'any: al juny (la mateixa data que la publicació simultània d'Eclipse) i desembre, proporcionant un calendari previsible en el qual els usuaris poden confiar. També podem afegir que la "taxa d'errors" del projecte es manté a un nivell constantment baix i Handly ha estat treballant de manera fiable en els productes dels primers usuaris des de les primeres versions. Per explorar més a fons Eclipse Handly, podeu utilitzar и .
Font: www.habr.com