我有偏见（是一名Python专家，但对Java却很生疏），但我认为GAE的Python运行时目前比Java运行时更先进和更好地开发-
毕竟前者还有一年的开发和成熟时间。
事情的进展当然很难预测-Java方面的需求可能会更强（尤其是因为它不仅与Java有关，而且其他语言也位于JVM之上，因此这是运行方式，例如PHP或App
Engine上的Ruby代码）；但是，Python App Engine团队的确拥有加入Python的发明者，非常强大的工程师Guido van
Rossum的优势。
在灵活性方面，如前所述，Java引擎确实提供了运行由不同语言（不仅仅是Java）制作的JVM字节码的可能性-
如果您在一家多语言商店中，那肯定是很大的。反之亦然，如果您讨厌Java脚本，但必须在用户浏览器中执行一些代码，则Java的GWT（通过Java级别的编码为您生成Java脚本）比Python端的替代方法（实际上，如果您选择）更丰富，更先进Python，您将为此自己编写一些JS，而如果您选择Java
GWT，则如果您讨厌编写JS，则可以使用它。
就库而言，这几乎是一种洗礼－
JVM受到足够的限制（没有线程，没有自定义类加载器，没有JNI，没有关系数据库），以至于妨碍了现有Java库的简单重用，甚至超过了现有Python。类似地，Python运行时的类似限制也限制了库。
在性能方面，尽管您应该以自己的任务为基准，但我认为这是一种洗礼-
不要依赖高度优化的基于JIT的JVM实现的性能，因为它们降低了启动时间和内存占用，因为应用引擎环境是非常不同的（启动成本将经常支付，因为应用程序的实例被启动，停止，移动到其他主机等）对您来说都是透明的-
Python运行时环境通常比JVM便宜得多。
叹为观止，XPath /
XSLT的情况（要委婉地说…）并不是两边都完美无缺，尽管我认为这在JVM中可能不那么糟糕（显然，可以使Saxon的实质子集运行）
，但要小心）。我认为值得在Appengine问题页面上打开标题，标题中包含XPath和XSLT
－现在只有问题需要特定的库，这是近视的：我真的不在乎如何实现良好的XPath /
XSLT，只要适用于Python和/或Java。（特定的库可能会简化现有代码的迁移，但是这比能够以某种方式执行“快速应用XSLT转换”这样的任务要重要！）。我知道如果措辞得当（尤其是以与语言无关的方式），我会盯上这样的问题。
最后但并非最不重要的一点：请记住，您可以拥有不同版本的应用程序（使用相同的数据存储），其中一些版本是通过Python运行时实现的，某些版本是通过Java运行时实现的，并且您可以访问不同于“默认/活动”的版本”带有明确的网址。因此，您可以同时使用Python
和 Java代码（在您应用的不同版本中）使用和修改同一数据存储，从而为您提供更大的灵活性（尽管只有一个拥有“ nice”
URL，例如foobar.appspot.com）我想这可能仅对交互式用户在浏览器上的访问很重要；-)。
