## 6.4 Eclipse 4.0 架构必须持续地进行检查以评估其是否依然合适。它是否能引入新的技术？它是否能带动社区的成长？它是否便于吸收新的提交者？在2007年底，Eclipse项目确定这些问题的答案是否定的所以他们着手设计新版本的Eclipse。同时，他们意识到有成千上万个Eclipse项目依赖于已有的API。在2008年的时候，他们创建了一个新的孵化项目，这个项目有三个明确的目标：通过开放式的架构来简化Eclipse开发模型、吸引新的开发者以及利用基于web技术的优势。  图 6.9 Eclipse 4.0 SDK的早期试用者版本 Eclipse 4.0首次发布于2010年7月，它针对于早期试用者以获取反馈信息。它的SDK包含两部分的bundle，一部分来源于3.6释放版，还有一部分新的bundle来源于技术项目。像3.0一样，有一个兼容层以保证现存的bundle在新版本中依然可用。一如既往的是，要警告用户为了保证兼容性需要使用公开的API。如果你的bundle使用了内部代码，将无法保证兼容性。4.0版本提供的Eclipse 4应用平台提供了如下的特性： **6.4.1 模型工作台** 在4.0版本中，提供了一个模型工作台，它使用了Eclipse模型框架（Eclipse Modeling Framework，EMFgc）。鉴于渲染器需要与模型交互并生成SWT代码，有必要在模型和渲染视图之间进行关注点的分离。默认会使用SWT渲染器，但是其它的方案也是可行的。如果你创建了一个4.x的示例应用，会为默认的渲染模型创建一个XMI文件。模型可以进行修改，而工作台会随着模型的变化即时更新。图6.10是4.0的一个示例应用所生成的模型。  图6.10 4.0示例应用生成的模型 **6.4.2级联样式表样式** Eclipse发布于2001年，早于富互联网应用的时代，在这个时代可以使用CSS来实现皮肤的切换以提供不同的外观和体验。Eclipse4.0提供了使用样式表来容易地修改Eclipse应用外观和体验的功能。默认的CSS样式单可以在org.eclipse.platform bundle的css文件下找到。 **6.4.3 依赖注入** Eclipse的扩展注册器和OSGi服务都是基于服务模型编程的。按照惯例，服务编程模型包含服务的生产者和消费者。而居间者（broker）负责管理生产者和消费者的关系。  图6.11 服务生产者和消费者的关系 在传统的Eclipse3.4.x应用中，消费者需要了解为了使用服务需要了解实现类的位置并理解其在框架中的继承关系。这样消费者的代码可重用性就降低了因为不能重写消费者所能接受到的服务。例如，如果你想在Eclipse 3.x中更新状态栏中的信息，代码应该是这样的： ~~~ getViewSite().getActionBars().getStatusLineManager().setMessage(msg); ~~~ Eclipse 3.6是基于组件构建的，但是很多的组件耦合性很高。为了能够耦合更宽松的组件来组建应用，Eclipse4.0使用了依赖注入来为客户端提供给服务。Eclipse4.x中的依赖注入是通过使用一个自定义的框架来实现的，这个框架使用了上下文的理念来提供一个通用的机制来为消费者定位服务。上下文存在于应用和框架之间。上下文是有等级的。如果一个上下文的请求不能得到满足，它将会把这个请求委托给父上下文。Eclipse的上下文，名为IEclipseContext，存储了可用的服务并提供了OSGi服务的查找。简单来说，上下文类似于一个Java的map，里面提供了一个名字或类与对象之间的映射。上下文处理模型元素和服务。每个模型元素都有一个上下文。在Eclipse 4.x中，服务是以OSGi服务的机制进行发布的。  图 6.12 服务居间者上下文（Service Broker Context） 生产者将服务和对象添加到上下文中储存。通过上下文，服务被注册到消费者对象中。消费者生命需要的服务而上下文负责确定如何满足这个需求。这种方式使得使用动态服务更容易了。在Eclipse 3.x中，消费者需要注册监听器，当服务可用或不可用的时候获取通知。在Eclipse 4.x中，一旦一个上下文注入到消费者对象中，任何变化都会自动传递到那个对象中。换句话说，依赖注入会再次发生。消费者通过使用Java 5的注解来声明使用上下文，这些注解是符合JSR 330规范的如@inject，除此以外还会有一些自定义的Eclipse注解。构造器、方法以及域注入都是支持的。4.x的运行环境会扫描对象来寻找这些注解。实际执行的操作取决于使用的注解。 分离上下文和应用使得组件能够更好地常用，也使得服务的消费者免于理解内部实现。在4.x中，更新状态行的代码如下： ~~~ @Inject IStatusLineManager statusLine; ⋮ ⋮ ⋮ statusLine.setMessage(msg); ~~~ **6.4.4 应用服务** Eclipse 4.0的一个主要目标是简化用户使用的API以便于其实现通用的服务。简单的服务列表被称为“20件事”（the twenty things）或Eclipse应用服务。其目标是为用户提供单独的API使得用户不必深入了解所有的API。它们被组织成独立的服务，因此可以用于其它非Java语言，像JavaScript。例如，有这样的API可以访问应用模型，读取和修改首选项以及报告错误和警告。 ## 6.5 结论 基于组件化架构的Eclipse可以不断吸收新的技术而同时保证向后的兼容性。这样的成本比较高昂，但是回报在于Eclipse社区在不断发展壮大，因为用户能够基于建立起来的信任，不断使用这些稳定的API开发产品。 Eclipse广大的用户群体会有不同的使用场景而我们众多的API使得新的用户很难适应和理解。回顾过去，我们应该让API更简单一些。如果80%的用户只使用20%的API，有必要对其进行简化，这也是Eclipse 4.x创建的原因之一。 聪明的用户群体带来了有趣的使用场景，例如分解出IDE中的bundle来构建RCP应用。另一方面，群体有时候也会创造一些噪音来要求实现很少见的场景，这消耗了大量的时间来实现。 在Eclipse项目的早期，提交者有充裕的时间来编写文档、样例以及回答社区的问题。随着时间的推移，这个任务转移给了整个Eclipse社区。我们本可以提供更好地文档和样例来帮助社区，但是因为每个释放版本都会有大量的特性使得这变得很困难。一般情况下，软件发布总是会延期；然而在Eclipse，我们总是按期发布，这样做同时也可以帮助我们的客户建立起按期发布产品的信心。 通过吸收新技术以及重新改造Eclipse的外观和运行机制，我们会持续与用户进行交流并使他们留在我们的社区。如果你对Eclipse相关信息感兴趣，请访问http://www.eclipse.org。 **脚注** 1. http://www.eclipse.org 2. http://www.eclipse.org/equinox 3. For example: http://help.eclipse.org.