Обзор платформы Eclipse – как её использовать | Статьи о программном обеспечении

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

Рассмотрим вначале некоторые общие аспекты архитектуры Eclipse на примере

(JDT). Выбор именно JDT в качестве примера не случаен. Это первая интегрированная среда разработки, появившаяся в Eclipse. Остальные *DT проекты Eclipse, такие как Eclipse C/C Development Tooling (CDT), были созданы позднее и заимствовали как основные архитектурные принципы, так и отдельные фрагменты исходного кода из JDT.

В первую очередь следует отметить, что для Eclipse характерно достаточно четкое архитектурное расслоение, с отделением языково-независимой функциональности от функциональности, предназначенной для поддержки конкретных языков программирования, и отделением UI-независимых «ядерных» (core) компонент от компонент, связанных с поддержкой пользовательского интерфейса.

Так, Eclipse Platform определяет общую, языково-независимую инфраструктуру, а Java development tools добавляют к Eclipse полнофункциональную Java IDE. Как Eclipse Platform, так и JDT состоят из нескольких компонент, каждая из которых относится либо к UI-независимому «ядру», либо к слою UI (рис. 1).

Рис. 1. Eclipse Platform и JDT

Перечислим основные компоненты Eclipse Platform:

Нужно сказать, что Eclipse Platform предоставляет и множество других полезных компонент для построения интегрированных средств разработки, среди которых можно отметить Debug, Compare, Search, и Team. Отдельно следует упомянуть JFace Text – основу для построения «умных редакторов» исходного кода.

К сожалению, даже беглое рассмотрение этих компонент, равно как и компонент UI-слоя не представляется возможным в рамках данной статьи, поэтому в оставшейся части этого раздела мы ограничимся обзором основных «ядерных» компонент Eclipse Platform и JDT.

EGit, интеграция Git для Eclipse

На сегодняшний день, это, пожалуй, самый необходимый плагин для Java разработчика. Он позволяет загружать код из GitHub и обеспечивает

. Этот плагин также делает поиск и выполнение запросов к истории быстрым и универсальным. Короче говоря, EGit — это must-have для разработки на Java.

Скачивание и установка Eclipse

Для работы в Eclipse нужна JDK, поэтому если у вас ее нет, нужно установить. Я использую Java SE Oracle JDK 8, вот ссылка. Работу приложения проверял до 15 версии JDK включительно. Скачиваем файл установки Eclipse версии 2021-03 отсюда. Дальше запускаем скачанный файл и выбираем пункт «Eclipse IDE for RCP and RAP Developers».

Ждем, пока Eclipse установится, и запускаем его. 

Меняем настройки окружения самого Eclipse: 

Spring Tools (AKA Spring IDE или Spring Tool Suite)

Нет никаких сомнений в том, что Spring является самым популярным Java фреймворком, а

упрощает создание проектов на Spring и Spring Boot в Eclipse. Используя STS, вы можете быстро создавать проекты на Spring Boot, используя простую интеграцию

start.spring.io

Он также поддерживает разработку приложений с использованием Spring Java-Config, расширенное автодополнение кода, content-assist, валидацию и поддержку quick-fix для приложений на Spring. Он идеально подходит для разработки микросервисов с использованием Spring, поскольку позволяет интегрировать IDE для Cloud Foundry, включая отладку в облаке.

Плагин M2E или плагин Maven Integration for Eclipse — это еще один популярный плагин Eclipse, необходимый для разработки на Java. Он обеспечивает комплексную интеграцию Maven для Eclipse.

Вы можете использовать M2E для управления как простыми, так и мульти-модульными проектами Maven, выполнять сборки Maven через интерфейс Eclipse и взаимодействовать с репозиториями Maven.

Кроме того, некоторые плагины зависят от того, какую версию Eclipse вы используете: существует отдельный плагин для Juno, Luna и так далее.

Это еще один плагин для управления версиями, который позволяет загружать код из SVN и выполнять все операции, связанные с SVN, из самого Eclipse. Он разработан и поддерживается разработчиками Subversion. Плагин постоянно апдейтится согласно последним фичам и релизам Subversion. Если вы работаете над Java-проектом в SVN, то этот плагин обязателен для вас.

У всех разработчиков разные вкусы. Некоторым разработчикам нравится старая уродливая цветовая тема Eclipse, другим нравятся темные темы, как у Vim и IntelliJ IDEA.

Eclipse Color Theme позволяет удобно переключать цветовые темы без всяких побочных эффектов. Если вы хотите иметь возможность менять цветовые темы или работать сразу на нескольких языках программирования — этот плагин может сделать вас счастливее.

