Windows 上使用 GCJ+SWT 开发 native GUI 应用

我准备写一套在 Windows 上使用 GCJ+SWT 开发 native GUI 应用的教程。因为我们有时候会为用户提供一些本机使用的工具。我们想用 Java 来开发（这样我们可以集中精力研究 Java，而不必同时使用多种语言），但是又不想迫使用户安装 JRE（虽然安装 JRE 很简单，但是多为用户着想还是受欢迎的）。
因为时间有限，只能一次写一点。今天我先介绍一下 GCJ for  Windows 的安装方法。
首先需要下载以下这些包：
http://mingw.sourceforge.net/download.shtml
binutils
gcc-core
mingw-runtime
w32api
gcc-java

建议从下载页的 Current 列表中下载这些包的稳定版本。
http://prdownloads.sf.net/mingw/binutils-2.13.90-20030111-1.tar.gz?download
http://prdownloads.sf.net/mingw/gcc-core-3.3.1-20030804-1.tar.gz?download
http://prdownloads.sf.net/mingw/mingw-runtime-3.2.tar.gz?download
http://prdownloads.sf.net/mingw/w32api-2.4.tar.gz?download
http://prdownloads.sf.net/mingw/gcc-java-3.3.1-20030804-1.tar.gz?download

下载后按照上述顺序将其解压到相同的目录，例如 D:\mingw
然后将 D:\mingw\bin 加入 PATH 环境变量。
打入
gcj -v
试一下，出现版本信息就没问题了。

下次我来讲讲如何使用 GCJ 将 SWT 编译为本地的库文件。
心急的朋友可以直接去看 DeveloperWorks 上的文档：
http://www-106.ibm.com/developerworks/java/library/j-nativegui2/

目前在 Windows 上使用 GCJ+SWT 开发 native GUI 应用的一个最大的障碍是 GCJ for Windows 不能很好地支持中文。出现这个问题的原因是，GCJ for Linux/Unix 使用 iconv 的库来做字符集的转换，GCJ for Windows 没有连接 iconv，虽然 iconv 很早前就已经被移植到 Windows 上。所以 GCJ for Windows 没有 --encoding 选项，不能做字符集的转换，因此不能很好地支持中文。随着这个教程的深入，我们将讨论出一个可行的解决方案。我能想到的一个方案是重新编译 GCJ，连接 iconv，使 GCJ 获得 --encoding 选项和字符集转换的能力。

按照 Kirk Vogen 先生写的这个教程，将 SWT 编译为本地的库文件是一件很容易的事（当然你要感谢 Kirk 为你所做的大量铺路的工作，包括为 SWT 所打的 patch）。
首先下载 Kirk 为这个教程所做的例子：
ftp://www6.software.ibm.com/software/developer/library/j-nativegui2.zip
解压缩到任何位置。
这个例子中含有 SWT 2.0.2 版的源代码。由于 GCJ 当前版本中有一些 bug，要用 GCJ 成功编译 SWT，需要对 SWT 打些 patch。不必担心，所有这些麻烦事 Kirk 都已经为你做好了。

编译 SWT 前，首先要保证你已经有了以下这些工具：
1、Ant 1.5.0 以上版本。如果你已经安装了 Eclipse，就不必另外下载 Ant 了。Ant 在 Eclipse 的 plugins\org.apache.ant_1.5.3 目录下，将 ant.jar 加入到 CLASSPATH。另外你还要将 JDK 中的 tools.jar 加入到 CLASSPATH。
2、GCJ 3.2 以上版本，前面我们不是已经装了吗？
3、一个小工具 patch。如果你没有 Windows 版的 patch，不必担心，例子的中有这个工具。在 Utilities\win32 目录下，把这个目录加入 PATH 环境变量。

好了，现在进入例子的 Library 目录。执行：
java org.apache.tools.ant.Main -Dos=win32 -Dwindow_system=win32
如果最后报告
BUILD SUCCESSFUL
就没有问题了。
最后将生成一个
lib-org-eclipse-swt.a
的库文件，大约 6.4M，这个文件就是从 SWT 源代码编译成的本地库文件。

如果编译出错，可以先执行：
java org.apache.tools.ant.Main clean
然后再重新执行上面的命令进行编译。

需要注意的是，GCJ for Windows 目前仅能将 SWT 编译为静态库，而不能编译为动态库（Linux/Unix 上不存在这个限制）。所以应用程序连接 SWT 后将变得非常大，一个 HelloSWT 的简单程序都会有几M。不过开源软件是会不断发展的，只要你有足够的耐心，这个问题总能解决。如果有足够的时间的话，也许你自己就可以解决。

