我有偏见(作为Python专家,但在Java中相当生锈),但我认为GAE的Python运行时目前比Java运行时更先进,开发得更好 - 毕竟前者还有一年的时间来开发和成熟。
当然,事情将如何发展是很难预测的 - Java方面的需求可能更强(特别是因为它不仅仅是关于Java,而且其他语言也栖息在JVM之上,所以这是运行的方式,例如.PHP或App Engine上的Ruby代码);然而,Python App Engine团队确实具有拥有Guido van Rossum的优势,Guido van Rossum是Python的发明者和一位非常强大的工程师。
在灵活性方面,如前所述,Java引擎确实提供了运行由不同语言制作的JVM字节码的可能性,而不仅仅是Java - 如果你在一个多语言商店,这是一个相当大的积极因素。反之亦然,如果你讨厌Javascript,但必须在用户的浏览器中执行一些代码,Java的GWT(从你的Java级编码中为你生成Javascript)比Python端的替代品更丰富,更高级(在实践中,如果你选择Python,你将为此目的自己编写一些JS,而如果你选择Java GWT,如果你讨厌编写JS,它是一个可用的替代方案)。
就库而言,这几乎是一种洗涤 - JVM受到足够的限制(没有线程,没有自定义类加载器,没有JNI,没有关系数据库),阻碍了现有Java库的简单重用,就像现有的Python库同样受到Python运行时的类似限制一样多或更多。
在性能方面,我认为这是一个洗涤,尽管您应该对自己的任务进行基准测试 - 不要依赖于高度优化的基于JIT的JVM实现的性能来减少其较大的启动时间和内存占用量,因为应用程序引擎环境非常不同(启动成本将经常支付,因为您的应用程序实例启动, 停止,移动到不同的主机,等等,所有这些都是跟踪你的 - 这样的事件通常比使用JVM便宜得多。
叹息,XPath/XSLT的情况(委婉地说......)在任何一方都不是完全完美的,尽管我认为在JVM中它可能不那么糟糕(显然,撒克逊人的大量子集可以运行,只要小心)。我认为值得在 Appengine Issues 页面上打开一些问题,在他们的标题中使用 XPath 和 XSLT - 现在只有问题要求特定的库,这是短视的:我真的不在乎一个好的 XPath/XSLT 是如何实现的,对于 Python 和/或 Java,只要我能使用它。(特定的库可以简化现有代码的迁移,但这不如能够以某种方式执行诸如“快速应用 XSLT 转换”之类的任务重要!我知道如果措辞得当(特别是以一种与语言无关的方式),我会把这样一个问题放在首位。
最后但并非最不重要的一点是:请记住,您可以拥有不同版本的应用程序(使用相同的数据存储),其中一些是使用Python运行时实现的,有些是使用Java运行时实现的,并且您可以使用显式URL访问与“默认/活动”版本不同的版本。因此,您可以让Python和Java代码(在应用程序的不同版本中)使用和修改相同的数据存储,从而为您提供更大的灵活性(尽管只有一个具有“好”的URL,例如 foobar.appspot.com - 我想这可能只对浏览器上的交互式用户访问很重要;-)。