Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ЛР1.doc
Скачиваний:
13
Добавлен:
11.11.2019
Размер:
238.08 Кб
Скачать

Графический интерфейс

Фундаментом, на котором построены все графические средства Eclipse, является входящий в Workbench компонент SWT (Standard widget toolkit). SWT является основным средством создания пользовательского интерфейса для приложений на основе Eclipse. Поскольку для прорисовки элементов интерфейса SWT максимально использует средства оконного менеджера операционной системы (Win32, GTK, Motif), приложения, построенные на базе SWT, визуально не отличаются от “родных” приложений, разработанных специально для конкретной операционной системы. При этом они сохраняют совместимость со всеми платформами, поддерживаемыми Eclipse.

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

SWT (в виде набора библиотек) может быть использован в качестве замены Swing и AWT, отдельно от Eclipse и компонента Workbench.

До последнего времени основным недостатком SWT было отсутствие визуального редактора для создания графических интерфейсов на его основе. Безусловно, разработку кода графического приложения с нуля трудно назвать увлекательной или интеллектуальной задачей. Заполнить этот пробел призван недавно стартовавший проект Eclipse Visual Editor.

На основе SWT построен компонент JFace, который решает более высокоуровневые задачи построения пользовательского интерфейса. JFace содержит классы для создания диалогов, страниц свойств, управления шрифтами, поддержки архитектуры модель/вид и т.п. Сам Eclipse создан исключительно с использованием SWT и JFace.

JDT

JDT – второй из основных подпроектов, составляющих Eclipse SDK. Это и есть “IDE для Java”, содержащая инкрементальный компилятор Java, редакторы, средства для отладки, тестирования, навигации и рефакторинга исходного кода.

Важно понимать, что JDT построен исключительно на основе подпроекта Platform и не использует каких-либо закрытых или недокументированных интерфейсов. Это значит, что при наличии желания и ресурсов можно разработать компонент, функционально аналогичный JDT, для любого другого языка – от С++ до Python, и тем самым превратить Eclipse в, например, “IDE для Python”.

Вы можете полностью исключить JDT из конфигурации Eclipse и установить только свои компоненты, так что пользователям вашего продукта ничто не будет напоминать о Java. Единственный компонент из стандартной конфигурации, который является обязательным для функционирования приложений – это Platform.

Инкрементальная компиляция

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

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

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

Что можно сказать о применимости автоматической компиляции для больших проектов – не окажется ли время, затрачиваемое на нее, неприемлемо большим? Как показывает практика, Eclipse позволяет комфортно работать с исходным кодом объемом порядка одного миллиона строк при условии, что он структурирован – разделен на проекты относительно небольшого размера. В случае, когда весь исходный код находится в одном проекте (рекомендуется избегать подобных ситуаций), может оказаться целесообразным отключить автоматическую компиляцию.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]