JBoss Tools — это комплексный проект для набора Eclipse-плагинов, который включает поддержку JBoss, а также смежных технологий, таких как Hibernate, JBoss AS / WildFly, CDI, OpenShift, Apache Camel, Red Hat JBoss Fuse, Docker, JSF, (X) HTML, Maven, и другие.

Если вы знаете, что JUnit идет в комплекте с Eclipse, но вы используете TestNG для написания юнит-тестов для вашего Java-проекта, то этот Eclipse плагин может вам помочь. Он позволяет запускать TestNG-тесты из Eclipse. Вы можете запускать наборы, группы или отдельные методы. Репорты об ошибках находятся на отдельной вкладке, с которой можно быстро перейти к провальным тестам.

Плагин также содержит несколько шаблонов для написания тестов.

Android Development Tools (ADT) — это плагин для Eclipse IDE, разработанный, чтобы обеспечить мощную интегрированную среду для разработки Android приложений.

— это бесплатный инструмент для покрытия Java кода для Eclipse, доступный в соответствии с Eclipse Public License. Он обеспечивает анализ покрытия кода непосредственно в рабочей среде Eclipse. При правильном использовании помогает улучшить качество кода, ускорив цикл быстрой разработки/тестирования.

— это инструмент, который позволяет разработчикам “на лету” перезагружать классы и другие ресурсы, которые были изменены с момента развёртывания приложения. Он пропускает цикл повторной сборки, перезапуска и повторного развертывания, которые типичны для разработки на Java. JRebel позволяет разработчикам выполнить больше работы за то же время и не распыляться во время написания кода.

JRebel поддерживает большинство существующих корпоративных Java-стеков и легко устанавливается в существующие среды разработки.

Все перечисленные Eclipse-плагины — одни из самых важных для Java разработчиков. Большинство из них включено во все популярные списки на Eclipse MarketPlace. Эти плагины широко распространены и, возможно, вы уже используете их. Если вдруг вы еще не затестили какой-либо из них — предлагаю попробовать.

Файловая структура rcp проекта

Именно такая файловая структура должна получиться, если все сделать как я описывал. 

• Test —  созданный нами plugin. 

• JRE System Library — системная библиотека JRE, добавляется самим eclipse при создании Java приложения. В ней отображаются .jar файлы той jdk, что вы подключили к приложению в пункте Execution Environment на первой странице настроек.

• Plug-in Dependencies — папка для .jar файлов ваших зависимостей. Посмотреть список зависимостей можно в файле MANIFEST.MF на вкладке Dependencies. В папке список будет больше, чем в файле, так как включает и транзитивные зависимости.

• src — исходники. Как вы видите, структура папок (com.firstarticle.test) между src и сгенерированными классами именно такая, которую мы указали на последнем шаге создания приложения. 

• css —  папка для конкретных ресурсов (css).

• icons — папка для конкретных ресурсов (icons).

• META-INF -> MANIFEST.MF. Клик правой кнопкой мыши -> Open with -> Plug-in manifest editor. Открылся пользовательский редактор настроек плагина. Он объединяет в себе три файла из файловой структуры приложения (MANIFEST.MF, build.properties, plugin.xml).

  • Overview –  страница обзора служит двойной цели:

  • Plug-in Dependencies — показаны зависимости вашего плагина от других плагинов. На этой странице вы должны перечислить все плагины, которые вы используете в своем проекте. 

  • Runtime — показаны все пакеты, которые ваш плагин делает видимыми для других плагинов, а также библиотеки и папки, составляющие путь к классам среды выполнения подключаемого модуля.

  • Extensions — это центральный механизм, влияющий на поведение платформы. Тут есть один пункт, если его раскрыть, то мы увидим lifeCycleURI — то расширение, что создалось при генерации плагина. Оно позволяет нам следить за жизненным циклом плагина.

  • Plug-in Extensions points — определяют новые функциональные точки для платформы, к которым могут подключаться другие плагины.

  • Build — содержит всю информацию, необходимую для сборки, упаковки и экспорта плагина. Хотя он отображается как страница в редакторе манифеста, изменения, внесенные в него, записываются  в файл build.properties. Файл build.properties управляет исключительно процессом сборки.

  • MANIFEST.MF, build.properties, plugin.xml — исходники. В них отображаются все те изменения, что мы вносили в предыдущих вкладках, плюс там есть доп.настройки, не вошедшие в пользовательский редактор и на этапе ознакомления с созданием приложения не используемые нами. 

