|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2003-11-24
robbin 写道 我在自己的Java程序里面使用了Java的动态加载类的功能，比如说动态加载数据库驱动类库，动态加载外部配置文件。
先说动态加载类库，程序运行失败。分析一下原理，确实是不能动态加载的。因为Java程序是靠JVM使用Classloader来加载类库，现在JVM都没有了，怎么加载？当然行不通了。 看来解决办法只能是把要动态加载的类库预先编译成DLL，放在PATH路径下，让操作系统来动态加载DLL。 JVM --load--> Class Library OS --load--> DLL 配置文件的动态加载大概只能另想办法了，只能在编译应用程序的时候就当做资源文件编译进去。不过这样也失去了可以动态修改配置文件的功能了。实在是得不偿失。 动态加载这个问题在文档： http://www.cs.umanitoba.ca/~eclipse/6-Compiling.pdf 中是这样解决的，添加一个新的类： public class ForceInclude {
private static final Class class1 = gnu.java.locale.Calendar.class;
private static final Class class2 = gnu.java.locale.LocaleInformation.class;
private static final Class class3 = com.mysql.jdbc.Driver.class;
private static final Class class4 = org.hsqldb.jdbcDriver.class;
ForceInclude(); {
}
}
这样用 GCJ 编译后要用到的类都已经知道了，就不需要再调用： Class.forName("com.mysql.jdbc.Driver");;
或者： Class.forName("org.hsqldb.jdbcDriver");;
动态加载了。确实如 robbin 所说，失去了动态加载的所有优点。 关于 RMI： RMI 好象已经进入 GCJ 3.3 的正式版本，但是其中含有不少的 bug，在 GCJ Maillist 中有这方面的讨论。 |
| 返回顶楼 | |
|
发表时间：2003-11-24
关于动态连接，一个需要研究的问题是如何把 Java 程序做成动态连接库，为何 GCJ 的 Linux 版可以把 SWT 编译为 shared libraries（*.so）而 Windows 版却不能把 SWT 编译为 DLL？这是我们需要深入探讨的问题。解决了这个问题，动态连接和程序规模的问题就迎刃而解了。我将在业余时间继续关注这个问题的解决。
剩下的两个问题是： 1、GCJ 如何将 Java 程序编译为 DLL？ 2、GCJ 如何支持中文字符集（GB2312、GBK、GB18030、BIG5、etc.）？SWT 似乎并不受 GCJ 在这方面的限制。SWT 中是如何支持 I18N 的？ 感兴趣的朋友可以和我共同创建一个项目来做这件事。 |
| 返回顶楼 | |
|
发表时间：2003-11-24
dlee 写道 2、GCJ 如何支持中文字符集（GB2312、GBK、GB18030、BIG5、etc.）？SWT 似乎并不受 GCJ 在这方面的限制。SWT 中是如何支持 I18N 的？
这个是不是和GCJ无关？因为资源文件是已经转成ascii了，GCJ自然可以支持，SWT再通过调用OS的api来显示。调整window的显示方案，你会发现SWT的菜单显示也会不一样的。 |
| 返回顶楼 | |
|
发表时间：2003-11-25
我提的这两个问题 Mohan Embar 老兄看来都已经解决掉了。这里有最新版本的 GCJ for Windows 和 SWT。
http://www.thisiscool.com/gcc_mingw.htm http://gcc.gnu.org/ml/java/2003-11/msg00272.html http://gcc.gnu.org/ml/java-patches/2003-q4/msg00438.html 我将考察 Mohan Embar 所做的 patch，并且在解决完上述问题后把所有的经验写入这个教程。 |
| 返回顶楼 | |
|
发表时间：2003-11-26
GCJ 的主要设计者和前期的主要开发者 Per Bothner 的文章“Compiling Java with GCJ”是我看到过的介绍 GCJ 最深入的文章。
http://www.linuxjournal.com/article.php?sid=4860 文中详细地比较了 JVM/JIT 和本地编译各自的优缺点，并且对 JNI 的缺点做了评论。 Per Bothner 是自由软件开发的元老级人物，从 1980 年代就开始为 GNU 贡献代码。他也是 GCC 开发人员之一。按照 Per Bothner 的说法，编译 Java 程序比编译 C++ 程序简单多了。 GCJ 中有一个 Java 解释器，gij，相当于 JDK 中的 java。gij 实现了全功能的 ClassLoader，所以也可以把 GCJ 当作是一个 OpenSource 的 JVM。在 gij 上可以跑 Eclipse，请看： Running Eclipse with gcj/gij http://www.klomp.org/mark/gij_eclipse/index.html |
| 返回顶楼 | |
|
发表时间：2003-12-07
这样开发桌面GUI应用程序 和 用Kylix开发个有什麽优略呢，哪个效率更高一些？
|
| 返回顶楼 | |
|
发表时间：2003-12-08
lyo 写道 这样开发桌面GUI应用程序 和 用Kylix开发个有什麽优略呢，哪个效率更高一些？
这只是一个雏形，根本无法与 Kylix 的开发效率相提并论。只适合开发一些纯桌面应用的小工具。 |
| 返回顶楼 | |
|
发表时间：2003-12-10
原来这样，那麽这个Linux上的Delphi和Jbuilder开发出的Swing应用程序哪个运行速度更快？
|
| 返回顶楼 | |
|
发表时间：2003-12-11
lyo 写道 原来这样，那麽这个Linux上的Delphi和Jbuilder开发出的Swing应用程序哪个运行速度更快？
答案是无疑的，肯定是 Kylix 开发的程序运行速度快。因为 Kylix 开发出来的是 native 的应用，而 Swing 速度之慢是人所共知的。 如果我开发新的 GUI 应用，肯定会选用 SWT。别跟我说 SWT 能做的界面 Swing 都能做，光是性能就足以让我做出选择了。另外 SWT 程序还可以使用 GCJ 编译为真正的 native 代码。 |
| 返回顶楼 | |
|
发表时间：2004-04-03
touchpdf 写道 关于编译出来的文件很大的问题，可以经过下面两步来处理
strip aaa.exe upx --best aaa.exe 当代活雷锋、21 世纪的北极星（抄自朝鲜某伟大领导人的称呼）Mohan Embar 同志已经把这个问题解决了。他在 3 月 20 号发布了一个新版本，里面可以对 Java 程序做动态链接。就是把 Java 核心类库单独做成一个 dll，Java 程序和核心类库做动态链接。我试验了一下，这种方式编译出来的程序做了 strip 后（gcj 加 -s 选项）就很小了，复杂一点的程序也只有几十K 左右。如果中文问题也很好地解决了话（至少也要有一个解决的方法，例如都转成 utf-8），gcj for Windows 就真正进入实用阶段了。我们写的一个读写 USB 加密棒的程序就是用 gcj 编译成 exe 后发布的，因为不想让客户另外再安装 JRE。 值得一提的是这个版本的 gcj 还可以使用 SwingWT 来编译一些 Swing 和 AWT 程序。SwingWT（http://swingwt.sourceforge.net） 就是在 SWT 之上实现的一个 Swing 兼容层。目前已经可以用 gcj 编译一些 Swing 程序了。 最新版本的 gcj 在这里下载： http://www.thisiscool.com/gcc_mingw.htm 就是：http://www.thisiscool.net/gcc34-20040320.tar.bz2 解压缩后注意看根目录下的 ReadMe.txt。 现在没时间，将来有空了编译出来一个完全 native 的 eclipse.exe 给大家玩玩。 Just for fun! 
|
| 返回顶楼 | |
