Eclipse като технологична платформа за 1C:Enterprise Development Tools

вероятно Затъмнение вече не се нуждае от специално представяне. Много хора са запознати с Eclipse благодарение на инструментите за разработка на Eclipse Java (JDT). Именно тази популярна Java IDE с отворен код повечето разработчици свързват с думата „Eclipse“. Въпреки това, Eclipse е както разширяема платформа за интегриране на инструменти за разработка (Eclipse Platform), така и редица IDE, изградени върху нея, включително JDT. Eclipse е както Eclipse Project, проектът от най-високо ниво, който координира разработката на Eclipse Platform и JDT, така и Eclipse SDK, доставимият резултат от тази разработка. И накрая, Eclipse е фондация с отворен код с огромна общност от проекти, не всички от които са написани на Java или са свързани с инструменти за разработка (например проекти Eclipse IoT и Eclipse Science). Светът на Eclipse е много разнообразен.

В тази обзорна статия ще се опитаме да разгледаме някои от основите на архитектурата на Eclipse като платформа за изграждане на интегрирани инструменти за разработка и ще дадем първоначална представа за компонентите на Eclipse, които формират основата на технологичната платформа за “ нов конфигуратор” 1C: Enterprise, 1C: Средства за разработка на предприятия. Разбира се, такъв преглед неизбежно ще бъде до голяма степен повърхностен и доста ограничен, също и защото не сме насочени само към разработчиците на Eclipse като целева аудитория. Надяваме се обаче, че дори опитни разработчици на Eclipse ще могат да намерят интересна информация в статията. Например, ще говорим за една от "тайните на Eclipse", сравнително нов и малко известен проект досега. Eclipse Handy, която е основана и поддържана от 1C.

Въведение в архитектурата на Eclipse

Нека първо да разгледаме някои общи аспекти на архитектурата на Eclipse, използвайки пример Eclipse Java инструменти за разработка (JDT). Изборът на JDT като пример не е случаен. Това е първата IDE, която се появява в Eclipse. Други *DT Eclipse проекти, като Eclipse C/C++ Development Tooling (CDT), са създадени по-късно и са заимствали както основните архитектурни принципи, така и фрагменти от изходния код от JDT. Основите на архитектурата, заложени в JDT, са актуални и до днес за почти всяка IDE, изградена върху платформата Eclipse, включително 1C:Enterprise Development Tools.

На първо място, трябва да се отбележи, че Eclipse се характеризира с доста ясна архитектурна стратификация, с разделянето на независимата от езика функционалност от функционалността, предназначена да поддържа специфични езици за програмиране, и отделянето на независимо от UI „ядро“ (ядро) компоненти от компоненти, свързани с поддръжката на потребителя интерфейс.

Например платформата Eclipse дефинира обща, независима от езика инфраструктура, а инструментите за разработка на Java добавят пълнофункционална Java IDE към Eclipse. Както платформата Eclipse, така и JDT са съставени от няколко компонента, всеки от които е или независимо от UI „ядро“ или UI слой (Фигура 1).

Ориз. 1. Платформа Eclipse и JDT

Изброяваме основните компоненти на платформата Eclipse:

• Runtime - Дефинира инфраструктурата на плъгина. Eclipse има модулна архитектура. По същество Eclipse е колекция от „разширителни точки“ и „разширения“.
• Работно пространство - Управлява един или повече проекти. Проектът се състои от папки и файлове, които се свързват директно с файловата система.
• Standard Widget Toolkit (SWT) - Осигурява основни елементи на потребителския интерфейс, които са интегрирани с операционната система.
• JFace - Предоставя набор от UI рамки, изградени върху SWT.
• Workbench - Дефинира парадигмата на потребителския интерфейс на Eclipse: редактори, изгледи, перспективи.

Трябва да кажа, че платформата Eclipse предоставя много други полезни компоненти за изграждане на интегрирани инструменти за разработка, сред които са Debug, Compare, Search и Team. Трябва да споменем и JFace Text – основата за изграждане на „умни редактори“ на изходния код. За съжаление, дори бегъл преглед на тези компоненти, както и на компонента на потребителския интерфейс, не е възможен в рамките на тази статия, така че в останалата част от този раздел ще се ограничим до преглед на основните "основни" компоненти на Eclipse Платформа и JDT.