• test.product — Клик правой кнопкой мыши -> Open with -> Product Configuration editor – именно этот файл – главный в нашем приложении. Из него мы запускаем приложение, в нем указаны все зависимости на приложение, начиная от плагина, что мы создали и его зависимостей (т.е. файл MANIFEST.MF — это настройки плагина, а файл test.product – настройки приложения), и до огромного количества плагинов, которые нужны для запуска платформы RCP. 

  • Overview — содержит разделы  «General Information», «Product Definition», определяющие основные свойства продукта, и разделы «Testing», «Exporting», в которых содержатся ссылки на тестирование и экспорт.

  • Contents –  определяет все зависимости продукта.

  • Configuration — определяет информацию, которая создает файл конфигурации, необходимый для запуска продукта.

  • Launching — настраивается собственная программа запуска вашего продукта и аргументы запуска.

  • Splash –  предоставляет возможность настроить экран-заставку вашего продукта.

  • Branding — придает продукту индивидуальность, настраивая изображения окон, диалоговое окно «О программе» и приветствие.

  • Customization — можно добавить свой файл свойств запуска продукта и свой css-файл настроек для внешнего вида приложения. 

  • Licensing — на странице лицензирования вы можете добавить URL-адрес и текст лицензии для вашего продукта.

  • Updates — позволяет настроить обновление приложения из сторонних источников

  • Source —  исходный вид файла test.product.

• Application.e4xmi –  описывает структуру приложения, может содержать как визуальные элементы (part, perspective, window), так и не визуальные (handler, command, addon). В сгенерированном примере есть и то и другое, можно посмотреть.

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 ресурса. Handle выступает в роли ключа (он знает только путь к ресурсу в workspace) и полностью контролирует доступ к внутреннему объекту модели, который непосредственно хранит информацию о состоянии ресурса. Данный дизайн является вариацией паттерна Handle/Body.

Рис. 2 иллюстрирует идиому Handle/Body применительно к модели ресурсов. Интерфейс IResource представляет handle ресурса и является API, в отличие от класса Resource, реализующего этот интерфейс, а также класса ResourceInfo, представляющего body, которые API не являются.

Подчеркнем, что handle знает только путь к ресурсу относительно корня workspace и не содержит в себе ссылку на resource info. Объекты resource info образуют так называемое «дерево элементов» (element tree). Эта структура данных полностью материализована в памяти.

Рис. 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-based моделей.

Jdt core

Модель ресурсов 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:

Рис. 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.

Bindings являются объектами, представляющими именованные сущности, такие как типы, методы, и переменные, известные компилятору. В отличие от узлов AST, образующих дерево, bindings поддерживают перекрестные ссылки и в общем случае образуют граф. Абстрактный класс ASTNode является общим базовым классом для всех узлов AST. Подклассы ASTNode соответствуют определенным синтаксическим конструкциям языка Java.

Поскольку синтаксические деревья могут потреблять значительное количество памяти, JDT кэширует только одно AST, для активного редактора. В отличие от модели Java, AST обычно рассматривается как «промежуточная», «временная» модель, на элементы которой клиентам не следует удерживать ссылки вне контекста операции, приведшей к созданию AST.

Перечисленные три модели (Java model, AST, bindings) совместно являются основой для построения «интеллектуальных средств разработки» в JDT, среди которых мощный редактор Java с разнообразными «помощниками», различные действия по обработке исходного кода (среди которых организация списка импорта имен и форматирование в соответствии с настроенным стилем), инструменты поиска и рефакторинга.

Архитектура платформы eclipse

• Основным элементом является исполняющая среда – Eclipse Runtime, в которой выполняются коды расширений и модулей. Она обеспечивает всю базовую функциональность платформы – управление расширениями и обновлениями, взаимодействие с операционной системой, обеспечение работы системы помощи.
• Следующим элементом является собственно IDE – она отвечает за управление основными элементами программы, их расположением и настройками, управление проектами, отладку и сборку проектов, поиск по файлам и командную разработку.

В стандартную поставку Eclipse SDK включены два плагина – Java Development Tools или JDT, и Plug-in Developer Environment или PDE, таким образом мы получаем полностью готовую IDE для Java программирования и для разработки расширений для Eclipse.

Компоненты eclipse, используемые в 1с:enterprise developments tools

На рис. 7 показаны компоненты Eclipse, образующие фундамент технологической платформы для 1C:Enterprise Development Tools.

Рис. 7. Eclipse как платформа для 1С:Enterprise Development Tools

Eclipse Platform предоставляет базовую инфраструктуру. Мы рассмотрели некоторые аспекты этой инфраструктуры в предыдущем разделе.

