Мабуть, давно вже не потребує особливого уявлення. Багато хто знайомий з Eclipse завдяки Eclipse Java development tools (). Саме ця популярна open-source Java IDE асоціюється у більшості розробників зі словом "Eclipse". Однак Eclipse – це платформа, що розширюється, для інтеграції засобів розробки (Eclipse Platform), і цілий ряд IDE, побудованих на її основі, в тому числі JDT. Eclipse - це і Eclipse Project, проект верхнього рівня, що координує розробку Eclipse Platform і 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 Platform, у тому числі і для 1C:Enterprise Development Tools.
Насамперед слід зазначити, що для Eclipse характерно досить чітке архітектурне розшарування, з відділенням мовно-незалежної функціональності від функціональності, призначеної для підтримки конкретних мов програмування, та відділенням UI-незалежних «ядерних» (core) компонент від компонентів, пов'язаних з підтримкою користувача інтерфейсу.
Так, Eclipse Platform визначає загальну, мовно-незалежну інфраструктуру, а Java development tools додають до Eclipse повнофункціональну Java IDE. Як Eclipse Platform, так і JDT складаються з декількох компонентів, кожна з яких відноситься або до UI-незалежного "ядра", або до шару UI (рис. 1).
Мал. 1. Eclipse Platform та JDT
Перерахуємо основні компоненти Eclipse Platform:
- Час виконання - Визначає інфраструктуру плагінів. Для Eclipse характерна модульна архітектура. По суті, Eclipse є колекцією "точок розширення" та "розширень".
- Робоча область — Керує одним чи кількома проектами. Проект складається з папок та файлів, які відображаються безпосередньо на файлову систему.
- 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).
Core Workspace
Практично будь-яке інтегроване середовище розробки, побудоване на основі Eclipse Platform працює з Eclipse workspace. Саме workspace зазвичай містить вихідний код програми, що розробляється в IDE. Workspace безпосередньо відображається на файлову систему і складається з проектів, які містять папки та файли. Ці проекти, папки та файли називаються ресурсами workspace. Реалізація workspace в Eclipse служить кешем по відношенню до файлової системи, що дозволяє помітно прискорити обхід дерева ресурсів. Крім того, workspace надає низку додаткових сервісів, включаючи и .
За підтримку workspace та його ресурсів відповідає компонент Core Resources (плагін org.eclipse.core.resources). Зокрема, ця компонента надає програмний доступ до workspace у вигляді моделі ресурсів. Для ефективної роботи з цією моделлю клієнтам потрібен простий спосіб подання посилання ресурс. При цьому об'єкт, що безпосередньо зберігає стан ресурсу в моделі, бажано було б сховати від клієнтського доступу. Інакше, у разі, наприклад, видалення файлу, клієнт міг би продовжувати утримувати об'єкт, якого вже немає в моделі, з проблемами, що випливають звідси. Eclipse вирішує це завдання, використовуючи так званий обробляти ресурсу. Handle виступає в ролі ключа (він знає лише шлях до ресурсу у workspace) і повністю контролює доступ до внутрішнього об'єкта моделі, що безпосередньо зберігає інформацію про стан ресурсу. Даний дизайн є варіацією патерну. .
Мал. 2 ілюструє ідіому Handle/Body стосовно моделі ресурсів. Інтерфейс IResource являє собою handle ресурсу і є API, на відміну від класу Resource, що реалізує цей інтерфейс, а також класу ResourceInfo, що представляє body, які API не є. Підкреслимо, що handle знає лише шлях до ресурсу щодо кореня workspace і не містить посилання на 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 надає ефективний механізм нотифікації про зміни ресурсів workspace (рис. 3). Ресурси можуть змінюватися як в результаті дій, що виконуються в Eclipse IDE, так і в результаті синхронізації з файловою системою. В обох випадках клієнтам, що підписалися на нотифікації, надається детальна інформація про зміни у вигляді «ресурсних дельт» (resource delta). Дельта описує зміни між двома станами (під-)дерева ресурсів workspace і сама є деревом, кожен вузол якого описує зміну деякого ресурсу та містить список дельт наступного рівня, що описують зміни дочірніх ресурсів.
Мал. 3. IResourceChangeEvent та IResourceDelta
Заснований на ресурсних дельтах механізм нотифікації має такі характеристики:
- Єдина зміна та безліч змін описуються за допомогою однієї і тієї ж структури, оскільки дельта будується за принципом рекурсивної композиції. Клієнти-передплатники можуть опрацьовувати нотифікації про зміну ресурсів за допомогою рекурсивного спуску по дереву дельт.
- Дельта містить повну інформацію про зміну ресурсу, включаючи його переміщення та/або зміну асоційованих з ним «маркерів» (у вигляді маркерів надаються, наприклад, помилки компіляції).
- Оскільки посилання на ресурс робляться через handle, дельта може природно посилатися на віддалений ресурс.
Як ми незабаром побачимо, основні складові дизайну механізму нотифікації про зміну моделі ресурсів є актуальними і для інших handle-based моделей.
Ядро JDT
Модель ресурсів Eclipse workspace є основною мовно-незалежною моделлю. Компонент JDT Core (плагін org.eclipse.jdt.core) надає API для навігації та аналізу структури workspace з точки зору Java, так звану «модель Java» (Java model). Цей API визначений у термінах елементів Java, на відміну від нижченаведеного API моделі ресурсів, який визначений у термінах папок та файлів. Основні інтерфейси дерева елементів Java зображені на рис. 4.
Мал. 4. Елементи моделі Java
Модель Java використовує ту ж ідіому handle/body, що і модель ресурсів (рис. 5). IJavaElement – це handle, а JavaElementInfo грає роль body. Інтерфейс IJavaElement визначає протокол, загальний всім елементів Java. Деякі з його методів є handle-only: getElementName(), getParent() і т.п. Об'єкт JavaElementInfo зберігає стан відповідного елемента: його структуру та атрибути.
Мал. 5. IJavaElement та JavaElementInfo
Модель Java має деякі відмінності у реалізації базового дизайну handle/body у порівнянні з моделлю ресурсів. Як зазначалося вище, моделі ресурсів element tree, вузлами якого є об'єкти resource info, повністю міститься в пам'яті. Але в моделі Java може бути значно більше елементів, ніж у дереві ресурсів, адже в ній представлена, в тому числі, і внутрішня структура .java і .class файлів: типи, поля та методи.
Щоб уникнути повної матеріалізації всього дерева елементів у пам'яті, реалізація моделі Java використовує обмежений LRU-кеш element info, де ключом є handle IJavaElement. Об'єкти element info створюються за запитом у міру того, як відбувається навігація дерева елементів. При цьому найменш часто використовувані елементи витісняються з кешу і споживання пам'яті моделлю залишається обмеженим заданим розміром кеша. Це ще одна перевага handle-based дизайну, який повністю приховує такі подробиці реалізації клієнтського коду.
Механізм нотифікації про зміну елементів Java загалом аналогічний розглянутому вище механізму відстеження змін ресурсів workspace. Клієнт, який бажає відстежувати зміни в моделі Java, підписується на нотифікації, які подаються у вигляді об'єкта ElementChangedEvent, який містить IJavaElementDelta (рис. 6).
Мал. 6. ElementChangedEvent і IJavaElementDelta
Модель Java не містить інформацію про тіло методів або роздільну здатність імен, тому для детального аналізу коду, написаного на Java, JDT Core надає додаткову (не handle-based) модель: (abstract syntax tree, AST). AST є результатом синтаксичного аналізу вихідного тексту. Вузли AST відповідають елементам структури вихідного модуля (оголошенням, операторам, виразам, тощо) і містять інформацію про координати відповідного елемента у вихідному тексті, а також (як опцію) інформацію про дозвіл імен у вигляді посилань на так звані прив'язки. Bindings є об'єктами, що представляють іменовані сутності, такі як типи, методи та змінні, відомі компілятору. На відміну від вузлів AST, що утворюють дерево, bindings підтримують перехресні посилання та у загальному випадку утворюють граф. Анотація класу ASTNode є загальним базовим класом для всіх вузлів AST. Підкласи ASTNode відповідають певним синтаксичним конструкціям мови Java.
Оскільки синтаксичні дерева можуть споживати значну кількість пам'яті, JDT кешує лише одне AST для активного редактора. На відміну від моделі Java, AST зазвичай розглядається як «проміжна», «тимчасова» модель, елементи якої клієнтам не слід утримувати посилання поза контекстом операції, що призвела до створення AST.
Перелічені три моделі (Java model, 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 надає базову інфраструктуру. Ми розглянули деякі аспекти цієї інфраструктури у попередньому розділі.
(EMF) надає загальні засоби моделювання структурованих даних. EMF інтегрований з Eclipse Platform, але може використовуватися і окремо у звичайних програмах Java. Досить часто, Eclipse-розробники-початківці вже добре знайомі з EMF, хоча ще не зовсім розуміються на тонкощах Eclipse Platform. Однією з причин такої заслуженої популярності є універсальний дизайн, що включає, у тому числі, і уніфікований API мета-рівня, що дозволяє узагальнено працювати з будь-якою моделлю EMF. Надані EMF базові реалізації для об'єктів моделі та підсистема генерації коду моделі по мета-моделі суттєво збільшують швидкість розробки та знижують кількість помилок. Також EMF містить механізми серіалізації моделей, відстеження змін у моделі та багато іншого.
Як будь-який по-справжньому універсальний інструмент, EMF підходить для вирішення широкого спектру завдань, пов'язаних з моделюванням, але деякі класи моделей (наприклад, розглянуті вище handle-based моделі) можуть потребувати більш спеціалізованих засобів моделювання. Розповідати про EMF – заняття невдячне, особливо в обмежених рамках однієї статті, оскільки це є предметом окремої книги, і досить товстою. Зазначимо тільки, що якісна система узагальнень, покладена в основу EMF, дозволила з'явитися світ цілому спектру проектів, присвячених моделюванню, які входять до проекту верхнього рівня. поряд із самим EMF. Одним із таких проектів є Eclipse Xtext.
надає інфраструктуру "текстового моделювання". Xtext використовує для синтаксичного аналізу вихідного тексту та EMF для представлення результуючого ASG (abstract semantic graph, який є комбінацією AST і bindings), званого також «семантичною моделлю». Граматика моделі, що моделюється за допомогою Xtext, описується власною мовою Xtext. Це дозволяє не тільки генерувати опис граматики для ANTLR, але й отримувати механізм серіалізації AST (тобто Xtext надає і parser, і unparser), контекстну підказку та ряд інших мовних компонентів. З іншого боку, мова опису граматики, що використовується в Xtext, менш гнучка порівняно, скажімо, з мовою опису граматики в ANTLR. Тому іноді доводиться «підгинати» під Xtext мову, що реалізується, що зазвичай не є проблемою, якщо йдеться про мову, що розробляється з нуля, але може бути неприйнятною для мов з уже сформованим синтаксисом. Незважаючи на це, Xtext є в даний час найбільш зрілим, функціонально повним і універсальним інструментом в Eclipse для побудови мов програмування та засобів розробки для них. Зокрема, він є ідеальним інструментом для швидкого прототипування (Domain-specific language, DSL). Крім згаданого вище «мовного ядра» на основі ANTLR та EMF, Xtext надає безліч корисних компонентів вищого рівня, включаючи механізми індексації, інкрементальної побудови, «розумний редактор», та багато, багато іншого, але залишає за дужками мовні handle-based моделі. Як і EMF, Xtext є предметом гідним окремої книги, і ми навряд чи зможемо навіть швидко розповісти зараз про всі його можливості.
1С:Enterprise Development Tools активно використовують як EMF сам по собі, так і низку інших проектів Eclipse Modeling. Зокрема, Xtext є однією з основ засобів розробки для таких мов 1С:Підприємство, як вбудована мова програмування та мова запитів. Іншою основою цих засобів розробки є проект Eclipse Handly, на якому ми зупинимося докладніше (з перерахованих компонентів Eclipse він поки що найменш відомий).
, підпроект проекту верхнього рівня Eclipse Technology, з'явився в результаті початкової контрибуції коду Eclipse Foundation, здійсненої фірмою 1C в 2014 році. З того часу фірма 1С продовжує підтримувати розробку проекту: committer'и Handly є співробітниками фірми. Проект невеликий, але займає досить унікальну нішу в Eclipse: його головною метою є підтримка розробки handle-based моделей.
Основні архітектурні принципи handle-based моделей, такі як ідіома handle/body, розглядалися вище на прикладі моделі ресурсів та Java-моделі. Також відзначалося, що і модель ресурсів, і модель Java є важливими основами для Eclipse Java development tools (JDT). А оскільки практично всі *DT проекти Eclipse мають аналогічну архітектуру JDT, то не буде великим перебільшенням сказати, що handle-based моделі лежать в основі багатьох, якщо не всіх IDE, побудованих поверх Eclipse Platform. Наприклад, в Eclipse C/C++ Development Tooling (CDT) є handle-based модель C/C++, що грає в архітектурі CDT ту саму роль, що і Java-модель в JDT.
До появи Handly, Eclipse не пропонував спеціалізованих бібліотек для побудови мовних handle-based моделей. Існуючі зараз моделі створювалися переважно за допомогою безпосередньої адаптації коду Java-моделі (aka copy/paste), у тих випадках, коли це дозволяє Eclipse Public License (EPL). (Зрозуміло, що, скажімо, для проектів самого Eclipse це зазвичай не є проблемою з юридичної точки зору, чого не скажеш про продукти із закритим вихідним кодом.) Крім характерної для неї безсистемності, така методика призводить до добре відомих проблем: дублювання коду, привнесеного при адаптації помилок і т.п. Що ще гірше, результуючі моделі залишаються «річчю в собі» і не використовують наявний потенціал для уніфікації. Адже виділення загальних понять та протоколів для мовних handle-based моделей могло б призвести до створення повторно використовуваних компонентів для роботи з ними, аналогічно тому, як це сталося у випадку з EMF.
Не можна сказати, що у Eclipse не було розуміння цих проблем. Ще 2005 року , узагальнюючи досвід розробки прототипу CDT, необхідність створення загальної інфраструктури для мовних моделей, включаючи і handle-based моделі. Але, як це часто буває, через пріоритетніші завдання до реалізації цих ідей тоді так і не дійшли руки. Тим часом, факторизація коду *DT-проектів, як і раніше, залишається однією з недостатньо опрацьованих тем в Eclipse.
У певному сенсі, проект Handly покликаний вирішувати приблизно ті ж завдання, що і EMF, але для handle-based моделей, і в першу чергу мовних (тобто елементів структури деякої мови програмування). Нижче наведено основні цілі, що ставилися при проектуванні Handly:
- Виділення основних абстракцій предметної галузі.
- Скорочення зусиль та підвищення якості реалізації мовних handle-based моделей за рахунок повторного використання коду.
- Надання уніфікованого API мета-рівня до результуючих моделей, що уможливлює створення спільних компонентів IDE, що працюють з мовними handle-based моделями.
- Гнучкість та масштабованість.
- Інтеграція з Xtext (в окремому шарі).
Для виділення загальних понять та протоколів було проаналізовано існуючі реалізації мовних handle-based моделей. Основні інтерфейси та базові реалізації, що надаються 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-based моделей. Для створення мовних моделей проект пропонує додаткову функціональність – зокрема, загальні інтерфейси та базові реалізації для елементів структури вихідного тексту, так званих source elements (Рис. 8). Інтерфейс ISourceFile представляє вихідний файл, а ISourceConstruct – елемент усередині вихідного файла. Абстрактні класи SourceFile та SourceConstruct реалізують узагальнені механізми для підтримки роботи з вихідними файлами та їх елементами, наприклад, роботу з текстовими буферами, прив'язку до координат елемента у вихідному тексті, reconciling моделі з поточним вмістом буфера working copy тощо. Реалізація цих механізмів зазвичай є досить непростим завданням, і Handly може суттєво скоротити зусилля розробки мовних handle-based моделей за рахунок надання якісних базових реалізацій.
Крім перелічених вище основних механізмів, Handly надає інфраструктуру текстових буферів та «знімків» (snapshots), підтримку інтеграції з редакторами вихідного коду (включаючи реалізовану «з коробки» інтеграцію з Xtext editor), а також деякі спільні UI-компоненти, що працюють із заснованими на Handly моделями, такі як outline framework. Для ілюстрації своїх можливостей проект надає кілька прикладів, зокрема й реалізацію моделі Java на Handly. (У порівнянні з повною реалізацією Java-моделі в JDT, ця модель навмисно спрощена для більшої наочності.)
Як було зазначено раніше, серйозна увага при початковому проектуванні Handly та подальшому розвитку приділялася і продовжує приділятися масштабованості та гнучкості.
Загалом, handle-based моделі досить добре масштабуються “by design”. Наприклад, ідіома handle/body дозволяє обмежити кількість споживаної моделі пам'яті. Але є й нюанси. Так, при випробуваннях Handly на масштабованість була виявлена проблема реалізації механізму нотифікації – при зміні великої кількості елементів побудова дельт займала занадто багато часу. Виявилося, що та сама проблема присутня і в Java-моделі JDT, з якої був свого часу адаптований відповідний код. Ми виправили помилку у Handly та підготували аналогічний патч для JDT, який був з вдячністю прийнятий. Це лише один із прикладів, коли впровадження Handly в існуючі реалізації моделей могло б бути потенційно корисним, адже в цьому випадку таку помилку можна було б виправити лише в одному місці.
Щоб зробити впровадження Handly в існуючі реалізації моделей технічно можливим, бібліотека повинна мати значну гнучкість. Основна проблема полягає в тому, щоб зберегти зворотну сумісність API моделі. Це завдання було вирішено у за допомогою чіткого відділення специфічного для моделі API, що визначається та повністю контролюється розробником, від уніфікованого API мета-рівня, що надається бібліотекою. Це не тільки робить технічно можливим впровадження Handly у існуючі реалізації, але й дає розробнику нової моделі значну свободу при проектуванні API.
Гнучкість має інші аспекти. Наприклад, Handly майже не накладає обмежень на структуру моделі та може використовуватися як для моделювання мов загального призначення, так і для предметно-орієнтованих мов. При побудові структури вихідного файлу, Handly не наказує якусь певну форму подання AST і в принципі не вимагає навіть наявності AST, забезпечуючи, таким чином, сумісність з практично будь-якими механізмами синтаксичного аналізу. Нарешті, Handly підтримує повноцінну інтеграцію з Eclipse workspace, але також може працювати і безпосередньо з файловими системами завдяки інтеграції з (EFS).
Поточна версія вийшла у грудні 2016 року. Незважаючи на те, що в даний час проект перебуває в стані інкубації і API остаточно ще не зафіксовано, Handly вже використовується у двох великих комерційних продуктах, які ризикнули виступити в ролі «ранніх адоптерів», і треба сказати, поки не шкодують про це.
Як зазначалося вище, один із цих продуктів – 1C:Enterprise Development Tools, де Handly із самого початку використовується для моделювання елементів високорівневої структури таких мов 1С:Підприємство, як вбудована мова програмування та мова запитів. Інший продукт менш відомий широкому загалу. Це , інтегроване середовище проектування проблемно-орієнтованих процесорів (application-specific instruction-set processor, ASIP), що використовується як усередині самої чеської компанії Codasip, так і її клієнтами, серед яких , , , . Codasip використовує Handly у production c 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) та грудні, забезпечуючи передбачуваний графік, на який можуть покладатися адоптери. Можна ще додати, що показник "bug rate" проекту залишається на стабільно низькому рівні і Handly з перших версій надійно працює у продуктах ранніх адоптерів. Для подальшого знайомства з Eclipse Handly можна використовувати и .
Джерело: habr.com