Вероятно, отдавна не требует особенного представления. Многим известен Eclipse благодаря инструментам разработки Java (). Именно эта популярная open-source Java IDE ассоциируется у большинства разработчиков со словом «Eclipse». Однако Eclipse – это также расширяемая платформа для интеграции средств разработки (Eclipse Platform), и целый ряд IDE, построенных на её основе, в том числе JDT. Eclipse – это также проект Eclipse Project, который координирует разработку платформы Eclipse и JDT, а также Eclipse SDK – конечный продукт этой разработки. В конце концов, Eclipse – это open-source Foundation с огромным сообществом проектов, многие из которых написаны не только на Java и не имеют отношения к инструментам разработки (например, проекты и ). Мир Eclipse действительно многообразен.
В этой обзорной статье мы постараемся рассмотреть некоторые основы архитектуры Eclipse как платформы для создания интегрированных средств разработки и дать начальное представление о компонентах Eclipse, которые формируют основу технологической платформы для «нового Конфигуратора» 1C: Предприятие, . Разумеется, такое рассмотрение будет во многом поверхностным и ограниченным, потому что мы ориентируемся не только на разработчиков Eclipse. Тем не менее, надеемся, что даже опытные разработчики Eclipse смогут найти в статье что-то интересное для себя. Например, мы расскажем об одном из «секретов Eclipse», относительно новом и малоизвестном проекте , который был основан и поддерживается компанией 1C.
Введение в архитектуру Eclipse
Давайте сначала рассмотрим некоторые общие аспекты архитектуры Eclipse на примере (JDT). Выбор JDT в качестве примера не случаен. Это первая интегрированная среда разработки, которая появилась в Eclipse. Остальные *DT проекты Eclipse, такие как Eclipse C/C++ Development Tooling (CDT), были созданы позже и заимствовали как основные архитектурные принципы, так и отдельные фрагменты исходного кода из JDT. Основы архитектуры, заложенные в JDT, актуальны и по сей день для практически любой IDE, построенной на платформе Eclipse, в том числе и для 1C:Enterprise Development Tools.
На първо място, трябва да се отбележи, че Eclipse има ясно изразена архитектурна разделеност, с отделяне на езиково-неутралната функционалност от функционалността, предназначена за поддръжка на конкретни програмни езици, и отделяне на UI-неутралните "ядра" (core) компоненти от компонентите, свързани с поддръжка на потребителския интерфейс.
Eclipse Platform определя общата езиково-неутрална инфраструктура, а инструментите за разработка на Java добавят към Eclipse напълнофункционална Java IDE. Както Eclipse Platform, така и JDT се състоят от множество компоненти, всяка от които принадлежи или на UI-неутралното "ядро", или на UI слоя (рис. 1).
Рис. 1. Eclipse Platform и JDT
Нека изброим основните компоненти на Eclipse Platform:
- Runtime — Определя инфраструктурата на плъгините. Eclipse има модулна архитектура. По същество, Eclipse е колекция от "точки на разширение" и "разширения".
- Workspace — Управлява един или няколко проекта. Проектът се състои от папки и файлове, които се показват директно в файловата система.
- Standard Widget Toolkit (SWT) — Предоставя основни елементи на потребителския интерфейс, интегрирани с операционната система.
- JFace — Предоставя набор от UI рамки, изградени върху SWT.
- Работна станция — Определя UI-парадигмата на Eclipse: редактори, изгледи, перспективи.
Трябва да се отбележи, че Eclipse Platform предлага и много други полезни компоненти за изграждане на интегрирани средства за разработка, сред които могат да се споменат Debug, Compare, Search и Team. Отделно трябва да се спомене и JFace Text – основата за изграждане на "умни редактори" на изходен код. За съжаление, дори бегъл преглед на тези компоненти, както и на компонентите от UI слоя не е възможен в рамките на тази статия, затова в оставащата част на тази секция ще се ограничим до преглед на основните "ядрени" компоненти на Eclipse Platform и JDT.
Core Runtime
Инфраструктурата на плъгините на Eclipse се основава на и се предоставя от проекта . Всеки плъгин на Eclipse е OSGi пакет. Спецификацията OSGi определя, включително и механизмите за версииране и разрешаване на зависимости. В допълнение към тези стандартни механизми, Equinox въвежда понятието точка на разширение. Все плъгини могат да определят свои точки за разширения, както и да въвеждат допълнителна функционалност в системата („разширения“), използвайки точки за разширение, определени от самите тях или от други плъгини. Подробно описание на механизмите OSGi и Equinox излиза извън рамките на тази статия. Само ще отбележим, че модулизацията в Eclipse е тотална (всяка подсистема, включително Runtime, се състои от един или повече плъгини) и практически всичко в Eclipse е разширение. Освен това, тези принципи бяха заложени в архитектурата на Eclipse дълго преди внедряването на OSGi (по това време се използваше собствена технология, до голяма степен аналогична на OSGi).
Основно работно пространство
Практически всяка интегрирана среда за разработка, построена на основата на платформата Eclipse, работи с Eclipse workspace. Работното пространство обикновено съдържа изходния код на разработеното в IDE приложение. Workspace директно отразява файловата система и се състои от проекти, които съдържат папки и файлове. Тези проекти, папки и файлове се наричат ресурси workspace. Реализацията на workspace в Eclipse служи като кеш по отношение на файловата система, което значително ускорява обхода на дървото с ресурси. Освен това, workspace предоставя набор от допълнителни услуги, включително и .
За поддръжката на workspace и ресурсите му отговаря компонентата Core Resources (плъгин org.eclipse.core.resources). По-специално, тази компонента предоставя програмен достъп до workspace под формата на модел на ресурси. За ефективна работа с този модел клиентите се нуждаят от прост метод за представяне на връзка с ресурс. При това обектът, който непосредствено съхранява състоянието на ресурса в модела, трябва да бъде скрит от клиентския достъп. В противен случай, в случай например на изтриване на файл, клиентът може да продължи да държи обект, който вече не съществува в модела, което води до проблеми. Eclipse решава този проблем, използвайки така наречения handle на ресурс. Handle играе ролята на ключ (той знае само пътя до ресурса в workspace) и напълно контролира достъпа до вътрешния обект на модела, който непосредствено съхранява информацията за състоянието на ресурса. Този дизайн представлява вариация на модела .
Рис. 2 илюстрира идиомата Handle/Body във връзка с модела на ресурсите. Интерфейсът IResource представя handle на ресурса и е API, за разлика от класа Resource, който реализира този интерфейс, и класа ResourceInfo, представляващ body, които не са API. Подчертаваме, че handle знае само пътя до ресурса спрямо корена на работното пространство и не съдържа информация за resource info. Обектите resource info образуват така нареченото „дърво на елементите“ (element tree). Тази структура от данни е напълно материализирана в паметта. За да намерите екземпляр на resource info, отговарящ на даден handle, element tree се обходи в съответствие с пътя, съхраняван в този handle.
Рис. 2. IResource и ResourceInfo
Както ще видим по-късно, основният дизайн на модела на ресурсите (може да го наречем handle-based) се използва и в Eclipse и за други модели. А за сега нека изброим някои отличителни свойства на този дизайн:
- Handle е обект със стойност (value object). Обектите със стойност са неизменяеми (immutable) обекти, чиято равност не се основава на идентичност. Такива обекти могат безопасно да се използват като ключ в хеширани контейнери. Няколко екземпляра на handle могат да сочат към един и същи ресурс. За тяхното сравнение трябва да се използва методът equals(Object).
- Handle определя поведението на ресурса, но не съдържа информация за състоянието на ресурса (единствените данни, които съхранява, са „ключът“, пътят до ресурса).
- Handle може да сочи към несъществуващ ресурс (или ресурс, който все още не е създаден, или ресурс, който вече е изтрит). Съществуването на ресурс може да се провери с метода IResource.exists().
- Някои операции могат да бъдат реализирани изцяло на базата на информацията, съхранявана в самия handle (т.нар. handle-only операции). Примери за това са IResource.getParent(), getFullPath() и т.н. Ресурсът не е задължителен за успешно изпълнение на такава операция. Операции, за успешното изпълнение на които е необходимо ресурсът да съществува, генерират изключение (CoreException), ако ресурсът не съществува.
Eclipse предлагае ефективен механизъм за уведомяване за изменения в ресурсите на работното пространство (фиг. 3). Ресурсите могат да се променят както в резултат на действия, извършвани в самата Eclipse IDE, така и в резултат на синхронизация с файловата система. В двата случая на клиентите, записали се за уведомления, се предоставя детайлна информация за промените под формата на «ресурсни делти» (resource delta). Делтата описва измененията между две състояния (под-)дърво на ресурсите в работното пространство и сама по себе си е дърво, всеки възел от което описва промяна на определен ресурс и съдържа списък с делти на следващото ниво, описващи изменения на дъщерните ресурси.
Фиг. 3. IResourceChangeEvent и IResourceDelta
Механизмът на уведомление, основан на ресурсни делти, има следните характеристики:
- Едно изменение и множество изменения се описват с помощта на една и съща структура, тъй като делтата е изградена на принципа на рекурсивна композиция. Клиентите, записали се за уведомления, могат да обработват уведомления за промяна на ресурсите чрез рекурсивно спускане по дървото на делтите.
- Делтата съдържа пълна информация за промяната на ресурса, включително неговото преместване и/или изменение на свързаните с него «маркировки» (например, грешки при компилация се представят под формата на маркировки).
- Тъй като референциите към ресурса са направени чрез handle, делтата може естествено да направи справка към отдалечен ресурс.
Както скоро ще видим, основните съставки на дизайна на механизма за уведомление за промяна на модела на ресурсите са актуални и за други модели, базирани на handle.
JDT Core
Моделът на ресурсите на Eclipse работното пространство е основен езиково-независим модел. Компонентата JDT Core (плъгин org.eclipse.jdt.core) предоставя API за навигация и анализ на структурата на работното пространство от гледна точка на Java, така нареченият «Java модел» (Java model). Този API е дефиниран в термини на елементи на Java, в противовес на по-ниското ниво на API на моделa на ресурсите, който е дефиниран в термини на папки и файлове. Основните интерфейси на дървото на елементите на Java са изобразени на фиг. 4.
Фиг. 4. Елементи на Java модела
Моделът Java използва същата идиома handle/body, както и моделът на ресурсите (фиг. 5). IJavaElement е handle, а JavaElementInfo играе ролята на body. Интерфейсът IJavaElement определя протокол, общ за всички елементи на Java. Някои от методите му са само за handle: getElementName(), getParent() и т.н. Обектът JavaElementInfo съхранява състоянието на съответния елемент: неговата структура и атрибути.
Фиг. 5. IJavaElement и JavaElementInfo
Моделът Java има някои различия в реализирането на основния дизайн handle/body в сравнение с модела на ресурсите. Както беше отбелязано по-горе, в модела на ресурсите, дървото на елементите, чиито възли са обекти с информация за ресурсите, е напълно съхранено в паметта. Но в модела Java може да има значително повече елементи, отколкото в дървото на ресурсите, тъй като той представя и вътрешната структура на .java и .class файлове: типове, полета и методи.
За да се избегне пълната материализация на цялото дърво от елементи в паметта, реализацията на модела Java използва ограничен по размер LRU кеш за информация за елементите, където ключът е handle IJavaElement. Обектите с информация за елементите се създават по заявка, в процеса на навигация в дървото от елементи. При това, най-рядко използваните елементи се изместват от кеша, а потреблението на паметта от модела остава ограничено на зададения размер на кеша. Това е още едно предимство на дизайна, базиран на handle, който напълно скрива тези подробности от клиентския код.
Механизмът за известяване за промени в елементите на Java в общи линии е аналогичен на разгледания по-горе механизъм за проследяване на промените в ресурсите на работното пространство. Клиентът, желаещ да следи промени в модела на Java, се абонира за известия, които се представят под формата на обект ElementChangedEvent, който съдържа IJavaElementDelta (фиг. 6).
Фиг. 6. ElementChangedEvent и IJavaElementDelta
Моделът Java не съдържа информация за тялото на методите или разрешението на имената, поради което за детайлен анализ на кода, написан на Java, JDT Core предоставя допълнителна (не базирана на handle) модел: (абстрактно синтактично дърво, AST). AST представлява резултата от синтактичен анализ на изходния текст. Възлите на AST съответстват на елементите на структурата на изходния модул (декларации, оператори, изрази и т.н.) и съдържат информация за координатите на съответния елемент в изходния текст, както и (по избор) информация за разрешаването на имената под формата на препратки към така наречените bindingsBindings са обекти, представляващи именувани единици, като типове, методи и променливи, познати на компилатора. В контекста на AST узли, които образуват дърво, bindings поддържат кръстосани препратки и в общия случай образуват граф. Абстрактният клас ASTNode е общ основен клас за всички AST узли. Подкласовете на ASTNode съответстват на определени синтактични конструкции на езика Java.
Тъй като синтактичните дървета могат да заемат значително количество памет, JDT кешира само едно AST за активния редактор. В контекста на Java модел, AST обикновено се разглежда като "междинен", "временен" модел, за който клиентите не трябва да държат препратки извън контекста на операцията, довела до създаването на AST.
Трите изброени модела (Java модел, AST, bindings) заедно съставляват основата за изграждане на "интелигентни средства за разработка" в JDT, сред които мощен Java редактор с разнообразни "асистенти", различни действия за обработка на изходния код (включително организиране на списък с импорти и форматиране в съответствие с зададения стил), инструменти за търсене и рефакторинг. В това отношение Java моделът играе особена роля, тъй като именно той се използва като основа за визуалното представяне на структурата на разработваното приложение (например в Package Explorer, Outline, Search, Call Hierarchy и Type Hierarchy).
Компонентите на Eclipse, използвани в 1С:Enterprise Developments Tools
На рис. 7 са показани компонентите на Eclipse, които образуват основата на технологичната платформа за 1C:Enterprise Development Tools.
Рис. 7. Eclipse като платформа за 1С:Enterprise Development Tools
Eclipse Platform предоставя основна инфраструктура. Разгледахме някои аспекти на тази инфраструктура в предишния раздел.
(EMF) предоставява общи средства за моделиране на структурирани данни. EMF е интегриран с Eclipse Platform, но може да се използва и самостоятелно в стандартни Java приложения. Често начинаещите разработчици на Eclipse са добре запознати с EMF, въпреки че все още не разбират напълно тънкостите на Eclipse Platform. Една от причините за такъв заслужен успех е универсалният дизайн, който включва също и унифициран API на мета ниво, позволяващ обобщена работа с всяка EMF модел. Основаните реализации на EMF за обекти на модела и подсистемата за генериране на код на модела по мета-модел значително увеличават скоростта на разработка и намаляват броя на грешките. EMF също така съдържа механизми за сериализация на модели, проследяване на промени в модела и много други.
Както всеки наистина универсален инструмент, EMF е подходящ за решаване на широк спектър от задачи, свързани с моделиране, но някои класове модели (например, разгледаните по-горе модели с основи) може да се нуждаят от по-специализирани инструменти за моделиране. Разказването за EMF е неблагодарно занимание, особено в ограничените рамки на една статия, тъй като това е предмет на отделна книга и доста дебела. Нека просто отбележим, че качествената система от обобщения, положена в основата на EMF, е позволила появата на цял спектър от проекти, посветени на моделирането, които са част от проекта на високо ниво. в допълнение към самия EMF. Един от тези проекти е Eclipse Xtext.
предоставя инфраструктура за "текстово моделиране". Xtext използва за синтактичен анализ на изходния текст и EMF за представяне на резултантния ASG (абстрактен семантичен граф, който по същество е комбинация от AST и свързвания), наричан също така "семантична модел". Граматиката на моделируемия чрез Xtext език се описва на собствения език на Xtext. Това позволява не само генерирането на описание на граматиката за ANTLR, но и получаване на механизъм за сериализация на AST (т.е. Xtext предоставя както parser, така и unparser), контекстна подсказка и редица други езикови компоненти. От друга страна, езикът за описание на граматиката, използван в Xtext, е по-малко гъвкав в сравнение, да кажем, с езика за описание на граматиката в ANTLR. Следователно понякога е необходимо да се "подгъват" реализирания език под Xtext, което обикновено не е проблем, ако става въпрос за език, разработван от нулата, но може да е неприемливо за езици със сложна синтактична структура. Въпреки това, Xtext е в момента най-зрял, функционално пълен и универсален инструмент в Eclipse за изграждане на програмни езици и средства за тяхното разработване. В частност, той е идеален инструмент за бързо прототипиране. (domain-specific language, DSL). Освен споменатото по-горе „езиково ядро“ на базата на ANTLR и EMF, Xtext предоставя множество полезни компоненти с по-високо ниво, включително механизми за индексиране, инкрементално строителство, „умен редактор“ и много, много други, но оставя извън обсега езиковите модели, базирани на handle. Както и EMF, Xtext е предмет на отделна книга и едва ли можем дори накратко да разкажем сега за всичките му възможности.
1С:Enterprise Development Tools активно използват както EMF сам по себе си, така и редица други проекти на Eclipse Modeling. В частност, Xtext е една от основите на средствата за разработка за езици 1С:Предприятие, като вградения език за програмиране и езика за запитвания. Другата основа на тези средства за разработка е проектът Eclipse Handly, за който ще се спрем по-подробно (от споменатите компоненти на Eclipse той е най-малко известен).
, подпроект на върховото ниво Eclipse Technology е резултат от първоначална контрибуция на код в Eclipse Foundation, направена от фирма 1C през 2014 година. Оттогава фирма 1C продължава да поддържа разработката на проекта: комитери на Handly са служители на фирмата. Проектът е малък, но заема достатъчно уникално място в Eclipse: основната му цел е поддръжката на разработката на модели, базирани на handle.
Основните архитектурни принципи на моделите, базирани на handle, като идиомата handle/body, бяха разгледани по-горе на примера на модела на ресурсите и Java модела. Също така беше отбелязано, че както моделът на ресурсите, така и Java моделът са важни основи за инструментите за разработка на Java (JDT) на Eclipse. Тъй като практически всички *DT проекти на Eclipse имат архитектура, подобна на JDT, не би било преувеличение да се каже, че моделите, базирани на handle, лежат в основата на много, ако не и на всички IDE, изградени върху платформата Eclipse. Например, в Eclipse C/C++ Development Tooling (CDT) има модел, базиран на handle, за C/C++, който играе в архитектурата на CDT същата роля, която Java моделът играе в JDT.
Преди появата на Handly, Eclipse не предлагаше специализирани библиотеки за изграждане на езикови модели, базирани на handle. Съществуващите в момента модели бяха създавани основно чрез непосредствена адаптация на кода на Java модела (известен още като copy/paste), в случаите, когато това е било позволено от Eclipse Public License (EPL). (Също така е очевидно, че, например, за проектите на самия Eclipse, това обикновено не представлява юридически проблем, каквото не може да се каже за продукти с затворен изходен код.) Освен типичната за нея безсистемност, този метод води до добре познати проблеми: дублиране на кода, грешки, внесени по време на адаптацията и т.н. Още по-лошо, резултатните модели остават 'вещ в себе си' и не използват наличния потенциал за унификация. А всъщност открояването на общи концепции и протоколи за езикови модели, базирани на handle, би могло да доведе до създаването на повторно използваеми компоненти за работа с тях, подобно на това, какво се случи с EMF.
Не може да се каже, че в Eclipse не е имало разбиране на тези проблеми. Още през 2005 година , обобщавайки опита от разработката на прототипа на CDT, необходимостта от създаване на обща инфраструктура за езикови модели, включително и модели, основаващи се на handle. Но, както обикновено, поради по-приоритетни задачи реализацията на тези идеи не беше осъществена. В същото време, факторизацията на кода *DT-проектите все още остава една от недостатъчно разработените теми в Eclipse.
В определен смисъл проектът Handly има за цел да решава приблизително същите задачи като EMF, но за модели, основаващи се на handle, и преди всичко езикови модели (т.е. представляващи елементи от структурата на определен език за програмиране). По-долу са изброени основните цели, поставени при проектирането на Handly:
- Изолиране на основните абстракции на предметната област.
- Намаляване на усилията и повишаване на качеството на реализацията на езикови модели, основаващи се на handle, чрез повторно използване на кода.
- Предоставяне на унифициран API на мета-уровен за резултиращите модели, което улеснява създаването на общи компоненти на IDE, работещи с езикови модели, основаващи се на handle.
- Гъвкавост и мащабируемост.
- Интеграция с Xtext (в отделен слой).
За изолиране на общи понятия и протоколи бяха анализирани съществуващи реализации на езикови модели, основаващи се на handle. Основните интерфейси и базови реализации, предоставяни от Handly, са показани на рис. 8.
Рис. 8. Общи интерфейси и базови реализации на елементи от Handly.
Интерфейсът IElement представлява handle на елемент и е общ за елементите на всички модели, основани на Handly. Абстрактният клас Element реализира обобщен механизъм handle/body (рис. 9).
Рис. 9. IElement и обобщената реализация handle/body.
Освен това, Handly предоставя обобщен механизъм за уведомяване за промяна на елементи в модела (рис. 10). Както може да се види, той е в общи линии аналогичен на механизмите за уведомяване, реализирани в моделите на ресурси и Java модела, и използва IElementDelta за унифицирано представяне на информацията за промяна на елемента.
Рис. 10. Общи интерфейси и базови реализации на механизма за уведомяване на Handly.
Обсъдената по-горе част на Handly (рис. 9 и 10) може да се използва за представяне на почти всякакви модели, основаващи се на handle. За създаване на езикови модели проектът предлага допълнителна функционалност - по-специално общи интерфейси и базови реализации за елементите от структурата на изходния текст, така наречените source elements (рис. 8). Интерфейс ISourceFile представлява входен файл, а ISourceConstruct – елемент вътре в входния файл. Абстрактните класове SourceFile и SourceConstruct реализират обобщени механизми за поддръжка на работа с входни файлове и техните елементи, например работа с текстови буфери, свързване с координатите на елемента в входния текст, съгласуване на модела с текущото съдържание на работния копие на буфера и т.н. Реализацията на тези механизми обикновено е достатъчно сложна задача и Handly може значително да намали усилията по разработка на езикови handle-based модели, като предоставя качествени основни реализации.
В допълнение към изброените по-горе основни механизми, Handly предлага инфраструктура за текстови буфери и 'снимки' (snapshots), поддръжка за интеграция с редактори на изходен код (включително реализирана 'из коробки' интеграция с Xtext editor), а също така и някои общи UI-компоненти, работещи с модели, основани на Handly, като outline framework. За илюстрация на своите възможности проектът предоставя няколко примера, включително и реализация на Java модел на Handly. (В сравнение с пълната реализация на Java модела в JDT, този модел е намерен за нарочно опростен за по-визуална яснота.)
Както беше споменато по-рано, сериозно внимание при началното проектиране на Handly и по-нататъшното му развитие е обърнато и продължава да бъде обърнато на мащабируемостта и гъвкавостта.
В принцип, handle-based моделите са достатъчно добре мащабируеми ‘по дизайн’. Например, идиомата handle/body позволява да се ограничи количеството памет, потребяванo от модела. Но има и нюанси. По време на тестовете на Handly за мащабируемост беше открит проблем в реализацията на механизма за известяване – при промяна на голям брой елементи, изчисляването на дельтите отнемаше твърде много време. Оказа се, че същият проблем присъства и в Java модела на JDT, от който съответният код беше адаптиран. Ние поправихме грешката в Handly и подготвихме аналогичен патч за JDT, който беше приет с благодарност. Това е само един от примерите за това как внедряването на Handly в съществуващи реализации на модели би могло да бъде потенциално полезно, тъй като в такъв случай такава грешка може да бъде коригирана само на едно място.
За да направите внедряването на Handly технически възможно в съществуващите реализации на модели, библиотеката трябва да притежава значителна гъвкавост. Основният проблем е да се запази обратната съвместимост на API на модела. Тази задача беше решена в чрез ясно отделяне на специфичния за модела API, който се определя и напълно контролира от разработчика, от унифицирания мета-уровен API, предоставен от библиотеката. Това не само прави технически възможно внедряването на Handly в съществуващите реализации, но също така дава на разработчика на новия модел значителна свобода при проектирането на API.
Гъвкавостта има и други аспекти. Например, Handly почти не налага ограничения върху структурата на модела и може да се използва както за моделиране на езици с общо предназначение, така и за предметно-ориентирани езици. При изграждането на структурата на изходния файл, Handly не предписва определена форма на представяне на AST и всъщност не изисква дори наличието на AST, осигурявайки по този начин съвместимост с практически всякакви механизми за синтактичен анализ. Накрая, Handly поддържа пълна интеграция с работната среда на Eclipse, но също така може да работи и директно с файловите системи, благодарение на интеграцията с (EFS).
Текущата версия излезе през декември 2016 година. Въпреки че в момента проектът е в стадий на инкубация и API-то все още не е окончателно фиксирано, Handly вече се използва в два големи търговски продукта, които рискуваха да бъдат "ранни последователи", и трябва да се каже, че досега не съжаляват за това.
Както беше споменато по-горе, един от тези продукти е 1C:Enterprise Development Tools, където Handly от самото начало се използва за моделиране на елементи от висшата структура на езици, като вградения език за програмиране и езика за запитвания. Другият продукт е по-малко известен на широката публика. Това е , интегрирана среда за проектиране на специфицирани проблемно-ориентирани процесори (application-specific instruction-set processor, ASIP), използвана както вътре в самата чешка компания Codasip, така и от нейните клиенти, сред които , , , . Codasip използва Handly в продукция от 2015 година, започвайки с версия Handly 0.2. Най-новото издание на Codasip Studio използва версия 0.5, пусната през юни 2016 година. Ondřej Ilčík, ръководител на разработката на IDE в Codasip, е в контакт с проекта, осигурявайки изключително важна обратна връзка от страна на „външен адаптер“. Той дори успя да намери малко свободно време, за да участва активно в разработката на проекта, реализирайки слой UI (~ 4000 реда код) за един от примерите на Handly, Java модел. По-подробна информация „от първа ръка“ за използването на Handly от адаптерите може да се получи на страницата проектa.
Надяваме се, че след пускането на версия 1.0 с гаранция за стабилност на API и излизането на проекта от инкубация, Handly ще привлече нови адаптери. Засега проектът продължава с тестови разработки и усъвършенстване на API, като издава по два „големи“ релиза годишно – през юни (на същата дата, когато е съвместният релиз на Eclipse) и декември, осигурявайки предсказуем график, на който адаптерите могат да разчитат. Може да добавим, че показателят за „броя на грешките“ остава стабилно нисък и Handly от самото си начало работи надеждно в продуктите на ранни адаптери. За допълнително запознаване с Eclipse Handly може да се използва и .
Източник: habr.com