Eclipse Modeling Framework (EMF) предоставляет общие средства моделирования структурированных данных. EMF интегрирован с Eclipse Platform, но может использоваться и отдельно, в обычных приложениях Java. Довольно часто, начинающие Eclipse-разработчики уже хорошо знакомы с EMF, хотя еще не совсем разбираются в тонкостях Eclipse Platform.

Одной из причин такой заслуженной популярности является универсальный дизайн, включающий, в том числе, и унифицированный API мета-уровня, который позволяет обобщенно работать с любой EMF моделью. Предоставляемые EMF базовые реализации для объектов модели и подсистема генерации кода модели по мета-модели существенно увеличивают скорость разработки и снижают количество ошибок. Также EMF содержит механизмы сериализации моделей, отслеживания изменений в модели, и многое другое.

Как любой по-настоящему универсальный инструмент, EMF подходит для решения широкого спектра задач, связанных с моделированием, но некоторые классы моделей (например, рассмотренные выше handle-based модели) могут нуждаться в более специализированных средствах моделирования.

Рассказывать об EMF – занятие неблагодарное, особенно в ограниченных рамках одной статьи, поскольку это предмет отдельной книги, и довольно толстой. Отметим только, что качественная система обобщений, положенная в основу EMF, позволила появиться на свет целому спектру проектов, посвященных моделированию, которые входят в проект верхнего уровня Eclipse Modeling наряду с самим EMF. Одним из таких проектов является Eclipse Xtext.

Eclipse Xtext предоставляет инфраструктуру «текстового моделирования». Xtext использует ANTLR для синтаксического анализа исходного текста и 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 модели.

1С:Enterprise Development Tools активно используют как EMF сам по себе, так и ряд других проектов Eclipse Modeling. В частности, Xtext является одной из основ средств разработки для таких языков 1С:Предприятие, как встроенный язык программирования и язык запросов.

Eclipse Handly, подпроект проекта верхнего уровня Eclipse Technology, появился в результате начальной контрибуции кода в Eclipse Foundation, осуществленной фирмой 1C в 2021 году. С тех пор фирма 1С продолжает поддерживать разработку проекта:

Основные архитектурные принципы 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-модели (a.k.a. copy/paste), в тех случаях, когда это позволяет Eclipse Public License (EPL).

(Понятно, что, скажем, для проектов самого Eclipse это обычно не является проблемой с юридической точки зрения, чего не скажешь о продуктах с закрытым исходным кодом.) Помимо характерной для нее бессистемности, такая методика приводит к хорошо известным проблемам: дублированию кода, привнесенным при адаптации ошибкам, и т.п.

Что еще хуже, результирующие модели остаются «вещью в себе» и не используют имеющийся потенциал для унификации. А ведь выделение общих понятий и протоколов для языковых handle-based моделей могло бы привести к созданию повторно используемых компонент для работы с ними, аналогично тому, как это произошло в случае с EMF.

Нельзя сказать, что в Eclipse не было понимания этих проблем. Еще в 2005 году Martin Aeschlimann, обобщая опыт разработки прототипа CDT, аргументировал необходимость создания общей инфраструктуры для языковых моделей, включая и handle-based модели.

В определенном смысле, проект Handly призван решать примерно те же задачи, что и EMF, но для handle-based моделей, и в первую очередь языковых (т.е. представляющих элементы структуры некоторого языка программирования). Ниже перечислены основные цели, ставившиеся при проектировании Handly:

Для выделения общих понятий и протоколов были проанализированы существующие реализации языковых 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 предоставляет инфраструктуру текстовых буферов и «снимков» (snapshots), поддержку интеграции с редакторами исходного кода (включая реализованную «из коробки» интеграцию с Xtext editor), а также некоторые общие UI-компоненты, работающие с основанными на Handly моделями, такие как outline framework.

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

В принципе, handle-based модели достаточно хорошо масштабируются “by design”. Например, идиома handle/body позволяет ограничить количество потребляемой моделью памяти. Но есть и нюансы. Так, при испытаниях Handly на масштабируемость была обнаружена проблема в реализации механизма нотификации – при изменении большого числа элементов построение дельт занимало слишком много времени.

Оказалось, что та же самая проблема присутствует и в Java-модели JDT, из которой был в свое время адаптирован соответствующий код. Мы исправили ошибку в Handly и подготовили аналогичный патч для JDT, который был с благодарностью принят. Это всего лишь один из примеров, когда внедрение Handly в существующие реализации моделей могло бы быть потенциально полезным, ведь в этом случае такую ошибку можно было бы исправить всего в одном месте.