време за изпълнение на ядрото

Eclipse Plugin Framework е базиран на OSGi и предвидени от проекта Затъмнение Равноденствие. Всеки плъгин на Eclipse е OSGi пакет. Спецификацията OSGi дефинира, наред с други неща, механизми за управление на версии и разрешаване на зависимости. В допълнение към тези стандартни механизми, Equinox въвежда концепцията точки за разширение. Всеки плъгин може да дефинира свои собствени точки за разширение, както и да добавя допълнителна функционалност („разширения“) към системата, използвайки точки за разширение, дефинирани от същия или други добавки. Всяко подробно описание на механизмите OSGi и Equinox е извън обхвата на тази статия. Отбелязваме само, че модулирането в Eclipse е тотално (всяка подсистема, включително Runtime, се състои от един или повече добавки) и почти всичко в Eclipse е разширение. Освен това тези принципи са включени в архитектурата на Eclipse много преди въвеждането на OSGi (по това време се използва тяхната собствена технология, в много отношения подобна на OSGi).

основно работно пространство

Почти всяка IDE, изградена върху платформата Eclipse, работи с работното пространство на Eclipse. Това е работното пространство, което обикновено съдържа изходния код на приложението, което се разработва в IDE. Работното пространство се свързва директно с файловата система и се състои от проекти, които съдържат папки и файлове. Тези проекти, папки и файлове се извикват ресурси работно пространство. Внедряването на работното пространство в Eclipse служи като кеш по отношение на файловата система, което може значително да ускори обхождането на дървото на ресурсите. В допълнение, workspace предоставя редица допълнителни услуги, включително механизъм за уведомяване за промяна на ресурса и инкрементална строителна инфраструктура.

Компонентът Core Resources (org.eclipse.core.resources plugin) е отговорен за поддръжката на работното пространство и неговите ресурси. По-специално, този компонент осигурява програмен достъп до работното пространство във формуляра ресурсни модели. За да работят ефективно с този модел, клиентите се нуждаят от лесен начин за представяне на връзка към ресурс. В същото време би било желателно да се скрие обектът, който директно съхранява състоянието на ресурса в модела от клиентски достъп. В противен случай, в случай например на изтриване на файл, клиентът може да продължи да държи обект, който вече не е в модела, с произтичащите от това проблеми. Eclipse решава този проблем с помощта на т.нар дръжка ресурс. Handle действа като ключ (познава само пътя до ресурса в работното пространство) и напълно контролира достъпа до обекта на вътрешния модел, който директно съхранява информация за състоянието на ресурса. Този дизайн е вариация на модела Дръжка/тяло.

Ориз. 2 илюстрира идиома Handle/Body, приложен към ресурсен модел. Интерфейсът IResource представлява манипулатора на ресурс и е API, за разлика от класа Resource, който имплементира този интерфейс, и класа ResourceInfo, който представлява body, които не са API. Подчертаваме, че манипулаторът знае само пътя до ресурса спрямо корена на работното пространство и не съдържа връзка към информация за ресурса. Информационните обекти за ресурси образуват това, което е известно като "елементно дърво". Тази структура от данни е напълно материализирана в паметта. За да се намери екземпляр с информация за ресурс, съответстващ на някакъв манипулатор, дървото на елемента се преминава според пътя, съхранен в този манипулатор.

Ориз. 2. IResource и ResourceInfo

Както ще видим по-късно, основният дизайн на ресурсния модел (можете да го наречете базиран на манипулатори) се използва в Eclipse и за други модели. Междувременно, ето някои от отличителните характеристики на този дизайн:

