上周,Eclipse 组织发布了面向早期开发者的Eclipse4.0 SDK 。这次发布与已经正式发布的 Eclipse Helios 没什么关系。正相反,这次发布的 Eclipse 是个预览版,我们可以从中看出未来 Eclipse 是什么样子。
下一次同步发布的 Eclipse(代号为 Indigo ,或叫 Eclipse3.7)仍然会基于现有的 3.x 系列代码,但 Eclipse4.1 也会同时构建。那么为什么今年和明年要同时维护两个公共版本呢?在项目的首页是这样描述的:
Eclipse SDK 4.0 是下一代构建 Eclipse 工具和富客户端桌面应用的平台。对于开发者来说,新版本的发布让开发和装配应用变得更容易,包括构建基于 Eclipse 平台的工具。
本次 4.0 的发布主要面向早期开发者,他们想测试 Eclipse 向后的兼容性,移植插件或 RCP 应用。我们期待 Eclipse 的最终用户将采用 Eclipse 4.x 的未来版本。
虽然 Eclipse 4.0(之前称为 E4 )已经开发了两年时间,但只有在 2009 年 7 月发布了一个 E4 0.9 的预览版。E4 的原始白皮书描述了针对 Eclipse 平台本身一些反思。它描绘了 Eclipse 4.0 作为第三代 Eclipse 产品开发平台的场景:
- 第一代:Eclipse1.0 到 2.1。“主要是一个集成平台;其重要作用是聚集不同作者不同用途的插件,并通过组合的方式将它们整合为一个通用的具备一致性和连贯性终端用户体验的应用系统”
- 第二代:Eclipse 3.x。“基于 OGSi 运行时环境,Eclipse 成为一个更为强大的、通用的、基于组件机制的应用程序框架,其应用范围包括小的嵌入式应用到大规模富客户端应用和 Web 服务器”
- 第三代:Eclipse 4.x。“减少附加依赖和假设,扩大语言的集合并让更多的技术被无缝集成进来,这使得编写易于复用而且够适应广泛应用和环境的组件变得越来越简单了”
虽然 OSGi 技术为 Eclipse 应用系统提供了很好的服务,但很多 Eclipse 应用没有很好的表现出 OSGi 的特征。这是由于历史原因引起的。在没有 OSGi 的时代,有很多独立的框架(类似 <a href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/runtime/Platform.html">Platform</a>,``<a href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/ui/PlatformUI.html">PlatformUI</a>
和 IDE )被当作“神器( God Objects )”。这不仅是个面向对象的反模式,而且不能很好的适应 OSGi(动态)的服务
Eclipse 4.0 通过使用依赖注入(又叫 DI)的方式改进了上述情况,就像非常普及的 Sping 框架一样,让服务变得按需应用。甚至可以通过 javax.inject 的注解进行动态注入,与 OSGi 的声明服务(又叫 DS)完全解偶,提供了 OSGi 服务自动编码,例如:
复制代码
import javax.inject.Inject; import org.eclipse.e4.core.services.Logger; import org.osgi.service.packageadmin.PackageAdmin; public class Example { @Inject private Logger logger; @Inject private PackageAdmin packageAdmin; }
Eclipse 4.0 平台将采用自动注入服务的方式,从代码外层进行控制使用。(如果不需要操作该服务,那么可以使用 @Optional 对其进行标注。)这使得现有组件与基于 OSGi 组件化和服务的应用系统集成变得更容易。一系列 Eclipse 应用服务已经可用了。
Eclipse 4.x 的另一个重大改进是 UI 的构建方式。在 Eclipse 3.x 里,用户界面的构建是命令式的,通过手工代码生成 SWT(或 JFace)微件,并把它们摆放到屏幕上。虽然说 SWT 在平台特性上已经比基于 Swing 的用户界面好了很多,包括渲染性能和行为,但人们一直对使用这个工具包感觉很不安。一部分原因是,为了释放系统资源,SWT 的 UI 程序执行完成时必须调用 dispose() 方法。虽然看上去并不难,但是由于其不符合 java 规范,经常会被遗忘。此外,在类似 Eclipse 的托管环境中,如果某个有缺陷的插件出现资源泄露的情况,会导致整个系统无法正常运转。虽然有工具来检查是否有资源泄露(例如 sleak ),但是我们还是希望能够不用担心这些问题。
最近被 Google 收购的 Instantiations 公司有个获奖产品叫做Window Builder Pro,是一个RCP 程序的设计器,可以通过拖拽组件的方式创建UI 界面。这种方式不仅仅是比手工编写代码更容易,而且管理内存可以通过生成的代码来完成,编码人员不用再担心了。然而,随着这次收购,这些产品不在可用了──尽管我们可以从GWT 的博客描述中期待在未来几个月GWT 设计器有全新的表现。
那么这些和Eclipse 4.x 有什么关系呢?因为Eclipse 4.x 另外的重要变化就是声明式的用户界面开发。与HTML 很像,UI 是声明式而不是命令式,Eclipse 4.x 中的UI 是通过类似 XAML 或 XUL 的样式来定义的。不仅易于维护,而且意味着渲染引擎可以处理界面结构──从而可以对 UI 微件进行布局。最后,它还可以通过代码本身定义显示顺序,这就意味着可以通过外部代码改变应用系统的主题。
根据 HTML 模式,我们可以用 CSS 来定义 UI 的样式。这意味 Web 前端应用与桌面应用越来越相近了,可以基于相同的底层声明式表现层生成不同的界面风格。
最终希望达成的效果是,通过 Eclipse 的模型框架(EMF)可以方便的描述应用、视图和服务。UI 的编写可以通过模型化的微件和视图来实现,这意味着可以预先创建或生成模型并进行自我校验,还可以在运行时维护模型,类似 JavaScript 可以操作 Web 页面的 DOM 一样。
正如 Ian Skerrett指出,这是新平台旅程的开始。虽然Eclipse 4.0 是针对早期开发者的(已经知道存在不少问题),但其目标是在Eclipse3.x 平台上的插件经过微小的改动就可以移植到Eclipse4.x 上。Mike Wilson 在 EclipseZone 上有个访谈,内容是关于 Eclipse 4.0 的,主要探讨了在 Eclipse 4.0 中什么才是重要的,同时 Lars Vogel 和 Tom Schindl 编写的教程已经完成了。
评论