[这是一个关于最先进技术的经验性问题：我不是在问 Java 是否比在 JVM 中工作的动态语言更酷或更不酷。]
除了性能是主要决定因素的情况之外，公司/开发人员是否仍然愿意选择 Java 而不是 Groovy、JRuby 或 Jython？
编辑：如果答案是“是”，为什么？
个人注意：我问的原因是，虽然我在 Ruby（目前不是 JRuby）中完成了我的专业工作的一部分，但在我的个人项目中，我使用 Java。虽然我用 Groovy 编写了重要的应用程序，但我更喜欢 Java，但我想知道我是否应该克服它并用 Groovy 做所有事情。我喜欢 Java，因为我觉得静态类型可以节省我的时间并有助于重构。（不，我不熟悉 Scala。）但是，我觉得这个非常经验性的、主题性的编程问题可能会影响我的决定。
静态类型仍然是一件大事。
尽管已经反复争论，动态方法的支持者说动态类型带来的问题可以通过足够的单元测试来减少（甚至消除）。
我不想争论这个论点是否正确，所以我假设它是正确的，对于这个答案。
在这种情况下，仍然存在一个问题，那就是许多商店没有程序/技术/规则/管理来生产足够数量的高质量单元测试。
如果我必须在没有单元测试的动态类型代码和没有单元测试的静态类型代码之间进行选择，我每天都会选择静态类型代码。
双重调度也存在类似的问题：
在 Groovy 中，方法调用是根据运行时参数的实际类型分派的（这几乎是必需的，因为静态类型是未知的和/或Object大多数情况下）。这意味着当面对可扩展的类层次结构时，没有可靠的方法可以知道在代码的任何给定点调用了哪个方法。
foo(String)大部分时间调用带有签名的方法的任何代码都可能突然调用foo(Integer)或foo(SomethingElseEntirely)仅取决于运行时参数的实际类型。在 Java 语言中这永远不会发生，因为要调用的方法的确切签名是在编译时决定的。
就像其他“动态”语言特性一样，双重分派有时是一个非常有用的工具，缺少它会在 Java 中产生一些丑陋的结构，但它的代价是它使阅读、理解和推理代码变得更加困难.
非静态类型语言在维护意义上不能很好地“扩展”。它们可以维护多达几万行代码。过去，他们只是花更多的精力来维护、重构或更新。这适用于任何非静态类型语言，Perl、Python、Groovy、Ruby 等。用于处理 50 万行 Python 代码与 C/C++/Java 中相同数量的代码行的工具只是不在那里。现在确实，Python 的代码行数大约是等效 Java 程序的 1/3 到 1/5。所以这永远不会是苹果和橘子，但有一个分界点，即非静态语言中的代码行数在维护方面的回报会递减。并且每个人都知道，维护是软件项目的真正成本一直存在的地方。
是的，很明显。
为什么公司仍然“心甘情愿”地使用 Java？
因为公司本质上是保守的。他们不会改变技术，因为它们很酷，甚至很时髦。当有一个谨慎的理由时，他们会不情愿地改变。早期采用者会因为成为早期采用者而付出非常沉重的代价。
编辑：这不是贬义意义上的“惯性”，如“除了抵制改变之外没有理由避免改变”，而是审慎意义上的。公司不放弃有效的方法是正确的，直到出现可证明更好的方法。
而不是“让开发人员高兴，因为它很酷”的感觉更好，而是更快、更可靠地满足推动组织发展的任何业务需求。
Java 提供：
大量训练有素、经验丰富的开发人员。很难找到能够很好地进行软件开发的人，而不是选择一种不存在那么久的语言。用新语言培训人们在时间和金钱上都是昂贵的。
品牌知名度和成功完成项目的轻松证明记录。这没什么好嘲笑的：如果我告诉上层管理人员我正在用一种他们从未听说过的时髦的新语言开始一个项目，我必须对他们进行教育，他们会认为这是一种风险。使用任何“既定”语言，我都可以跳过这一步。
完善、成熟的支持工具和第三方支持。
这些优势来自于历史悠久的语言与新语言之间的任何比较，而不仅仅是 Java 和您的列表。我希望有一天，Groovy 等人会成为既定的语言，并且会有人问同样的问题关于一些更新的、更闪亮的语言。这就是循环。这就是我从事该行业的时间更长的情况。
除了性能是主要决定因素的情况之外，公司/开发人员是否仍然愿意选择 Java 而不是 Groovy、JRuby 或 JPython？
是的，我认为主要原因是开发者或公司的惰性：
缺乏可用资源可能是另一个原因，尽管这是一个先有鸡还是先有蛋的问题（或墨西哥的对峙，或自我实现的预言，或其他什么）。我想有很多公司都在关注 Groovy、Jython 等，但要等待它们被更广泛地采用，然后再冒险尝试。显然，通过推迟采用本身，他们正在加剧这种缺乏资源的问题。
个人旁白
去年我是一名 Groovy/Grails 开发人员。我最近换了工作，现在是一名 Java 1.4 开发人员，（与 Groovy 编程相比）这就像用生锈的勺子挖出你的眼睛一样令人愉快。
静态类型非常棒，因为它有助于编译时检查和代码分析工具，如 FindBugs，但它无法弥补编写 Java 时完成最简单任务所需的大量（样板）代码（特别是如果你'重新使用早于 1.5 的版本）。
我可以告诉你我公司的情况。我们当前的应用程序是用 java 完成的，但我们已经开始向 grails/groovy 过渡，这很可能是我们下一代产品的平台。
既然你问的是一个经验问题，我假设寻找经验答案：
除了性能是主要决定因素的情况之外，公司/开发人员是否仍然愿意选择 Java 而不是 Groovy、JRuby 或 JPython？
是的。
我不认为还有什么可说的。