• Дръжката е стойностен обект. Стойностните обекти са неизменни обекти, чието равенство не се основава на идентичност. Такива обекти могат безопасно да се използват като ключ в хеширани контейнери. Няколко екземпляра на манипулатор могат да се отнасят към един и същ ресурс. За да ги сравните, използвайте метода equals(Object).
• Handle определя поведението на ресурса, но не съдържа информация за състоянието на ресурса (единствените данни, които съхранява, са "ключът", пътят към ресурса).
• Манипулаторът може да се отнася до ресурс, който не съществува (или ресурс, който все още не е създаден, или ресурс, който вече е изтрит). Съществуването на ресурс може да се провери с помощта на метода IResource.exists().
• Някои операции могат да бъдат изпълнени въз основа единствено на информацията, съхранена в самия манипулатор (така наречените операции само с манипулатори). Примери са IResource.getParent(), getFullPath() и т.н. Не е необходимо ресурсът да съществува, за да успее такава операция. Операции, които изискват ресурсът да съществува, за да успеят, хвърлят изключение (CoreException), ако ресурсът не съществува.

Eclipse предоставя ефективен механизъм за уведомяване за промени в ресурсите на работното пространство (Фигура 3). Ресурсите могат да се променят както в резултат на действия, извършени в самата IDE на Eclipse, така и в резултат на синхронизация с файловата система. И в двата случая клиентите, които се абонират за известията, получават подробна информация за промените под формата на „делта на ресурса“ (resource delta). Делтата описва промените между две състояния на (под)дървото на ресурсите на работното пространство и само по себе си е дърво, всеки възел от което описва промяна на някакъв ресурс и съдържа списък с делти от следващо ниво, които описват промените на дъщерните ресурси.

Ориз. 3. IResourceChangeEvent и IResourceDelta

Механизмът за уведомяване, базиран на делта на ресурсите, има следните характеристики:

• Една единствена промяна и много промени са описани с помощта на една и съща структура, тъй като делтата е изградена според принципа на рекурсивна композиция. Абонатните клиенти могат да обработват известия за промяна на ресурса чрез рекурсивно низходящо делта дърво.
• Делтата съдържа пълна информация за промяната на ресурса, включително неговото движение и/или промяна на "маркерите", свързани с него (маркерите представляват например грешки при компилиране).
• Тъй като препратките към ресурси се правят чрез манипулатора, делтата може естествено да се отнася до отдалечен ресурс.

Както ще видим скоро, основните елементи на дизайна на механизма за уведомяване за промяна на ресурсния модел са подходящи и за други модели, базирани на манипулатори.

JDT ядро

Ресурсният модел на работното пространство на Eclipse е фундаментален независим от езика модел. Компонентът JDT Core (org.eclipse.jdt.core плъгин) предоставя API за навигация и анализ на структурата на работното пространство от гледна точка на Java, така нареченият „модел на Java“ (java модел). Този API е дефиниран от гледна точка на елементи на Java, за разлика от базовия API на ресурсния модел, който е дефиниран от гледна точка на папки и файлове. Основните интерфейси на дървото на елементите на Java са показани на фиг. 4.

Ориз. 4. Елементи на Java модела

Моделът на Java използва същия идиом за манипулатор/тяло като ресурсния модел (Фигура 5). IJavaElement е дръжката, а JavaElementInfo е тялото. Интерфейсът IJavaElement дефинира общ протокол за всички Java елементи. Някои от неговите методи са само за обработка: getElementName(), getParent() и т.н. Обектът JavaElementInfo съхранява състоянието на съответния елемент: неговата структура и атрибути.

Ориз. 5. IJavaElement и JavaElementInfo

Моделът на Java има някои разлики в изпълнението на основния дизайн на ръкохватката/тялото в сравнение с ресурсния модел. Както беше отбелязано по-горе, в ресурсен модел дърво на елементи, чиито възли са информационни обекти за ресурси, се съдържа изцяло в паметта. Но един Java модел може да има много по-голям брой елементи от дървото на ресурсите, защото съдържа и вътрешната структура на .java и .class файлове: типове, полета и методи.

За да се избегне пълното материализиране на цялото дърво на елементите в паметта, изпълнението на модела на Java използва LRU кеш с информация за елемент с ограничен размер, където ключът е манипулатор IJavaElement. Обектите с информация за елемента се създават при поискване, докато дървото на елемента се навигира. В този случай най-рядко използваните елементи се изваждат от кеша и потреблението на памет на модела остава ограничено от определения размер на кеша. Това е още едно предимство на дизайна, базиран на манипулатори, който напълно скрива подобни детайли на изпълнение от клиентския код.

