在Google App Engine上选择Java vs Python

我有偏见（是一名Python专家，但对Java却很生疏），但我认为GAE的Python运行时目前比Java运行时更先进和更好地开发-毕竟前者还有一年多的开发和成熟时间。

事情的进展当然很难预测-Java方面的需求可能会更强（尤其是因为它不仅与Java有关，而且其他语言也位于JVM之上，因此这是运行方式，例如PHP或App Engine上的Ruby代码）；但是，Python App Engine团队的确具有加入Python的发明者，非常强大的工程师Guido van Rossum的优势。

在灵活性方面，如前所述，Java引擎确实提供了运行由不同语言（不仅是Java）制作的JVM字节码的可能性-如果您在一家多语言商店中，那肯定是很大的。反之亦然，如果您讨厌Javascript但必须在用户的浏览器中执行一些代码，则Java的GWT（从Java级编码为您生成Javascript）比Python端的替代方法更丰富和更先进（实际上，如果您选择Python，您将为此自己编写一些JS，而如果您选择Java GWT，则如果您讨厌编写JS，则可以使用它。

就库而言，这几乎是一种洗礼－ JVM受到足够的限制（没有线程，没有自定义类加载器，没有JNI，没有关系数据库），以至于与现有Python相比，现有Java库的简单重用受到了更多的干扰。类似地，Python运行时的类似限制也限制了库。

就性能而言，尽管您应该以自己的任务为基准，但我认为这是一次洗礼-不要依赖高度优化的基于JIT的JVM实现的性能，因为它们降低了启动时间和内存占用，因为应用引擎环境是非常不同的（启动成本将经常支付，因为您的应用程序实例被启动，停止，移动到其他主机等）对您来说都是透明的-与Python相比，使用Python运行时环境这些事件通常要便宜得多。

叹为观止，XPath / XSLT的情况（实际上是委婉的...）并不是两边都完美无缺，尽管我认为这在JVM中可能会稍微好一些（显然，可以使Saxon的大部分子集可以运行） ，但要小心）。我认为值得在Appengine问题页面上打开标题，标题中包含XPath和XSLT；现在只有问题要求特定的库，这是近视的：我真的不在乎如何实现良好的XPath / XSLT，只要适用于Python和/或Java。（特定的库可能会简化现有代码的迁移，但这比能够以某种方式执行“快速应用XSLT转换”这样的任务要重要！）。我知道如果措辞得当（尤其是以与语言无关的方式），我会盯上这样的问题。

最后但并非最不重要的一点：请记住，您可以拥有不同版本的应用程序（使用相同的数据存储），其中一些版本是通过Python运行时实现的，某些版本是通过Java运行时实现的，并且您可以访问不同于“默认/活动”的版本”带有明确的网址。因此，您可以同时使用Python 和 Java代码（在应用的不同版本中）使用和修改相同的数据存储，从而为您提供更大的灵活性（尽管只有一个拥有“ nice” URL，例如foobar.appspot.com）我想这可能仅对交互式用户在浏览器上的访问很重要；-)。