SWT本身仅仅是Eclipse组织为了开发Eclipse IDE环境所编写的一组底层图形界面 API 或许是无心插柳 或是有意为之 至今为止 SWT无论是在性能和外观上 都超越了SUN公司提供的AWT和SWING 目前Eclipse IDE已经开发到了 版本 SWT已经十分稳定 这里指的稳定应该包含两层意思
一是指性能上的稳定 其中的关键是源于SWT的设计理念 SWT最大化了 *** 作系统的图形构件API 就是说只要 *** 作系统提供了相应图形的构件 那么SWT只是简单应用JNI技术调用它们 只有那些 *** 作系统中不提供的构件 SWT才自己去做一个模拟的实现 可以看出SWT的性能上的稳定大多时候取决于相应 *** 作系统图形构件的稳定性
另一个稳定是指SWT API包中的类 方法的名称和结构已经少有改变 程序员不用担心由于Eclipse组织开发进度很快（Eclipse IDE每天都会有一个Nightly版本的发布） 而导致自己的程序代码变化过大 从一个版本的SWT更新至另一版本 通常只需要简单将SWT包换掉就可以了
第一个SWT程序
下面让我们开始一个SWT程序 （注意 以下的例子和说明主要针对Windows平台 其它的 *** 作系统应该大同小异） 首先要在Eclipse安装文件中找到SWT包 Eclipse组织并不提供单独的SWT包下载 必须下载完整的Eclipse开发环境才能得到SWT包 SWT是作为Eclipse开发环境的一个插件形式存在 可以在$｛你的eclipse安装路径｝\plugins路径下的众多子目录下去搜索SWT JAR文件 在找到的JAR文件中包含了SWT全部的Java类文件 因为SWT应用了JNI技术 因此同时也要找到相对应的JNI本地化库文件 由于版本和 *** 作平台的不同 本地化库文件的名称会有些差别 比如SWT WIN DLL是Window平台下Eclipse Build 的动态库 而在Unix平台相应版本的库文件的扩展名应该是 so 等等 注意的是 Eclipse是一个开放源代码的项目 因此你也可以在这些目录中找到SWT的源代码 相信这会对开发很有帮助 下面是一段打开空窗口的代码(只有main方法)
import e one examplepublic class OpenShell{ public static void main(String [] args) {Display display = new Display()Shell shell = new Shell(display)shell open()// 开始事件处理循环 直到用户关闭窗口while (!shell isDisposed()) { if (!display readAndDispatch())display sleep()}display dispose() }}
确信在CLASSPATH中包括了SWT JAR文件 先用Javac编译例子程序 编译无错后可运行java Djava library path=${你的SWT本地库文件所在路径} e one example OpenShell 比如SWT WIN DLL件所在的路径是C:\swtlib 运行的命令应该是java Djava library path=c:\swtlib e one example OpenShell 成功运行后 系统会打开了一个空的窗口
剖析SWT API
下面再让我们进一步分析SWT API的组成 所有的SWT类都用 eclipse swt做为包的前缀 下面为了简化说明 我们用*号代表前缀 eclipse swt 比如* widgets包 代表的是 eclipse swt widgets包
我们最常用的图形构件基本都被包括在* widgets包中 比如Button Combo Text Label Sash Table等等 其中两个最重要的构件当数Shell和Composite Shell相当于应用程序的主窗口框架 上面的例子代码中就是应用Shell构件打开一个空窗口 Composite相当于SWING中的Panel对象 充当着构件容器的角色 当我们想在一个窗口中加入一些构件时 最好到使用Composite作为其它构件的容器 然后再去* layout包找出一种合适的布局方式 SWT对构件的布局也采用了SWING或AWT中Layout和Layout Data结合的方式 在* layout包中可以找到四种Layout和与它们相对应的布局结构对象（Layout Data） 在* custom包中 包含了对一些基本图形构件的扩展 比如其中的CLabel 就是对标准Label构件的扩展 上面可以同时加入文字和图片 也可以加边框 StyledText是Text构件的扩展 它提供了丰富的文本功能 比如对某段文字的背景色 前景色或字体的设置 在* custom包中也可找到一个新的StackLayout布局方式
SWT对用户 *** 作的响应 比如鼠标或键盘事件 也是采用了AWT和SWING中的Observer模式 在* event包中可以找到事件监听的Listener接口和相应的事件对象 例如常用的鼠标事件监听接口MouseListener MouseMoveListener和MouseTrackListener 及对应的事件对象MouseEvent
* graphics包中可以找到针对图片 光标 字体或绘图的API 比如可通过Image类调用系统中不同类型的图片文件 通过GC类实现对图片 构件或显示器的绘图功能
对不同平台 Eclipse还开发了一些富有针对性的API 例如 在Windows平台 可以通过* ole win 包很容易的调用ole控件 这使Java程序内嵌IE浏览器或Word Excel等程序成为可能！
更复杂的程序
下面让我们展示一个比上面例子更加复杂一些的程序 这个程序拥有一个文本框和一个按键 当用户点击按键的时候 文本框显示一句欢迎信息
为了文本框和按键有比较合理的大小和布局 这里采用了GridLayout布局方式 这种布局是SWT中最常用也是最强大的布局方式 几乎所有的格式都可能通过GridLayout去达到 下面的程序也涉及到了如何应用系统资源(Color) 以及如何释放系统资源
private void initShell(Shell shell) { //为Shell设置布局对象 GridLayout gShellLay = new GridLayout() shell setLayout(gShellLay) //构造一个Composite构件作为文本框和按键的容器 Composite panel = new Composite(shell SWT NONE) //为Panel指定一个布局结构对象 这里让Panel尽可能的占满Shell 也就是全部应用程序窗口的空间 GridData gPanelData = new GridData(GridData GRAB_HORIZONTAL| GridData GRAB_VERTICAL|GridData FILL_BOTH) panel setLayoutData(gPanelData) //为Panel也设置一个布局对象 文本框和按键将按这个布局对象来显示 GridLayout gPanelLay = new GridLayout() panel setLayout(gPanelLay) //为Panel生成一个背景色 final Color bkColor = new Color(Display getCurrent() ) panel setBackground(bkColor) //生成文本框 final Text text = new Text(panel SWT MULTI|SWT WRAP) //为文本框指定一个布局结构对象 这里让文本框尽可能的占满Panel的空间 GridData gTextData = new GridData (GridData GRAB_HORIZONTAL| GridData GRAB_VERTICAL|GridData FILL_BOTH) text setLayoutData(gTextData) //生成按键 Button butt = new Button(panel SWT PUSH) butt setText( Push ) //为按键指定鼠标事件 butt addMouseListener(new MouseAdapter(){public void mouseDown(MouseEvent e){ //当用户点击按键的时候 显示信息 text setText( Hello SWT )} } //当主窗口关闭时 会触发DisposeListener 这里用来释放Panel的背景色 shell addDisposeListener(new DisposeListener(){public void widgetDisposed(DisposeEvent e) { bkColor dispose()} }}
把这段代码中的方法initShell()加入到第一个打开空窗口的例子中 得到的是一段能成功运行的完整GUI应用程序 运行方法可参考第一个例子
系统资源的管理
在一个图形化的 *** 作系统中开发程序 都要调用系统中的资源 如图片 字体 颜色等 通常这些资源都是有限的 程序员务必非常小心的使用这些资源 当不再使用它们时 就请尽快释放 不然 *** 作系统迟早会油尽灯枯 不得不重新启动 更严重的会导致系统崩溃 SWT是用Java开发的 Java语言本身的一大优势就是JVM的 垃圾回收机制 程序员通常不用理会变量的释放 内存的回收等问题 那么对SWT而言 系统资源的 *** 作是不是也是如此？答案是一个坏消息 一个好消息
坏消息是SWT并没采用JVM的垃圾回收机制去处理 *** 作系统的资源回收问题 一个关键的因素是因为JVM的垃圾回收机制是不可控的 也就是说程序员不能知道 也不可能做到在某一时刻让JVM回收资源！这对系统资源的处理是致命的 试想你的程序希望在一个循环语句中去查看数万张图片 常规的处理方式是每次调入一张 查看 然后就立即释放该图片资源 而后在循环调入下一张图片 这对 *** 作系统而言 任何时刻程序占用的仅仅是一张图片的资源 但如果这个过程完全交给JVM去处理 也许会是在循环语句结束后 JVM才会去释放图片资源 其结果可能是你的程序还没有运行结束 *** 作系统已经宕掉
但下面的好消息也许会让这个坏消息变得无关紧要 对于SWT 只需了解两条简单的 黄金 法则就可以放心的使用系统资源！之所以称为黄金法则 一是因为少 只有两条 二是因为它们出奇的简单 第一条是 谁占用 谁释放 第二条是 父构件被销毁 子构件也同时被销毁 第一条原则是一个无任何例外的原则 只要程序调用了系统资源类的构造函数 程序就应该关心在某一时刻要释放这个系统资源 比如调用了
Font font = new Font (display Courier SWT NORMAL)
那么就应该在不在需要这个Font的时候调用
font dispose()
对于第二个原则 是指如果程序调用某一构件的dispose()方法 那么所有这个构件的子构件也会被自动调用dispose()方法而销毁 通常这里指的子构件与父构件的关系是在调用构件的构造函数时形成的 比如
Shell shell = new Shell()Composite parent = new Composite(shell SWT NULL)Composite child = new Composite(parent SWT NULL)
其中parent的父构件是shell 而shell则是程序的主窗口 所以没有相应的父构件 同时parent又包括了child子构件 如果调用shell dispose()方法 应用第二条法则 那么parent和child构件的dispose()方法也会被SWT API自动调用 它们也随之销毁
线程问题
在任何 *** 作平台的GUI系统中 对构件或一些图形API的访问 *** 作都要被严格同步并串行化 例如 在一个图形界面中的按键构件可被设成可用状态(enable)或禁用状态(disable) 正常的处理方式是 用户对按键状态设置 *** 作都要被放入到GUI系统的事件处理队列中（这意味着访问 *** 作被串行化） 然后依次处理（这意味着访问 *** 作被同步） 想象当按键可用状态的设置函数还没有执行结束的时候 程序就希望再设置该按键为禁用状态 势必会引起冲突 实际上 这种 *** 作在任何GUI系统都会触发异常
Java语言本身就提供了多线程机制 这种机制对GUI编程来说是不利的 它不能保证图形构件 *** 作的同步与串行化 SWT采用了一种简单而直接的方式去适应本地GUI系统对线程的要求 在SWT中 通常存在一个被称为 用户线程 的唯一线程 只有在这个线程中才能调用对构件或某些图形API的访问 *** 作 如果在非用户线程中程序直接调用这些访问 *** 作 那么SWTExcepiton异常会被抛出 但是SWT也在* widget Display类中提供了两个方法可以间接的在非用户线程的进行图形构件的访问 *** 作 这是通过syncExec(Runnable)和asyncExec(Runnable)这两个方法去实现 例如
//此时程序运行在一个非用户线程中 并且希望在构件panel上加入一个按键
Display getCurrent() asyncExec(new Runnable() { public void run() {Button butt = new Button(panel SWT PUSH)butt setText( Push ) }})
方法syncExec()和asyncExec()的区别在于前者要在指定的线程执行结束后才返回 而后者则无论指定的线程是否执行都会立即返回到当前线程
SWT的扩展 JFace
JFace与SWT的关系好比Microsoft的MFC与SDK的关系 JFace是基于SWT开发 其API比SWT更加易于使用 但功能却没SWT来的直接 比如下面的代码应用JFace中的MessageDialog打开一个警告对话框
MessageDialog openWarning(parent Warning Warning message )
如果只用SWT完成以上功能 语句不会少于 行!
JFace原本是为更加方便的使用SWT而编写的一组API 其主要目的是为了开发Eclipse IDE环境 而不是为了应用到其它的独立应用程序 因此在Eclipse 版本之前 很难将JFace API完整的从Eclipse的内核API中剥离出来 总是要多多少少导入一些非JFace以外的Eclipse核心代码类或接口才能得到一个没有任何编译错误的JFace开发包 但目前Eclipse组织似乎已经逐渐意识到了JFace在开发独立应用程序起到的重要作用 在开发的 版本中 JFace也开始变成了和SWT一样的完整独立的开发包 只是这个开发包还在变动中(笔者写本文时 应用的Eclipse M 版本) JFace开发包的包前缀是以 eclipse jface开头 JAR包的源代码也和SWT一样 也在$｛你的eclipse安装路径｝\plugins路径下去找
对开发人员来说 在开发一个图形构件的时候 比较好的方式是先到JFace包去找一找 看是不是有更简洁的实现方法 如果没有再用SWT包去自己实现 比如JFace为对话框提供了很好的支持 除了各种类型的对话框(比如上面用的MessageDialog 或是带有Title栏的对话框) 如要实现一个自定义的对话框也最好从JFace中的Dialog类继承 而不是从SWT中的* widget Dialog继承
应用JFace中的Preference包中的类很容易为自己的软件做出一个很专业的配置对话框 对于Tree Table等图形构件 它们在显示的同时也要和数据关联 例如Table中显示的数据 在JFace 中的View包中为此类构件提供了Model View方式的编程方法 这种方法使显示与数据分开 更加利于开发与维护 JFace中提供最多的功能就是对文本内容的处理 可以在 eclipse jface text * 包中找到数十个与文本处理相关类
与应用程序更近一步
Java程序通常是以class文件的方式发布的 运行class需要JRE或JDK的支持 这又是Java GUI程序的另一个致命的弱点 想象对一个面向广大用户的应用程序来说 无论你的程序功能有多简单 或是你的代码十分的精简 你都不得不让用户去下载一个 M的JRE 那是多么令人沮丧的一件事 而且对程序员来说 Class通常意味着源代码的暴露 反编译的工具让那些居心叵测的人轻易得到你的源代码 虽然有很多对Class的加密方法 但那总是以牺牲性能为代价的 好在我们还有其它的方式可用 把Class编译成exe文件!
lishixinzhi/Article/program/Java/gj/201311/27737
我承认即使在JavaFX出现之前Java已经在桌面领域做出了一些重大的提升，比如Swing中的提升我们现在也有了很棒的OpenGLDirectX也有了很大的提升启动时间也显着提升了。没错，昌平IT培训认为Java在去年做了很多显着而有效的工作。
然而不得不说的是，除此之外其他的仍是一塌糊涂。比如Javasound实际上并不好用，被遗弃的Java3D又如何呢?最近甚至JOGL也被Sun遗弃，包括很久之前的SwingLabJAI(用作图片处理)多年未真正升级过，看起来也没有在什么地方得到利用，它迫切需要性能上的巨大提升以适应来临的多核GPU时代所有这些应用于桌面领域的Java产品不是被遗弃就是成为鸡肋。
而且很关键一点是，尽管我们可以用Java创建出桌面应用，但只要我们想开发真正的富桌面应用我们就无法真正使用Java而使用JNI、C/C++和平台依赖的libraries等。
使用Java构建桌面应用更多的是困难和麻烦，比如即便想要在Java应用内创建一个高效的优良的web浏览器都是一件难事。而且没有用Java编写的图片处理应用，没有一个纯粹的Javaweb浏览器，没有数字音频应用，没有3D建模器，没有矢量图形编辑器，没有先进的光栅编辑器。Java今日在桌面端所到达的高度只能满足那些服务器开发者，因为他们只需要在远程服务时使用电脑桌面上的简单界面。
过去我们一直说这是因为Java太慢，无法在一个慢的平台上开发出如此复杂的应用。但我们这样说是错的。原因有两点：一，Java从来就没有慢过，即便有些部分曾经慢过，但没有人怀疑当它需要被用到服务器端时它会迅速地得到提升，比如JITs，GCs等。这一点也正是Java语言卓越的地方。二，由于Java平台的天然特性，Java应用总是第一个利用市场上新硬件和新 *** 作系统的应用。一旦JVM被配置到了一个新系统中，几乎不需要任何编辑和调试，Java应用就可以在上面全速运行。比如你在32位的 *** 作系统上开发了一个应用，它就可以全速运行在Windows7或者Solaris的64位JVM上。所以所谓的Java太慢根本不能成为Java在桌面端碌碌无为的借口。
我承认即使在JavaFX出现之前Java已经在桌面领域做出了一些重大的提升 比如Swing中的提升 我们现在也有了很棒的OpenGL DirectX也有了很大的提升 启动时间也显著提升了 没错 Java在去年做了很多显著而有效的工作
然而不得不说的是 除此之外其他的仍是一塌糊涂 比如Java sound实际上并不好用 被遗弃的Java D又如何呢？最近甚至JOGL也被Sun遗弃 包括很久之前的SwingLab JAI（用作图片处理）多年未真正升级过 看起来也没有在什么地方得到利用 它迫切需要性能上的巨大提升以适应来临的多核GPU时代所有这些应用于桌面领域的Java产品不是被遗弃就是成为鸡肋
而且很关键一点是 尽管我们可以用Java创建出桌面应用 但只要我们想开发真正的富桌面应用我们就无法真正使用Java而使用JNI C/C++和平台依赖的libraries等
使用Java构建桌面应用更多的是困难和麻烦 比如即便想要在Java应用内创建一个高效的优良的web浏览器都是一件难事 而且没有用Java编写的图片处理应用 没有一个纯粹的Java web浏览器 没有数字音频应用 没有 D建模器 没有矢量图形编辑器 没有先进的光栅编辑器 Java今日在桌面端所到达的高度只能满足那些服务器开发者 因为他们只需要在远程服务时使用电脑桌面上的简单界面
过去我们一直说这是因为Java太慢 无法在一个慢的平台上开发出如此复杂的应用 但我们这样说是错的 原因有两点 一 Java从来就没有慢过 即便有些部分曾经慢过 但没有人怀疑当它需要被用到服务器端时它会迅速地得到提升 比如JITs GCs等 这一点也正是Java语言卓越的地方 二 由于Java平台的天然特性 Java应用总是第一个利用市场上新硬件和新 *** 作系统的应用 一旦JVM被配置到了一个新系统中 几乎不需要任何编辑和调试 Java应用就可以在上面全速运行 比如你在 位的 *** 作系统上开发了一个应用 它就可以全速运行在Windows 或者Solaris的 位JVM上 所以所谓的Java太慢根本不能成为Java在桌面端碌碌无为的借口
而且 如果你是一个终端用户 你甚至不需要从网站上重新下载应用 这意味着不仅终端用户和开发者得到了速度提升 甚至应用的执行性能的前边也得到了速度提升 今天 JIT在runtime为本地 *** 作优化代码已经做得很棒了 这意味着你可以挖掘出你运行的硬件的全部的能力 这是一个静态编译语言永远也无法竞争过的性能 只是这个性能如果可以运用到桌面端和游戏领域就好了
我们总是说 由于Sun总是一个服务器端公司的原因 Java在桌面端一直没有真正的机会 而Oracle的收购让这种境况看起来不会有什么改变 希望这不要再继续下去 为了Sun Oracle和Java自身的利益 Oracle内部的知名人士应该提醒公司来让他们知道 如果缺乏了在桌面端的能力和效率 必将影响Java的普及率甚至它在服务器端的占有率
我们一直以来习惯着Sun主要提供服务器端服务 因而想象著未来更多的处理能力还是出现在服务器端 而客户端不过是连接服务器的简单服务 这种情况已被证明是绝对错误的 因为未来的桌面应用将服务 应用与硬件所有的运算能力相结合 大量的数据和解码 声音 图像 视频被开发者处理 而且用并行编程的方式来实现 既保证了丰富的性能又保证了速度 对开发者来说 未来的服务既需要他们在客户端处理也需要在服务器端处理 执行复杂的搜索 图像 视频以及虚拟 D环境需要服务器端的技术 而远程服务如医学分析 远程教育和远程会议等则需要客户端能力
只是令我们感到失望的是历史又一次地重复了 因为至今Java中还没有什么大的动作
armin Ehrenreich 在回复中说道 说的好 我完全认同
确实迫切需要跨平台的桌面应用技术 而且我不认为C++结合Qt是个好的选择 你说阐述的问题之所以没有引起很多的共鸣 我想是文化上的问题 许多Java社区的人们包括Sun内部的负责人无法理解你所说的 所以我断言Oracle也不会对Java做出什么大的改变
客户端现在基本上被微软和Apple包揽 到Cocoa论坛中会发现他们谈论的是GUI的可用性 响应性 终端户如何处理桌面应用等而我们的论坛呢 大部分人认为应用的未来在服务器端 这就是文化上的差异
但是桌面技术需要做很多工作 Swing很慢很慢地进化 连同Netbeans平台 Java D JOGL等应用勉强成为了桌面端的一个选择 但Sun置此境遇于不顾 只是模仿Flash发布了一款新的脚本语言 但是那些API只有使用JavaFX才可用
Jeff Martin回复道 正确的观点 但我有一点不同 Sun真正的问题是他应该吃自己的饭 用自己的力量来用Java写一些实在的桌面应用 这可以证明他们关于Java在桌面端的承诺 证明他们可以写出应用 提升框架和工具 我不认为另一个框架会帮助Java
James Sugrue回复道 我同意作者观点 我也很支持桌面端开发 看看现在处于开发中的Eclipse e 中的一些项目 它们为桌面和浏览器提供了一个解决方案 所以我想还是有一些希望的 但我认为我们不需要过分聚焦于桌面端 JavaFX是正确方向上的一个迈进 只是无法在Swing和Java D/JOGL中看到应用提升
Osvaldo Doederlein回复道 我认为JOGL的支持没有那么糟糕 毕竟它是JavaFX Desktop Runtime的一个依赖 实际上 我们可以写一个非JavaFX的小程序 而且不需要请求本地代码的许可性就可以配置
lishixinzhi/Article/program/Java/hx/201311/25625
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）