Механизмът за уведомяване за промени в Java елементи е като цяло подобен на механизма за проследяване на промените в ресурсите на работното пространство, обсъден по-горе. Клиент, който иска да проследи промените в модела на Java, се абонира за известия, които са представени като обект ElementChangedEvent, който съдържа IJavaElementDelta (Фигура 6).

Ориз. 6.ElementChangedEvent и IJavaElementDelta

Моделът на Java не съдържа информация за тялото на методите или разрешаването на имена, така че за подробен анализ на кода, написан на Java, JDT Core предоставя допълнителен (небазиран на манипулатори) модел: абстрактно синтактично дърво (абстрактно синтактично дърво, AST). AST представлява резултата от анализирането на оригиналния текст. AST възлите съответстват на структурните елементи на изходния модул (декларации, оператори, изрази и т.н.) и съдържат информация за координатите на съответния елемент в изходния текст, както и (по избор) информация за разрешаване на имена под формата на връзки към т.н. Наречен автомати. Обвързванията са обекти, които представляват наименувани обекти като типове, методи и променливи, известни на компилатора. За разлика от AST възлите, които образуват дърво, обвързванията поддържат кръстосани препратки и обикновено образуват графика. Абстрактният клас ASTNode е общият базов клас за всички AST възли. Подкласовете на ASTNode съответстват на определени синтактични конструкции на езика Java.

Тъй като синтактичните дървета могат да консумират значително количество памет, JDT кешира само един AST за всеки активен редактор. За разлика от модела на Java, AST обикновено се разглежда като "междинен", "временен" модел, чиито елементи не трябва да се запазват от клиенти извън контекста на операцията, която е създала AST.

Тези три модела (Java модел, AST, свързвания) заедно формират основата за изграждане на „интелигентни инструменти за разработка“ в JDT, включително мощен Java редактор с различни „помощници“, различни действия за обработка на изходния код (включително организиране на списък за импортиране на имена и форматиране според персонализирания стил), инструменти за търсене и рефакторинг. В този случай моделът на Java играе специална роля, тъй като именно той се използва като основа за визуално представяне на структурата на разработеното приложение (например в Package Explorer, Outline, Search, Call Hierarchy и Типова йерархия).

Компонентите на Eclipse, използвани в 1C:Enterprise Developments Tools

На фиг. Фигура 7 показва компонентите на Eclipse, които формират основата на технологичната платформа за 1C:Enterprise Development Tools.

Ориз. 7. Eclipse като платформа за 1C:Enterprise Development Tools

Платформа Eclipse осигурява основната инфраструктура. Покрихме някои аспекти на тази инфраструктура в предишния раздел.

Рамка за моделиране на Eclipse (EMF) предоставя обща рамка за моделиране на структурирани данни. EMF е интегриран с платформата Eclipse, но може да се използва и самостоятелно в обикновени Java приложения. Доста често начинаещите разработчици на Eclipse вече са доста запознати с EMF, въпреки че все още не разбират напълно тънкостите на платформата Eclipse. Една от причините за такава заслужена популярност е универсалният дизайн, който включва, наред с други неща, унифициран API на мета-ниво, който ви позволява да работите с всеки EMF модел като цяло. Базовите реализации, осигурени от EMF за моделни обекти и подсистемата за генериране на моделен код от мета-модела, значително увеличават скоростта на разработка и намаляват броя на грешките. EMF също така съдържа механизми за сериализиране на модели, проследяване на промените в модела и много повече.

Като всеки наистина многофункционален инструмент, EMF е подходящ за широк спектър от задачи за моделиране, но някои класове модели (например моделите, базирани на дръжки, обсъдени по-горе) може да се нуждаят от по-специализирани инструменти за моделиране. Да се ​​говори за ЕМП е неблагодарна задача, особено в рамките на една статия, тъй като това е тема на отделна книга, и то доста дебела. Отбелязваме само, че качествената система от обобщения, лежаща в основата на EMF, позволи раждането на цял набор от проекти за моделиране, които са включени в проекта от най-високо ниво Моделиране на Eclipse заедно със самия ЕМП. Един такъв проект е Eclipse Xtext.

