我正在查看运行Alfresco的JVM配置选项,主要是Alfresco Wiki上的这个文档.其中一个建议是使用JVM标志和.这样做的理由是:-Xcomp-Xbatch
如果您希望Hotspot预编译类,可以添加[-Xcomp和-Xbatch].但是,这将显着增加服务器启动时间,但会突出显示以后可能遇到的缺失依赖项.
从我在其他地方读到的关于-Xcomp和-Xbatch旗帜的内容,我想知道它们是否确实提供了任何好处.
-Xcomp 获得HotSpot以预先编译所有代码并进行最大程度的优化,从而推导出VM将通过系统的标准运行获得的任何分析.-Xbatch停止后台编译,这意味着在编译完成之前导致代码被编译的线程.但是,在编译完成后,先前阻塞的线程将不会运行已编译的代码,它仍将运行解释的代码.这是Java 6(Mustang)的一个变化 - 在Mustang之前,由于-Xbatch标志的存在而被阻止编译的线程一旦编译完成就保证在编译的代码中运行.因此,我猜测-Xbatch标志的推荐是在较旧的VM上运行Alfresco的遗留物.有人有想法吗？我倾向于摆脱这两面旗帜并依靠虚拟机来解决问题.
我想添加两件事,首先是我还没有访问Alfresco实例来测试这个,其次我不知道什么样的机器托管Alfresco而不是通过查看其他配置选项它必须是64位VM.尽管如此,我希望社区将有一些有用的输入,可能来自一般的HotSpot调整观点.
作为开发人员,我经常对可以让您的生活更轻松的新语言功能感兴趣.例如,java 5为该语言带来了泛型和注释,这些功能绝对可以提高您的工作效率.
然而,当我回顾近十年来在java平台上工作时,我发现与版本相关的问题是非生产性和不必要的努力的最大罪魁祸首.寻找正确版本的jar的小时和小时,试图协调一些版本冲突,升级依赖库等.当我开始使用java时,事情并不那么困难,你有几个第三方库,就是这样.今天,您可以轻松使用典型的Web应用程序:Spring Framework,Hibernate,Struts,您可以使用它.所有这些都带有许多依赖的第三方库.今天,我的耳档将通常包括大约40个或更多第三方库.一个真正的罐子地狱!
使用注释,我不必管理Hibernate的配置文件.一个很好的功能,但我没有看到由于我将描述符保存在单独的文件中而引起的许多问题.使用泛型,我不会编写演员语句,但在我的整个编程载体中,我记不起一个可以通过使用类型安全容器来防止的错误.版本问题的解决方案不是更有价值吗？
所有这些问题导致了许多工具,如Maven,Ivy,One Jar,Jar Jar Links(不是开玩笑!),甚至恰当地命名为Jar Hell等.即使你使用其中一些工具,你也远远不能免疫问题.我使用Maven 2,这是一个很好的帮助.不过,它本身就是一个世界.新手程序员可能需要一段时间来学习它.将您的遗留项目迁移到Maven结构也很痛苦.
似乎在.Net中他们已经学会了dll地狱的教训,并且.Net程序集的管理要简单得多.
似乎有计划为java平台和OSGI等替代方案解决这个问题.我认为非常需要一些基本的和平台强制的版本控制机制