1 Eclipse插件开发系统的结论(接选)Eclipse插件开发已经是现在各大软件厂商比较关注的一个热点，在随着竞争日益激烈的今天，软件开发效率及质量成为软件厂商们不可不争的两个重要战略点，开发工具的实用性与方便性也成了这场竞争的关键,定制一套符合自己厂商特点的开发工具尤为重要。本文利用了Eclipse插件开发技术对基于J2EE框架的VO层代码生成工具系统进行了详细的设计与实现,结合现实,对基于Eclipse插件开发的教学具有一定的意义。本系统的最终实现，体现了JAVA技术在IDE开发中的强大优势，同时也证实了利用SWT来开发界面的合理性。系统满足了XXXX开发组的需求，为今后的开发工作奠定了坚实基础。
2 难点解决方案及心得
我个人并不是Eclipse的狂热爱好者，虽对java编程和相应的IED有一定的认识，但是一开始的时候对Eclipse的框架是不大了解的，所以在项目的进行中，也并不是一帆风顺，遇到了许多难题，犯过许多低级错误，项目开始的时候一天写不出一行代码，因为Eclipse的插件开发在国内时属凤毛麟角，能够查阅的中文书籍只有3本，网络论坛上的例子几乎只有halloword，在刚开始的两周内，每天的8小时工作时间里，平均要花6~7小时来读代码（这些代码是通过反编译其它有代表性的插件得来的），读资料（大部分是关于Eclipse架构的），剩下的时间用来和组员交换意见，经验和调侃项目的未来，在结束一天的工作之前写几行有重大突破的代码。渐渐的，我们的插件在问题的解决中不断的成型，下面列出一些开发难点和相应的解决方案
2.1 在Eclipse上为插件找一个切入点
当我们知道自己电脑中的类能干什么的时候，下一步就想到怎么才能在Eclipse的平台上展示自己的功能类，当然在此之前你必须学会在调试环境中正确的调试好你的功能类（最好能让它表现出来，HalloWord是一个不错的选择），接下来明确我们的问题：怎么让Eclipse把我们的类送进内存（调用并实例化），这一切都依赖于xml，在自己的插件项目生成的时候会自动生成一个plugin.xml文件，你只要在该文件中声明你要扩展的内容（功能类）和在哪扩展（表明扩展点）即可。在Eclipse启动时，平台的基础部分会查找系统中注册的插件，在plugin.xml中,形如class="com.dx.eclipse.plugin.VoDemoAction"的标签会找到是哪个类会在哪个动作发生后被调用。扩展点的问题在这里就不再累述了，只是想告述大家当你的动作（action）被触动时，却没有实例化你的类（必须保证你的功能类是可用的），你应该到plugin.xml中找一找了。
2.2 使用SWT不用Swing和AWT，why?
标准小窗口工具箱简称swt，它是java开发者的小工具箱，它提供可移植的API，并与计算机的底层操作系统的图形用户紧密集成。使用SWT小窗口可以直接实现工作台用户截面添加项，例如，视图、编辑器、向导和对话框等。
Java抽象窗口工具箱AWT的类库内容及其丰富，共有６０多个类和接口，包括了创建图形用户界面的所有工具。AWT为较底级别的小窗口（例如列表、文本和按钮等）提供了平台集成的小窗口，但是没有提供对较高级别的平台组件，例如树等的访问权。由于AWT组件通过与平台相关的对等类实现，因此AWT与底层操作系统具有紧密的联系，为了保证程序的一致性，应用程序的开发人员经常不得不只能使用在所有平台上都可用的小窗口。
小窗口工具箱设计中常见的问题是可移植工具箱与平台集成之间的平衡。Swing工具箱试图通过提供高级别小窗口，例如树、表和文本等的非本机实现来解决此问题。Swing为基于图形用户界面的应用程序开发，提供了一套精美，丰富的基本组件以及一个能使得图形用户独立于特定平台的显示框架。
Swing组件是用１００％纯java实现的轻量级组件，没有本地代码，不依赖本机操作系统的支持，这是它与AWT组件的最大区别。
Swing工具箱提供了许多功能，但是Swing中开发的应用程序的外观总是和同一操作系统下的其他软件显得差异很大。为了解决这一问题，通常使用平台外观模拟层帮助应用程序看起来像平台中的其他程序，但是与用户交互方式仍然有很大的不同。这使得基于Swing的图形用户界面的程序的外观总比为特定操作系统平台专门开发的应用程序的外观稍逊一筹。
SWT通过定义在所有受支持的平台上提供的常见可移植API来解决此问题，并尽可能使用本机小窗口在每个平台上实现该API。这使得工具箱在使用平台上维护一致的编程模型时立即反映底层操作系统的图形用户界面外观中的任何更改。
SWT最大化了操作系统的图形组件API，就是说只要操作系统提供了相应推行图形的组件，那么SWT只是简单应用JNI技术调用它们，只有那些操作系统中不提供的组件，SWT才自己去做一个模拟的实现，可以看出SWT性能上的稳定大多时候取决于相应操作系统图形组件的稳定性。
SWT是比Swing更紧密地映射到底层操作系统的本机图形技术，这不仅使得SWT更快速，而且使得java程序具有更像本机应用程序的外观和感觉，使用这个新的图形用户界面API可能会限制Eclipse工作台的可移植性，而使用Eclipse构建的任何java应用程序都不会受到影响，除非它们使用SWT而不是使用Swing或AWT。
SWT包含许多功能部件，但在开发图形用户界面程序中主要涉及小窗口、布局和事件。
2.3 小窗口应用程序的结构
典型的独立SWT应用程序具有下列结构。
（1） 创建显示，它表示SWT会话。
（2） 创建一个或多个Shell，它充当应用程序的主窗口。
（3） 创建Shell内部需要的任何其它小窗口。
（4） 初始化小窗口的大小和其它必须的状态。为需要处理的小窗口事件注册侦听器。
（5） 打开Shell窗口。
（6） 运行事件调度循环，直到发生退出情况为止（通常是在用户关闭主Shell窗口的情况下）。
（7） 除掉显示
显示表示SWT与底层平台的图形用户界面系统之间的连接。显示主要用来管理平台事件循环和控制用户界面线程与其它线程之间的通信。
2.4 SWT中应用程序的系统资源管理
SWT是用java开发的，java语言本身的一大优势就是java虚拟机的“垃圾回收机制”，程序员通常不用处理变量的释放和内存的回收等问题。然而，SWT并没有采用JVM的垃圾回收机制去处理操作系统的资源回收问题，SWT要求开发人员显式地释放已经分配的任何操作系统资源。主要原因是java虚拟机的垃圾回收机制是不可控的，也就是说开发人员不能知道，也不可能做到在某一时刻让 java虚拟机回收资源。因此在SWT中经验法则是：“谁创建，谁释放”。一般用组件的dispose()方法回收资源，如果程序调用某一组件的dispose()方法，那么所有这个组件也会被自动调用dispose()方法而销毁。通常这里指的是子组件与父组件的关系是在调用组件的构造函数时形成的。以下进一步说明此法则的特定规则：
（1）当使用构造函数来创建小窗口或图形对象时，使用完后必须显示释放它。
（2）如果没有使用构造函数就获取小窗口或图形对象，因为未分配它，因此不应显式释放它。
（3）如果将对小窗口或图形对象的引用传送至另一个对象，则在仍使用它时，注意不能释放它。
（4）当用户关闭Shell时，当递归地销毁Shell及其所有子代小窗口。在此情况下，不需要除掉小窗口本身，因为父组件被销毁，子组件也同时被销毁。然而，必须释放与那些小窗口一起分配的所有图形资源。
（5）如果创建图形对象以便在其中一个小窗口的生命周期内使用它，则在除掉小窗口时必须除掉图形对象。这可以通过向小窗口注册销毁侦听器，并在接受到销毁事件时释放图形对象来实现。
这些规则有一个例外。简单的数据对象，例如矩形和点，不使用操作系统资源。它们没有dispose()方法，因此也不需要释放他们。
2.5 数据库驱动的加载
在几乎所有与数据库有关的插件开发中，都会有数据库连接的问题，在这里大家都会遇到过no suitable driver这个问题，也许你会提出你的class12(oracle9i中jdbc连接用driver)Eclipse怎么都找不到，问题很简单，在你的plugin.xml中的<runtime>标签中添加<library name="你的classes12.jar"/>即可，但我并不主张这样不具备灵活性的做法，个人建议如果有能力和时间的话采取本地类加载的方法。
2.6 代码文件在资源浏览器的加载
如果你有一定的开发经验并乐于此道的话，在你的记忆中一定有一些值得你称道的代码，在代码生成器这个项目中若有的话，那就是下面的一句了：
VoDemo.getWorkspace().getRoot().refreshLocal(2,monitor) ;
看名字就知道了，它的作用就是刷新资源浏览器的内容，其实资源浏览器是一棵资源树，你可以先获得资源句柄，然后遍历它得到你想要的节点文件，进行添加，修改，删除等操作，在本项目中只涉及到把文件添加到资源浏览器中，所以只需把文件系统刷新到资源浏览器即可，你也许会问，为什么不直接访问文件系统呢，因为，在Eclipse中要频繁的对文件进行操作，如果直接访问文件系统就比较慢，把资源信息放在内存中就比较快啦。
2.7 在开发中我的角色是什么？我可以为什么角色？
在Eclipse的插件开发过程中，有这么几种角色：
使用者(User)，配置者(Configurer)，扩展者(Extender)，发布者(Publisher)，促成者(Enabler)，提交者(Committer)，。
使用者(User)：他们每天使用Eclipse。目前Eclipse的用户全是程序员，不过（至少在理论上）Eclipse完全可以用于组织其他信息处理工作。
配置者(Configurer)： 这些用户能够定制Eclipse的使用体验，譬如重新排列视角，设置某些参数，决定显示那些视图。不过他们只能在Eclipse平台和插件的开发预想的范围内进行配置。
扩展者(Extender)：这些程序员会对Eclipse做一些修改，修改的方式出乎Eclipse平台和插件开发者的预想之外。Eclipse允许你在很多地方“插入”新的功能，因为Eclipse本身就完全是由插入的功能搭建起来的。
发布者(Publisher)：如果你写了什么有用的东西，别的人也可能需要它。Eclipse有意识地为这种情况做了准备。因此你可以轻松地把自己的扩展打包发布，让别人能够加载使用他们。
促成者(Enabler)：整体来说，Eclipse是由“用于插入功能的地方”（扩展点）和“插入的功能”（扩展）所组成的。在发布自己的插件之后，下一步就应该促成其他人以出乎你预想的方式来扩展你的插件—方法就是发布你的扩展点。
提交者(Committer)：Eclipse是一个开源项目，如果现有的扩展点还不能够满足你的需要，你可以直接修改源码。要想把你的修改集成到全世界的Eclipse发布版本中，你必须首先获得整个社区的信任，成为一名提交者。
而我们的角色并不是一成不变的，因为，在Eclipse的世界里是以贡献的多少来评论角色的成就，你贡献的插件的质量越好，你就越被Eclipse社群认可，便可以享受别人的工作带来的好处，大大节省自己的工作精力，同时“地位”就越高。
在
这个循环中最有趣的是最后一个箭头：从“促成者”回到“使用者”。Eclipse社群不是企业，它的文化并不是“投入更多精力，获得更多的回报”这么简单。当你成为一名促成者，发布自己的扩展点时，你也为自己创造了一个机会—享用别人工作成果的机会。以后，别人可能会扩展你的插件，而你可能发现这个扩展对你很有用，由于创建并共享了自己的扩展点，你将可以享受别人的工作带来的好处，大大节省自己的精力。(在这里感谢熊节的努力)