Eclipse Xtext предоставя инфраструктура за "моделиране на текст". Xtext използва ANTLR за анализиране на изходния текст и EMF за представяне на получения ASG (абстрактна семантична графика, която всъщност е комбинация от AST и обвързвания), наричана още „семантичен модел“. Граматиката на език, моделиран с Xtext, е описана на родния език на Xtext. Това позволява не само да се генерира граматическо описание за ANTLR, но и да се получи AST механизъм за сериализация (т.е. Xtext предоставя както парсер, така и депарсер), контекстна подсказка и редица други езикови компоненти. От друга страна, езикът за граматично описание, използван в Xtext, е по-малко гъвкав, отколкото, да речем, езикът за граматично описание в ANTLR. Следователно понякога е необходимо да се „прегъне“ внедреният език към Xtext, което обикновено не е проблем, когато става въпрос за език, разработен от нулата, но може да е неприемливо за езици с вече установен синтаксис. Въпреки това, Xtext в момента е най-зрелият, богат на функции и многофункционален инструмент в Eclipse за изграждане на езици за програмиране и инструменти за разработка за тях. По-специално, той е идеален инструмент за бързо създаване на прототипи. езици, специфични за домейна (специфичен за домейн език, DSL). В допълнение към ANTLR и EMF базираното „езиково ядро“, споменато по-горе, Xtext предоставя много полезни компоненти от по-високо ниво, включително механизми за индексиране, инкрементално изграждане, „интелигентен редактор“ и много, много повече, но пропуска манипулатора- базирани на езикови модели. Подобно на EMF, Xtext е тема, достойна за отделна книга и едва ли можем дори накратко да опишем всичките му възможности сега.

1С:Enterprise Development Tools активно използва както самия EMF, така и редица други проекти за моделиране на Eclipse. По-специално, Xtext е една от основите на инструментите за разработка на такива 1C:Enterprise езици като вграден език за програмиране и език за заявки. Друга основа за тези инструменти за разработка е проектът Eclipse Handly, на който ще се спрем по-подробно (от изброените компоненти на Eclipse той все още е най-малко известен).

Eclipse Handy, подпроект на проекта на високо ниво на Eclipse Technology, възникнал от първоначалния принос на код към Eclipse Foundation от 1C през 2014 г. Оттогава 1C продължава да подкрепя развитието на проекта: Handly Committers са служители на компанията. Проектът е малък, но заема доста уникална ниша в Eclipse: основната му цел е да подпомогне разработването на модели, базирани на дръжки.

Основните архитектурни принципи на модели, базирани на дръжка, като идиома дръжка/тяло, бяха обсъдени по-горе, използвайки модела на ресурсите и модела на Java като пример. Той също така отбеляза, че както моделът на ресурсите, така и моделът на Java са важни основи за инструментите за разработка на Eclipse Java (JDT). И тъй като почти всички проекти на Eclipse *DT имат архитектура, подобна на JDT, няма да е голямо преувеличение да се каже, че базираните на манипулатори модели са в основата на много, ако не и на всички IDE, изградени върху платформата Eclipse. Например Eclipse C/C++ Development Tooling (CDT) има C/C++ модел, базиран на дръжка, който играе същата роля в CDT архитектурата, както моделът Java в JDT.

Преди Handly, Eclipse не предлагаше специализирани библиотеки за изграждане на езикови модели, базирани на манипулатори. Моделите, които съществуват днес, са създадени главно чрез директно адаптиране на кода на модела на Java (известен още като копиране/поставяне), в случаите, когато позволява Публичен лиценз на Eclipse (EPL). (Очевидно е, че за, да речем, собствените проекти на Eclipse това обикновено не е правен проблем, което не е случаят с продуктите със затворен код.) В допълнение към характерната си случайност, тази техника води до добре известни проблеми: дублиране на код, въведено от при адаптиране към грешки и др. Още по-лошо е, че получените модели си остават „неща сами по себе си“ и не използват съществуващия потенциал за унификация. Но разпределянето на общи концепции и протоколи за модели, базирани на езикови манипулатори, може да доведе до създаването на многократно използвани компоненти за работа с тях, подобно на това, което се случи в случая с EMF.