Чтобы сделать внедрение Handly в существующие реализации моделей технически возможным, библиотека должна обладать значительной гибкостью. Основная проблема состоит в том, чтобы сохранить обратную совместимость по API модели. Эта задача была решена в Handly 0.

5 посредством четкого отделения специфичного для модели API, определяемого и полностью контролируемого разработчиком, от унифицированного API мета-уровня, предоставляемого библиотекой. Это не только делает технически возможным внедрение Handly в существующие реализации, но также дает разработчику новой модели значительную свободу при проектировании API.

Гибкость имеет и другие аспекты. Например, Handly почти не накладывает ограничений на структуру модели и может использоваться как для моделирования языков общего назначения, так и предметно-ориентированных языков. При построении структуры исходного файла, Handly не предписывает какую-то определенную форму представления AST и в принципе не требует даже самого наличия AST, обеспечивая, таким образом, совместимость с практически любыми механизмами синтаксического анализа.

Текущая версия Handly 0.6 вышла в декабре 2021 года. Несмотря на то, что в настоящее время проект находится в состоянии инкубации и API окончательно еще не зафиксирован, Handly уже используется в двух крупных коммерческих продуктах, которые рискнули выступить в роли «ранних адоптеров», и, надо сказать, пока не жалеют об этом.

Как отмечалось выше, один из этих продуктов – 1C:Enterprise Development Tools, где Handly с самого начала используется для моделирования элементов высокоуровневой структуры таких языков 1С:Предприятие, как встроенный язык программирования и язык запросов.

Другой продукт менее известен широкой публике. Это Codasip Studio, интегрированная среда проектирования проблемно-ориентированных процессоров (application-specific instruction-set processor, ASIP), используемая как внутри самой чешской компании Codasip, так и ее клиентами, среди которых AMD, AVG, Mobileye, Sigma Designs.

Codasip использует Handly в production c 2021 года, начиная с версии Handly 0.2. Последний на данный момент релиз Codasip Studio использует версию 0.5, выпущенную в июне 2021 года. Ondřej Ilčík, возглавляющий разработку IDE в Codasip, находится в контакте с проектом, обеспечивая крайне важную обратную связь от лица «стороннего адоптера».

Он даже смог найти немного свободного времени, чтобы непосредственно поучаствовать в разработке проекта, реализовав слой UI (~ 4000 строк кода) для одного из примеров Handly, модели Java. Более подробную информацию «из первых уст» об использовании Handly адоптерами можно получить на странице Success Stories проекта.

Надеемся, что после выпуска версии 1.0 с гарантией стабильности API и выходом проекта из состояния инкубации, у Handly появятся и новые адоптеры. Пока же проект продолжает обкатку и дальнейшее совершенствование API, выпуская по два «больших» релиза в год – в июне (в ту же дату, что и одновременный релиз Eclipse) и декабре, обеспечивая предсказуемый график, на который могут полагаться адоптеры.

Можно еще добавить, что показатель “bug rate” проекта остается на стабильно низком уровне и Handly с самых первых версий надежно работает в продуктах ранних адоптеров. Для дальнейшего знакомства с Eclipse Handly можно использовать Getting Started Tutorial и Architectural Overview.

Особенности платформы eclipse

• Кроссплатформенность – работает под операционными системами Windows, Linux, Solaris и Mac OS X.
• Используя Eclipse можно программировать на множестве языков, таких как Java, C и C , PHP, Perl, Python, Cobol и других.
• Является фреймворком для разработки других инструментов и предлагает обширный набор API для создания модулей.
• Используя подход RCP (Rich Client Platform) Eclipse является инструментом для создания практически любого клиентского программного обеспечения.

Работа над проектом Eclipse ведётся в нескольких направлениях, основные три – работа над платформой Eclipse, разработка Java IDE, разработка плагинов для расширения функциональности Eclipse.

Гибкость и расширяемость достигается благодаря модульности платформы.

Примеры других специализированных сборок eclipse

• Eclipse IDE for Java Developers – среда разработки на языке Java.
• Eclipse IDE for Java EE Developers – среда разработки веб приложений и корпоративных приложений с использованием технологии Java EE.
• Eclipse IDE for C/C Developers – функциональная IDE для программирования на C и C .
• Eclipse IDE for JavaScript Web Developers – IDE для разработки веб приложений с использованием HTML, XML, JavaScript и CSS.

Заключение

При изучении технологии и дальнейшем ее использовании, я столкнулся с проблемой малого количества информации, ее фрагментарности и конечно же она была крайне устаревшей. И сформировать какое-то общее понимание того как это все работает, а не тупое использование заученных действий, оказалось крайне сложно.