下载本文的 PDF 版本 PDF

Eclipse 的核心

深入了解可扩展的插件架构

DAN RUBEL，INSTANTIATIONS

ECLIPSE 既是一个开放的、可扩展的软件开发环境，也是一个开放的、可扩展的应用程序框架，软件可以基于它构建。作为最受欢迎的 Java IDE，它为工具的使用提供了一个通用的 UI 模型，并促进了基于插件组件模型（图 1）的模块化功能的快速开发。Eclipse 基金会 (http://www.eclipse.org) 设计该平台可在多种操作系统上原生运行，包括 Macintosh、Windows 和 Linux，从而提供与每个系统的强大集成，并提供支持每个人都熟悉的 GUI 交互的富客户端：拖放、剪切和粘贴（剪贴板）、导航和自定义。您可以将 Eclipse 视为一个“设计中心”，由 300 多名开发人员的开发团队支持，您可以在开发自己的软件时利用他们。

虽然 Eclipse 被设计为一个通用的工具集成平台，但它不仅仅用于创建 IDE。它同样有助于构建通用应用程序，例如工作流、帮助系统或联系人管理系统（图 2）。事实上，NASA 使用 Eclipse RCP（富客户端平台）构建了 Maestro，这是一个用于管理太空任务中远程车辆的软件程序。

Eclipse RCP 的架构概述

Eclipse 的核心是一个用于动态发现、加载和运行组件或插件的架构，插件是 Eclipse 中功能的基本单元。插件决定了平台的功能以及它是作为 IDE 还是通用应用程序运行。

Eclipse IDE 分为多个层，每一层都由更细粒度的插件组成。Java IDE 分层构建在更通用的工具平台之上，而工具平台又分层构建在 Eclipse RCP 框架之上（图 2）。Eclipse RCP 提供了构成非常基本的应用程序基础架构的插件，包括窗口系统、帮助系统、首选项页面和更新管理器等服务（见表 1）。

表 1 Eclipse 详细信息
平台运行时 动态发现插件，并在平台注册表中维护有关插件及其服务的信息。插件根据平台的用户操作在需要时加载和启动。运行时使用 OSGi 框架实现。
资源管理（工作区）
 定义了用于创建和管理工具生成并保存在文件系统中的资源（项目、文件和文件夹）的 API。
Eclipse UI 工作台 实现用于导航平台的用户驾驶舱。它定义了用于添加 UI 组件（例如视图或菜单操作）的扩展点。它提供额外的工具包（JFace 和 SWT）用于构建用户界面。UI 服务被组织成 UI 插件的子集，可用于构建独立于资源管理和工作区模型的富客户端应用程序。以 IDE 为中心的插件定义了用于导航和操作资源的其他功能。
帮助系统 定义了插件的扩展点，以提供帮助或其他文档作为可浏览的书籍。
团队支持 定义了用于管理和版本控制资源的团队编程模型。 
调试支持 定义了与语言无关的调试模型和 UI 类，用于构建调试器和启动器。
其他实用程序 其他实用程序插件提供诸如搜索和比较资源、使用 XML 配置文件执行构建以及从服务器动态更新平台等功能。

Eclipse 和 Eclipse RCP 的开发目标是

Eclipse 团队努力通过提供类似于“中式菜单”的现成模块（插件）来减少应用程序的设计工作，从而缩短开发时间和上市时间，同时仍然构建世界一流的应用程序。Eclipse 插件是松耦合的，开发人员可以自由地将它们以不同的配置组合在一起，仅使用解决特定问题所需的插件即可。

RCP 的插件可以针对 Eclipse 可移植 API 进行编程，并在任何受支持的操作系统上不变地运行。这允许开发人员专注于设计执行重要业务任务的插件，例如工作流、处理、图表绘制、报告、发布或任何其他业务需求。Eclipse 有许多通用插件可用，或者用户可以设计自己的插件。Eclipse 平台处理查找和运行正确代码的后勤工作，并且平台 UI 提供了用于导航的标准模型。（有关可用插件的列表，请访问 http://www.eclipseplugincentral.com。）

Eclipse RCP 包含五个基本部分

Eclipse UI 工作台

Eclipse UI 工作台组织用户体验，并提供应用程序与用户交互的结构。从用户的角度来看，应用程序窗口在视觉上由编辑器、视图和操作组成，用户可以重新排列它们以更好地适应任务。透视图体现在屏幕上可见的编辑器、视图和操作的选择和排列（图 3）。UI 工作台使开发人员无需为在不同操作系统上运行的每个 Java 客户端应用程序重新发明高性能用户界面。

编辑器允许用户打开、编辑和保存域对象，例如人员姓名、年龄、联系信息和社保号码的记录。编辑器遵循类似于基于文件系统的工具的打开-保存-关闭生命周期，但它们与工作台的集成更紧密。当编辑器处于活动状态时，它可以向工作台菜单和工具栏贡献操作。

视图提供有关与用户当前任务相关的对象的信息，例如可以编辑的对象列表。视图可以通过提供有关正在编辑的文档的信息来辅助编辑器。例如，如果编辑器实现了标准接口，则内容大纲视图将显示活动编辑器内容的结构化大纲。视图可以通过提供有关所选对象的信息来增强其他视图。视图的生命周期比编辑器简单。在视图中所做的修改（例如更改属性值）会立即保存，并且更改会立即反映在 UI 的其他相关部分中。

操作允许用户命令独立于它们在 UI 中的确切位置进行定义。操作表示用户可以使用按钮、菜单项或工具栏项触发的命令。每个操作都知道自己的 UI 属性（标签、图标、工具提示等），用于构造用于呈现操作的适当组件。这种分离允许在 UI 中的多个位置使用相同的操作，并且意味着可以轻松更改操作在 UI 中的呈现位置，而无需更改操作本身的代码。

透视图以适合特定用户任务的排列方式组织视图和编辑器。视图和编辑器可以平铺、堆叠或分离以在屏幕上呈现。透视图控制初始视图的可见性、布局和操作可见性，但是一旦透视图被打开，用户就拥有完全控制权，并且可以轻松地重新排列和自定义透视图以更好地适应特定任务。用户可以随时快速切换到不同的透视图以处理不同的任务。可以在单个窗口或单独的窗口中打开多个透视图，所有这些都由用户控制。

Eclipse 工作台窗口提供了一组关于如何组织 UI 的视觉设计选择。它具有菜单栏、工具栏、快捷栏和状态栏，以及某些颜色和渐变，使事物具有集成且独特的视觉外观。视图在其标题栏中具有带有操作的标题；工作台具有“文件”、“编辑”、“窗口”和“帮助”列表。每个透视图的一部分都被设置为编辑器区域。对于通用应用程序，可以根据应用程序的需要显示或隐藏这些 UI 元素中的每一个。

用户配置和自定义的能力是 UI 的重要组成部分。例如，工作台允许用户通过拖放视图和双击视图的标题栏来最大化视图来重新排列透视图中的元素。通用应用程序可能希望决定用户是否以及如何影响布局。用户可能希望重新排列人员信息在屏幕上的显示方式，例如，通过使其更小以查看更多人员的信息，甚至重新排列信息的顺序。

新功能以明确定义的方式集成到 UI 的编辑器-视图-透视图范例中。所有视图和编辑器都实现通用接口并访问通用 API，以便用户可以自定义其在应用程序窗口中的外观、内容和位置。扩展点允许插件通过添加新型编辑器、视图、操作和透视图来增强工作台。

工作台 API 使用 SWT 和 JFace 实现，以获得平台原生用户体验。未使用 AWT（抽象窗口工具包）和 Swing，因为 AWT 提供的原生 widget 集太小，而 Swing 提供的 widget 是模拟的而不是原生的；此外，当时两者都缺乏所需的一些性能。如今，客户端应用程序可以将 AWT 和 Swing 与 SWT 和 JFace 一起使用，尽管通常只使用 SWT 和 JFace。

SWT

SWT 为 widget 和图形提供了一个通用的、独立于操作系统的 API。整个 Eclipse 平台 UI 和插入其中的工具都使用 SWT 向用户呈现信息。SWT 的实现允许与底层原生窗口系统紧密集成。它为与应用程序目标平台一致的模块化原生 widget 提供了基础架构。这带来了响应迅速、高质量的用户体验。

SWT 是 Java GUI 组件的低级图形库，具有原生实现，它隐藏了平台或操作系统之间的差异，以便开发人员可以使用一组一致的高性能 widget，为所有平台使用单个 API 进行编程。这意味着开发人员可以编写一次代码，并使其看起来像 Macintosh 或 Windows 应用程序 UI。作为 UI 工作台的一部分，SWT 还有助于为用户提供响应迅速、高质量的 Java 客户端应用程序体验，该体验感觉像是平台的原生体验。对于小型、轻量级的应用程序，对于低级 API，其中微小的占用空间很重要，例如移动应用程序，开发人员可能会选择 SWT 而不是 JFace。

可移植工具包和原生窗口系统集成之间的张力始终是 widget 工具包设计中的一个问题。Java AWT 提供了低级 widget（列表、文本字段和按钮），但没有高级 widget（树或富文本）。AWT widget 直接使用所有底层窗口系统上的原生 widget 实现。仅使用 AWT 构建 UI 意味着针对所有操作系统窗口系统的最小公分母进行编程。

Java Swing 工具包通过模拟 widget（例如树、表和富文本）来解决此问题。Swing 还提供了外观模拟层，试图使应用程序看起来像底层原生窗口系统。然而，模拟的 widget 总是缺乏原生 widget 的外观和感觉。与模拟 widget 交互的用户会注意到与商业软件应用程序及其原生 widget 之间的差异足够大，以至于具有模拟 UI 的软件很难与之竞争。

为了克服这个问题，SWT 定义了一个跨多个受支持的窗口系统可用的通用 API。在可能的情况下，SWT 对每个不同的原生窗口系统使用原生 widget。当一个原生 widget 在一个平台上可用但在另一个平台上不可用时，SWT 提供合适的模拟。SWT 在任何地方都使用原生 widget 实现常见的低级 widget，例如列表、文本字段和按钮；但是，一些通用的更高级别的 widget 可能需要在某些窗口系统上进行模拟。这种方法允许 SWT 在所有环境中保持一致的编程模型，并尽可能地让底层原生窗口系统的外观和感觉显现出来。

在内部，SWT 实现为每个原生窗口系统提供了单独且不同的 Java 实现，同时保持 API 在所有平台之间相同。Java 原生库对于每个平台都完全不同，每个平台都使用最少量的代码将特定的底层窗口系统绑定到通用 API。与底层原生窗口系统的紧密集成不仅仅是外观和感觉的问题。SWT 还与原生桌面功能（例如拖放）进行交互，允许用户将内容从 SWT widget 拖放到其他非基于 SWT 的原生应用程序。

在特定底层原生窗口系统提供其他窗口系统无法模拟的独特且重要功能的情况下，SWT 会公开特定于原生窗口系统的 API。Windows ActiveX 就是一个例子。特定于窗口系统的 API 被隔离到适当命名的包中，以表明它是固有的不可移植的。由于这些特定于窗口系统的 API 是用最少量的代码实现的，因此 SWT 实现完全用 Java 代码表示，原生操作系统开发人员会感到熟悉。使用 C 语言的 Windows 程序员会发现 SWT for Windows ActiveX 的 Java 实现立即熟悉，因为它由他们已经知道的 Windows API 调用组成。

这种策略极大地简化了 SWT 的实现、调试和维护，因为它允许所有有趣的开发都在 Java 中完成。另一方面，这对于普通的 SWT 客户端来说不是问题，因为原生 widget 隐藏在独立于窗口系统的 SWT API 之后。

JFace

JFace 是一个 Java UI 工具包，其中包含用于处理更高级别上的许多常见 UI 编程任务的类。SWT 和 JFace 是分开的，因为它们解决了不同的问题：SWT 在所有平台之间提供了一个通用的 API，而 JFace 在这个通用但简单的 API 的基础上构建，以提供易于使用的 UI 抽象层。使用 JFace，程序员与其自己的域对象而不是其更原始的底层 UI 表示形式进行交互。例如，要显示记录列表，您可以实现一个接口，描述应为给定记录显示的内容，然后从那时起，您就可以操作记录列表，而不是表示这些记录的字符串列表。

JFace 在其 API 和实现中都是独立于窗口系统的，并且包括图像和字体注册表、对话框、首选项、向导框架以及长时间运行操作的进度报告等常用 UI 工具包组件。其更有趣的三个功能是查看器、内容提供器和标签提供器。

查看器围绕其关联的 SWT 组件提供面向对象的包装器。它们提供比 SWT widget 更高级别的语义。用于列表、树和表的标准查看器支持使用来自客户端域的元素填充查看器，并使 widget 与该域的更改保持同步。这些查看器配置有内容提供器和标签提供器，并且可以选择配置基于元素的过滤器和排序器。

内容提供器知道如何将查看器的输入元素映射到预期的查看器内容，以及如何将域更改转换为适当的查看器更新。

标签提供器生成显示 widget 中任何给定域元素所需的特定字符串标签和图标。

客户端根据它们提供给查看器的域元素接收选择和事件的通知。查看器实现处理域元素和 SWT widget 之间的映射，调整元素的过滤视图，并在必要时重新排序。文本的标准查看器支持常见操作，例如双击行为、撤消、着色或按字符索引或行号导航。文本查看器为客户端提供文档模型，并管理文档到 SWT 样式文本 widget 所需信息的转换。

可以通过实现适当的接口在 Eclipse UI 中显示现有域对象。可以在同一模型或文档上打开多个查看器；当模型或文档在其中任何一个中更改时，所有查看器都会自动更新。例如，如果您显示记录信息列表，并且用户在列表中选择特定元素，则会生成内部通知，通知其他用户界面元素，以便它们可以根据新的选择更新其内容。

平台运行时

平台运行时通过使用扩展和扩展点来促进松耦合的程序模块（插件）。插件声明它们如何扩展其他插件以及其他插件如何扩展它们。使用此信息，平台运行时动态确定给定任务所需的最小插件集，并且仅加载这些插件；这减少了应用程序的内存占用并提高了启动速度。

平台运行时使用 OSGi 框架来确定应用程序运行时可用的插件。此信息以及插件扩展和扩展点信息为每个插件提供了有关哪些插件扩展了它以及如何扩展的信息。由于此信息不是硬编码到每个插件中，而是在执行时动态发现的，因此程序员可以更轻松地以不同的方式重新组合插件以解决不同的问题，而无需重新发明轮子。

OSGI 框架

OSGi 框架是一个轻薄层，允许多个基于 Java 的组件在单个 JVM（Java 虚拟机）中协同工作。它专注于插件生命周期，以便可以在运行时安装、更新或删除插件，而不会中断设备的运行。其软件组件是库或应用程序，可以动态发现和使用其他组件（见图 4）。

组件在需要时延迟加载，从而减少应用程序的启动时间和整体内存占用。许多标准组件接口可用于 OSGi，包括 HTTP 服务器、配置、日志记录、安全性、用户管理和 XML 等常用功能。这些组件的插件兼容实现可以从具有不同优化的不同供应商处获得。OSGi 为 Eclipse RCP 平台添加了以下功能

插件及其操作

插件也称为捆绑包，是 Eclipse 平台的最小功能单元，可以单独开发和交付。插件用 Java 编写。非常小的应用程序可以编写为单个插件，而复杂的应用程序则将其功能混合在多个插件中。除了平台运行时之外，Eclipse 平台的所有功能都位于插件中。它们可以为编辑和操作其他类型的资源（例如 Java 文件、C 程序、Word 文档、HTML 页面和 JSP (JavaServer pages) 文件）提供支持。插件决定了平台或应用程序的最终功能。这就是 Eclipse SDK 附带其他插件以增强其功能的原因。

典型的插件包含清单文件、JAR（Java 归档）库中的 Java 代码、一些只读文件以及其他资源，例如图像、Web 模板、消息目录、本机代码库等。但是，插件可能根本不包含代码。以 HTML 页面形式贡献在线帮助的插件就是一个示例。插件代码库和只读内容位于文件系统中的目录中或服务器上的基本 URL 上。另一种机制允许从单独的片段合成插件，每个片段都在其自己的目录或 URL 中。这是用于为国际化的插件交付单独语言包的机制。

插件的清单文件定义了该插件如何与系统交互。这包括唯一标识插件和版本的信息。它还包括该插件消耗的服务以及该插件为其他插件提供的服务。这种模块化的声明性方法允许 Eclipse 平台运行时仅加载应用程序当前操作所需的插件。

使用 Eclipse RCP 构建应用程序的挑战

希望使用 Eclipse RCP 的开发人员面临几个技术问题，包括快速上手和编写松耦合的代码

快速上手。Eclipse 是一个设计良好且支持良好的面向对象框架。它代表一个非常大的 API，因此对于环境新手来说，可能具有陡峭的学习曲线。许多书籍、培训材料和在线文章可用于提供一般理解，并指导开发人员在哪里深入挖掘更多详细信息。如何使用特定功能或特性在代码中通过 Javadoc 很好地记录下来，Javadoc 解释了 API。

坚持使用 API。许多开发人员习惯于编写访问其他模块内部代码的代码。对于 Eclipse RCP 应用程序采用相同的方法意味着代码将不可维护，因为内部代码会随着 Eclipse 平台的发展而变化。

松耦合的代码。许多开发人员习惯于编写与其他模块交互的代码，而不是编写清单来声明其代码如何与其他模块交互。编写声明它们如何与其他插件交互的插件可以提高所编写代码的灵活性和可重用性，并且是基于 Eclipse 的开发的基础。开发人员需要从插件提供什么“服务”以及它如何扩展或使用其他插件的“服务”的角度来思考。

测试工具。测试工具的可用性也可能是一个问题。例如，很少有用于 Eclipse RCP 应用程序的自动化 GUI 测试工具可用；JUnit 是一个标准的 Java 测试框架，但如果没有在其之上分层的其他功能，则不容易解决 UI 测试。幸运的是，一些第三方解决方案正在涌现。

安装程序。Eclipse RCP 没有安装程序，这使得部署和应用程序更新更加困难。但是，商业第三方安装程序可以很好地处理此问题。

插件质量、成熟度和支持。对于某些人来说，Eclipse 作为一个应用程序框架已经足够丰富，不需要其他插件来添加功能。但是，许多组织需要使用符合其业务需求的功能来增强 Eclipse RCP。这意味着他们将不得不深入 Eclipse 插件生态系统，这带来了一些问题。可以在商业软件世界中找到类似的例子，其中提供了免费软件和共享软件。这些产品的质量、成熟度和支持是显而易见的考虑因素。

一些解决方案正在涌现，以解决识别、质量和支持问题。SourceLabs 验证、集成和支持开源产品。Eclipse 插件中心 (http://www.eclipseplugincentral.com) 是 Eclipse 插件的信息交换中心。Yoxos 是 Eclipse 发行版的另一个示例，其中包括在托管场景中可用并受支持的开源插件。

商业第三方工具

对于选择为其应用程序创建富客户端的开发人员，可以使用商业工具，例如 RCP Developer (http://www.instantiations.com/rcpdeveloper)。这些工具不仅可以帮助 GUI 设计和编码，还可以帮助 UI 测试、创建帮助文档以及应用程序的打包和部署。Eclipse 中的更新管理器可以使用户及时了解其应用程序的最新版本。

结论

许多组织正在将 RCP 标准化为内部 IT 应用程序的架构，从而使它们能够作为可管理的集成套件而不是不相关的功能单元运行。Eclipse RCP 将对企业组织的桌面计算策略产生重大影响，因为它结合了易于使用的应用程序开发工具，提供了开放源代码的可扩展应用程序框架，并创建了可以在各种平台上运行的应用程序。

DAN RUBEL 是 Instantiations 的 CTO。作为面向对象技术的设计和应用专家，他拥有超过 15 年的软件开发经验，包括 8 年的 Java 经验和 4 年的 Eclipse 经验。他是多个商业产品的主要架构师和产品经理。他拥有 Bucknell 大学理学学士学位，并且是《Eclipse: Building Commercial Quality Plug-ins (Addison-Wesley Eclipse series)》一书的合著者。

 

acmqueue

最初发表于 Queue vol. 4, no. 8—
在 数字图书馆 中评论本文




更多相关文章

Catherine Hayes, David Malone - 质疑评估非加密哈希函数的标准
虽然加密和非加密哈希函数无处不在，但它们的设计方式似乎存在差距。出于各种安全需求，存在许多针对加密哈希的标准，但在非加密方面，存在一定的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布非常有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。


Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 在行动
在许多软件组织中，DevEx（开发者体验）正受到越来越多的关注，因为领导者们力求在财政紧缩和人工智能等变革性技术的背景下优化软件交付。技术领导者们凭直觉普遍认为，良好的开发者体验能够提升软件交付的效率和开发者的幸福感。然而，在许多组织中，旨在改善 DevEx 的提议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。


João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和超低代码技术进行的实验室实验结果，来研究生产力差异，从而为该主题提供新的见解。低代码技术已清晰地展现出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性以及未来研究的机会。


Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，新的工具、技术和方法不断涌现以服务于商业和社会，但它也是健忘的。在追求快速前进的过程中，它容易受到时尚潮流的影响，并且可能会忘记或忽视已证实的解决方案来解决它所面临的一些永恒的问题。用例最早于 1986 年被引入，并在后来得到普及，正是这些已证实的解决方案之一。



© 保留所有权利。

© . All rights reserved.