使用GCJ发布服务器端应用程序真的可行吗? WEBAPPS?
我的老板确信将我们的( 我的 )webapp编译成二进制可执行文件是一个绝妙的主意。 (然后,他再次喜欢用他能理解的眨眼灯光的漂亮,小巧的简单事物。)他本能地认为没有问题,而我只能看到无穷无尽的一系列问题和退化。有一次我开始和他讨论我们平台的复杂性,以及更深入的字节代码,JVM,库,操作系统之间的差异,处理器架构等......嗯......他的眼睛茫然,他微笑着他已经明确表示他认为我是幼稚的抵抗力。
为什么他想要一个神奇的可执行文件?他看到了几个“好处”:
所以,我已经完成了20分钟的谷歌搜索,现在我在这里。
我申请的一些背景知识:
它是由什么构成的:
它的作用
正如您可能会收集到的那样,我对此“将Java编译为本机代码”的事情持高度怀疑态度。这听起来像是Mono(Linux上的VB)早在2000年。但我是否过于悲观?它可行吗?我是否应该花时间(几天甚至几周)来试试呢?
还有一个类似的线程(Java Compiler Options to produce .exe files),但它有点过于简单,链接过时了,并没有真正针对服务器端问题。
亲爱的SOpedians,您的知情意见将受到高度重视! TIA!
答案 0 :(得分:6)
我不知道GCJ,但我公司成功使用Excelsior JET。我们还没有使用webapp(但是)它应该能够处理Sun JRE可以处理的任何事情。事实上,JET是Sun认证的Java实现。
答案 1 :(得分:4)
FWIW:我从来没有和GCJ好运,我在使用它时遇到了很多问题并且有一些模糊不清的问题突然出现,需要永远诊断GCJ而不是我(我总是非常不愿意责备外部图书馆的事情)。我会公开承认这是几年前发生的事情,我再也不想再去GCJ了。为了给出更多实质内容,这是在我上学的时候,正在开展一项非常简单的计划,所以在“企业层面”我对GCJ有一种健康的恐惧。
答案 2 :(得分:3)
Excelsior JET是明确的答案
答案 3 :(得分:2)
有一个可执行文件有一些缺点:
如果他想要一些简单的东西,也许战争或耳朵会更好。我认为这样做没有任何好处 - 我认为可能是有益的,因为它是您分发的独立应用程序,以便人们可以双击它。
答案 4 :(得分:0)
我只是简单地使用了GCJ,并很快转移到了Sun的JDK。我看到的主要问题是GCJ似乎总是落后于Sun的JDK的最新版本,并且由于与Sun的JDK的细微差别而导致奇怪的神秘错误。在版本1.5(被认为与Sun的v1.5兼容)中,我在使用泛型编译时遇到了问题,最后放弃并转移到了Sun的JDK。
我必须说,性能上的任何差异都可以忽略不计(就我的目的而言,YMMV),实际上安装问题的解决方案是为您的应用创建一个安装程序。逆向工程二进制文件并不比反向工程字节码更难。如果它很重要,请使用混淆器。
总的来说,我认为使用GCJ所涉及的兼容性问题大大超过了你可能从中获得的任何收益(我认为最好的问题)。尝试在gcj中编译应用程序的各个部分,看看它是如何进行的。如果它运作得很好,否则你会得到一些可靠的东西给你的老板。
答案 5 :(得分:0)
编译为本机代码可能会使您的应用程序性能提升并使用更少的内存,因此如果可以使其工作,那么竞争方面的业务就会有优势。
能够更好地支持应用程序对业务也有好处。
因此,考虑到baring是值得考虑的,没有什么比不起作用的应用程序更快地失去客户。
您需要适当的项目时间来尝试这一点,并且客户知道他们正在接受什么,愿意让它旋转(更难找到)。
答案 6 :(得分:-1)
我认为像你这样的大型应用程序不会编译成机器代码。请记住,java不仅是java语法(可能编译为机器代码),而且还是一个更像应用程序/进程环境的虚拟机。我建议改为uberjar或者喜欢这样做。
答案 7 :(得分:-1)
也许你的老板只需要一个演示来说明在自己的应用服务器上为客户分发和部署war文件是多么容易。每个文件都是“二进制”的,所以你可能认为他在命令行中是一个可执行文件太过于字面化。