呼吁用gcj编译lumaqq

liuhj02

能否把旧版的编译一下，早日脱离jre
可参考
http://www.redhat.com/magazine/012oct05/features/java/

PoemCode

用狂热来思考问题的家伙。搞明白GCJ 和 JRE分别干什么，什么关系，再来呼吁吧。

sunmoon1997

Post by PoemCode
用狂热来思考问题的家伙。搞明白GCJ 和 JRE分别干什么，什么关系，再来呼吁吧。

那你认为是什么关系？
lumaqq 的旧版的确可以用 kaffe 运行起来[1], gcj 我也编译过, 因为 gcj 里的 classpath 比较老， lumaqq 只出来了界面但是没法用，呵呵。新版的 lumaqq 因为用到了 java 1.5 就不能运行了,
不过可以试试 ecj + classpath generic 分支, 虽然没有编译成本地代码，但是觉得性能还是可能sun jdk 的要好点。
[1].用 kaffe 运行 lumaqq 十分轻便， 内存占用大概 60M.
[2].http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath.html

sleepy

不敢非常肯定，但推测 SUN JDK 兼容性会好一点。因为 GCJ 和 Kaffe 始终都只能是跟在 SUN JDK 后面走。性能上来说，估计 GCJ 的本地编译会比 SUN JDK 好一点。但只是性能而言，希望没有伤及 Java 应用程序的功能实现。因为 1.5 和 1.4 的 Java 在某些语法上有出入，感觉 1.5 更加灵活更加方便。当然，转成字节码后就不清楚是什么回事了。不知道 GCJ 和 Kaffe 能兼容到哪个程度。所以，用于开发的话，或者保守选择的话，用 SUN JDK 会好一点。

GCJ 和 Kaffe 最糟糕的一点是没有标明版本号，也没有标明自己的版本能够对应 SUN JDK 的哪个版本，这让人很不放心。尽管应用程序第一次启动的界面出来了，但谁能保证它的稳定性和持久性呢？

使用Native Eclipse重新编译 LumaQQ 会有点难度。这首先需要把 LumaQQ 源代码项目从基于 SUN JDK的 Eclipse 上移植到基于 GCJ 的Native Eclipse上。移植过程必然会有很多麻烦事出现。假如 GCJ 不兼容 SUN JDK 1.5 的新语法的话，这样就会引起很大的麻烦。某些编码逻辑要改变，这样就不是简单的几句“用GCJ 编译”就可以解决的问题了。

sleepy

Post by sunmoon1997
那你认为是什么关系？

可能只是楼主笔误引起的误会而已。认真说来，GCJ 就是一种 JRE。所以 GCJ 和 JRE 的关系显而易见。我也不认为 LumaQQ 可以“早日”脱离JRE。

sunmoon1997

Post by sleepy
不敢非常肯定，但推测 SUN JDK 兼容性会好一点。因为 GCJ 和 Kaffe 始终都只能是跟在 SUN JDK 后面走。性能上来说，估计 GCJ 的本地编译会比 SUN JDK 好一点。但只是性能而言，希望没有伤及 Java 应用程序的功能实现。因为 1.5 和 1.4 的 Java 在某些语法上有出入，感觉 1.5 更加灵活更加方便。当然，转成字节码后就不清楚是什么回事了。不知道 GCJ 和 Kaffe 能兼容到哪个程度。所以，用于开发的话，或者保守选择的话，用 SUN JDK 会好一点。

classpath 是按照 java specification 开发的。目前主要目标是实现 java 1.4.
classpath 的 generic 分支是 java 1.5 的。

Post by sleepy

GCJ 和 Kaffe 最糟糕的一点是没有标明版本号，也没有标明自己的版本能够对应 SUN JDK 的哪个版本，这让人很不放心。尽管应用程序第一次启动的界面出来了，但谁能保证它的稳定性和持久性呢？

gcj 和 kaffe 都说明了自己是 java 1.4 的。

Post by sleepy

使用Native Eclipse重新编译 LumaQQ 会有点难度。这首先需要把 LumaQQ 源代码项目从基于 SUN JDK的 Eclipse 上移植到基于 GCJ 的Native Eclipse上。移植过程必然会有很多麻烦事出现。假如 GCJ 不兼容 SUN JDK 1.5 的新语法的话，这样就会引起很大的麻烦。某些编码逻辑要改变，这样就不是简单的几句“用GCJ 编译”就可以解决的问题了。

gcj 肯定不能编译新的 lumaqq 但是可以用 gcjx 或者 ecj 来编译。