google closure js压缩器编译为本地码可执行文件的尝试

阅读更多

最近 @定球呀球 抱怨说 google closure 作为 java 命令行应用启动速度暴慢,什么都不做运行一次也要 1s 多,有大量 js 文件要处理时为每个文件都运行一次是要死人的。想起 gcj 作为 gcc 的 java 前端是可以将 java 代码编译为本地码执行的,于是好奇地尝试了一把,过程如下,较为曲折……

 

  1. 首先要 patch google closure 源码。由于 gcj 及其整合的 gnu classpath 基础类库实现目前只支持 java 5 的部分特征,所以先要把源码中不支持的部分绕过去。补丁见附件,下载至 google closure 源码根目录并 patch < closure-gcj.patch 即可。主要的修改点为:去除命令行解析逻辑中 gcj 不支持的 annotation 语法;从 OpenJDK 中补充了 gnu classpath 未实现的正则转义方法 Pattern.quote();去除了 gnu classpath 未实现的 Math.copySign() 方法
  2. 原来的命令行解析逻辑不能用了,只好增加一个简单的命令行启动入口类,见附件中的 NativeRunner.java,将其放置到 google closure 源码目录中的 src/com/google/javascript/jscomp/ 子目录中
  3. 在 google closure 源码目录中执行 ant 重新编译打包,拿到 build/ 子目录中的结果 compiler.jar
  4. 用如下 gcj 命令行将 compiler.jar 转换为本地码可执行文件:
gcj -findirect-dispatch --main=com.google.javascript.jscomp.NativeRunner -o closure compiler.jar -Wl,-Bsymbolic

 

最后编译出的可执行文件约 33MB 大,但测试后大失所望,和直接用 java -jar 启动速度相差无几,运行速度还慢了几乎 50%,估计是因为 gcj 还利用不了 gcc 4.6 新的 SSA 优化链的缘故吧,不过本来对 java 来说,稍有利用动态特性的地方 AOT 编译器就要大费周张地搞复杂的机制来兼容,很难赶上 JIT 编译生成代码的紧凑程度了。

 

话说回来,若你的 java 程序基本上是 java 1.4 兼容的,且没有使用太多动态特性,想在 C/C++ 程序中复用这些代码,那么 gcj 编译应该是最理想的解决方案了吧,呵呵。

 

  • NativeRunner.java.gz (172 Bytes)
  • 下载次数: 3
  • closure-gcj.patch.gz (4.8 KB)
  • 下载次数: 2

你可能感兴趣的:(google closure js压缩器编译为本地码可执行文件的尝试)