Това не означава, че Eclipse не разбираше тези проблеми. Още през 2005г Мартин Ешлиман, обобщавайки опита от разработването на CDT прототип, спореше необходимостта от създаване на обща инфраструктура за езикови модели, включително модели, базирани на манипулатори. Но, както често се случва, поради по-висок приоритет на задачите, тогава реализацията на тези идеи не стигна до ръцете. Междувременно факторизацията на кода на *DT проекти все още е една от слабо разработените теми в Eclipse.

В известен смисъл проектът Handly е предназначен да решава приблизително същите задачи като EMF, но за модели, базирани на манипулатори, и предимно езикови (т.е. представляващи елементи от структурата на език за програмиране). Следните са основните цели на дизайна на Handly:

• Изолиране на основните абстракции на предметната област.
• Намаляване на усилията и подобряване на качеството на внедряването на модели, базирани на езикови манипулатори чрез повторно използване на код.
• Осигуряване на унифициран API на мета-ниво към получените модели, което прави възможно създаването на общи IDE компоненти, които работят с модели, базирани на езикови манипулатори.
• Гъвкавост и мащабируемост.
• Интеграция с Xtext (в отделен слой).

За да се подчертаят общи концепции и протоколи, бяха анализирани съществуващите реализации на модели, базирани на езикови манипулатори. Основните интерфейси и базови реализации, предоставени от Handly, са показани на Фигура 8-XNUMX. XNUMX.

Ориз. 8. Общи интерфейси и основни реализации на Handly елементи

Интерфейсът IElement представлява манипулатора на елемент и е общ за елементите на всички базирани на Handly модели. Абстрактният клас Element имплементира общ механизъм дръжка/тяло (Фигура 9).

Ориз. 9. Елемент и генерична реализация на дръжка/тяло

В допълнение, Handly предоставя обобщен механизъм за уведомяване за промяна на елементите на модела (фиг. 10). Както можете да видите, в общи линии той е подобен на механизмите за уведомяване, внедрени в модела на ресурсите и модела на Java, и използва IElementDelta, за да осигури унифицирано представяне на информацията за промяна на елемента.

Ориз. 10. Общи интерфейси и основни реализации на механизма за уведомяване Handly

Частта от Handly, разгледана по-горе (фиг. 9 и 10), може да се използва за представяне на почти всички модели, базирани на дръжка. За създаване лингвистичен модели, проектът предлага допълнителна функционалност - по-специално общи интерфейси и базови реализации за елементи на структурата на изходния текст, т.нар. изходни елементи (фиг. 8). Интерфейсът ISourceFile представлява файл източник, а ISourceConstruct представлява елемент в рамките на файла източник. Абстрактните класове SourceFile и SourceConstruct реализират общи механизми за поддръжка на работа с изходни файлове и техните елементи, например работа с текстови буфери, обвързване с координати на елемент в изходния текст, съгласуване на модела с текущото съдържание на буфера на работното копие и т.н. . Внедряването на тези механизми обикновено е доста предизвикателство и Handly може значително да намали усилията за разработване на езикови модели, базирани на манипулатори, като предостави качествени базови реализации.

В допълнение към основните механизми, изброени по-горе, Handly предоставя текстов буфер и инфраструктура за моментни снимки, поддръжка за интеграция с редактори на изходния код (включително интеграция извън кутията с редактора Xtext), както и някои общи UI компоненти, които работят с модели на Handly като структурата на очертанията. За да илюстрира своите възможности, проектът предоставя няколко примера, включително внедряването на Java модела на Handly. (В сравнение с пълната реализация на Java модела в JDT, този модел е умишлено донякъде опростен за по-голяма яснота.)

Както беше отбелязано по-рано, първоначалният дизайн и разработка на Handly бяха и продължават да бъдат силно фокусирани върху скалируемостта и гъвкавостта.