下面就可以写几个 SWT 应用编译出来试试了。可以从 Kirk 写的这个 ControlExample 的例子入手。
进入 ControlExample 目录，执行：
java org.apache.tools.ant.Main
正常情况下应该报告
BUILD SUCCESSFUL
并且这个目录下出现了一个 ControlExample.exe，大约 3.8M，显然是静态连接的结果。没办法，等 GCJ for Windows 的发展吧。
执行这个程序前要先把
Eclipse_2.0.2_SWT_Source\plugins\org.eclipse.swt.win32\os\win32\x86\swt-win32-2052.dll
copy 到 PATH 环境变量的某个目录中。然后执行：
ControlExample
这就是一个 native 的 SWT 程序了。

中文问题的一个解决方法是把要显示的中文放在资源文件中，然后使用 native2ascii 对资源文件做转换，使用转换后的资源文件。
比如我修改了 ControlExample 的资源文件，将 Text_Buttons 改为：
Text_Buttons = Text 中国人Buttons
然后用 native2ascii 做转换，
编译后的程序中就可以显示中文了。SWT 对 I18N 的支持真的是非常棒！看来解决中文问题不需要重新编译 GCJ 了。Good! 现在只剩下一个动态连接的问题了。
附件是程序显示的界面。

  谢谢分享这样的文章，我想知道如果转化那种SWT控件很多的应用工具，转化出来的文件size会不会很大？性能上和使用JRE相比有什么不同吗？

  另外JRE不一定要user安装的，我们可以copy一个在应用工具的子目录下面，只要有相关的dll，rt.jar，charsets.jar（中文支持），然后对启动脚本做一些修改，就可以把整个目录打包作为产品发布了。我在Jdk 1.4.1 + windows 2000下面测试过，不知道其他版本的情况会不会有意外。

呵呵，因为目前只能做静态连接，所以编译出来的文件会很大。性能上比在 JRE 上跑要快不少，那个 native 的 Eclipse build 不是自称是这个星球上最快的 Eclipse 吗？编译出来的程序如果不加调试信息，并且做过 strip 之后会小得多，跑起来也会更快。robbin 以前对 Java 的本地编译做过比较深入的分析。请看：
http://www.linuxtea.org/phpBB2/viewtopic.php?t=1963

这是一个 open 的讨论，大家都可以参与，目标是等到 GCJ for Windows 足够强大后可以直接用在我们的项目和产品中。
我研究过一些 JRE、JDK 的 license。Sun 的 JRE 是可以随商业产品自由发布的，但是 IBM 的 JRE 不可以。BEA 只有 JDK，没有提供单独的 JRE。这 3 个厂商的 JDK 都不可以随商业产品自由发布。不过随着一些开源 JRE/JDK 的成熟，摆脱这些大厂控制的时间已经不远了。
BTW，改变 JRE 的目录结构好象也是不允许的。

Cool, 按这一点来说确实是一个很好的工具。

我没有改变Sun JRE的目录结构，只是删除了一些不必要的文件，关于这样是否抵触License，我倒是没有考虑， ，谢谢提醒，得再去看看了。

最后再补充一点，如何编译使用了 JNI 的程序。
GCJ 对于 JNI 有很好的支持，在 GCJ FAQ（http://www.gnu.org/software/gcc/java/faq.html）中说：
2.2 Does GCJ support using straight C native methods ala JNI?
Yes. libgcj now has experimental support for JNI, in addition to its native Compiled Native Interface (CNI). gcjh will generate JNI stubs and headers using the "-jni" option. However, we do prefer CNI: it is more efficient, easier to write, and (at least potentially) easier to debug.
除了支持标准的 JNI 接口外，GCJ 还支持其独有的 CNI 接口。

因为 SWT 中含有大量的 JNI 调用（调用本机窗口系统的功能），所以编译 SWT 的时候，必须要加上 -fjni 这个选项，这个选项目将被 GCJ 传递给调用的低层工具。在 SWT 的创建文件 build.xml 中我们可以看到正是使用了这个选项来调用 GCJ 的。
<arg value="-fjni"/>

robbin 在前一篇文章中遇到的问题确实是带有普遍性的问题。目前已经有几个项目把一些常用的工具用 GCJ 编译为本地版本。例如：
RHUG：http://sources.redhat.com/rhug/
NAOKO：http://people.redhat.com/gbenson/naoko/

我们看到，一些常用的工具如 Ant、JUnit、Tomcat、MySQL-JDBC、PostgreSQL-JDBC、Struts、Xerces、Xalan 都已经编译成了 native 的版本。前些时候我们还听说有人把 Eclipse 完全编译成了 native 的版本。
所以有一天我给你一个 ant.exe 或者 tomcat.exe 你可别大惊小怪。

不过本地编译在一个较长的时间内是无法取代 JVM 的。它只能作为 JVM 的补充，并且给我们带来了很多编程的乐趣。Just for fun! 呵呵。