По принцип моделите с дръжки се мащабират добре „по дизайн“. Например идиомът дръжка/тяло ви позволява да ограничите количеството памет, консумирано от модела. Но има и нюанси. И така, при тестване на Handly за мащабируемост беше открит проблем при внедряването на механизма за уведомяване - при промяна на голям брой елементи изграждането на делта отне твърде много време. Оказа се, че същият проблем присъства и в Java JDT модела, от който навремето беше адаптиран съответният код. Поправихме грешка в Handly и подготвихме подобна корекция за JDT, която беше приета с благодарност. Това е само един пример, при който внедряването на Handly в съществуващи реализации на модели може да бъде потенциално полезно, тъй като би било възможно да се коригира такъв бъг само на едно място.

За да бъде технически осъществимо вграждането на Handly в съществуващи реализации на модела, библиотеката трябва да бъде изключително гъвкава. Основният проблем е да се поддържа обратна съвместимост с API на модела. Този проблем беше решен в Удобен 0.5 чрез ясно разделяне на специфичния за модела API, дефиниран и напълно контролиран от разработчика, от унифицирания API на мета ниво, предоставен от библиотеката. Това не само прави технически възможно внедряването на Handly в съществуващи реализации, но също така дава на разработчика на новия модел много свобода в дизайна на API.

Гъвкавостта има и други аспекти. Например Handly не налага почти никакви ограничения върху структурата на модела и може да се използва за моделиране на езици с общо предназначение, както и на специфични за домейн езици. Когато конструира структурата на изходния файл, Handly не предписва никаква конкретна форма на представяне на AST и по принцип дори не изисква наличието на самия AST, като по този начин гарантира съвместимост с почти всеки механизъм за анализиране. И накрая, Handly поддържа пълна интеграция с работното пространство на Eclipse, но може да работи и директно с файлови системи благодарение на интеграцията си с Файлова система Eclipse (EFS).

Сегашна версия Удобен 0.6 издаден през декември 2016 г. Въпреки факта, че проектът в момента е в състояние на инкубация и API все още не е окончателно коригиран, Handly вече се използва в два големи комерсиални продукта, които се впуснаха в ролята на „ранни осиновители“ и, трябва да кажа, правят още не съжалявам.

Както беше отбелязано по-горе, един от тези продукти е 1C:Enterprise Development Tools, където Handly се използва от самото начало за моделиране на елементи от структурата на високо ниво на такива 1C:Enterprise езици като вграден език за програмиране и език за заявки. Друг продукт е по-малко известен на широката публика. Това Студио Codasip, интегрирана среда за проектиране за специфични за приложението процесори за набор от инструкции (ASIP), използвани както в самата чешка компания Codasip, така и от нейните клиенти, включително AMD, AVG, mobileye, Sigma Designs. Codasip използва Handly в производството от 2015 г., започвайки с Handly 0.2. Последната версия на Codasip Studio в момента използва версия 0.5, издадена през юни 2016 г. Ondřej Ilčík, който ръководи разработването на IDE в Codasip, е в контакт с проекта, предоставяйки критична обратна връзка от името на „осиновителя от трета страна“. Той дори успя да намери малко свободно време, за да допринесе директно за развитието на проекта чрез внедряване на UI слой (~4000 реда код) за един от примерите на Handly, модел на Java. За повече информация от първа ръка относно използването на Handly от адаптери вижте Разкази за успеха проект.

Надяваме се, че след пускането на версия 1.0 с гаранция за стабилност на API и излизането на проекта от състоянието на инкубация, Handly ще има и нови осиновители. Междувременно проектът продължава да тества и усъвършенства допълнително API с две „големи“ издания годишно, през юни (същата дата като едновременната версия на Eclipse) и декември, осигурявайки предвидим график, на който осиновителите могат да разчитат. Можем също да добавим, че „процентът на грешки“ на проекта остава на постоянно ниско ниво и Handly работи надеждно в продуктите на ранните осиновители още от първите версии. За по-нататъшно запознаване с Eclipse Handly можете да използвате Урок за работа и Архитектурен преглед.

Източник: www.habr.com