在 Google App Engine 上选择 Java 与 Python

正如您已经指出的，使用 JVM 并不限制您使用 Java 语言。JVM 语言和链接的列表可以找到 给你。在 然而中，Google App Engine 确实限制了您可以从普通 Java SE 集中使用的类集，并且您将希望研究这些实现中的任何一个是否可以在应用程序引擎中使用。

编辑: 我看你已经找到了这样一个名单

我不能评论 Python 的性能。然而，考虑到 JVM 在运行时动态编译和优化代码的能力，它在性能方面是一个非常强大的平台。

最终，性能将取决于应用程序的功能和编码方式。由于缺乏进一步的信息，我认为不可能在这方面给予更多的指导。

基于在其他平台上运行这些虚拟机的经验，我认为您可能会从 Java 中获得比 Python 更原始的性能。然而，不要低估 Python 的卖点: Python 语言在代码行方面更有效率——大体上的共识是，Python 需要相当于 Java 程序三分之一的代码，同时保持为或更具可读性。这种优势被立即运行代码而不需要显式编译步骤的能力所乘以。

至于可用的库，您会发现许多扩展的 Python 运行时库都是开箱即用的(Java 也是如此)。AppEngine 也支持流行的 Django Web 框架(http://www.djangoproject.com/)。

关于“ power”，很难理解你的意思，但 Python 在许多不同的领域都有使用，尤其是 Web: YouTube 是用 Python 编写的，Sourceforge (截至上周)也是用 Python 编写的。

我有偏见(作为一名 Python 专家，但对 Java 已经相当生疏) ，但我认为 GAE 的 Python 运行时目前比 Java 运行时更先进、开发得更好——毕竟，前者还有一年的时间来开发和成熟。

事情将如何发展当然很难预测—— Java 方面的需求可能更强(特别是因为它不仅仅是关于 Java，还有其他位于 JVM 之上的语言，所以这是在 App Engine 上运行 PHP 或 Ruby 代码的方式) ，然而 Python App Engine 团队的优势在于拥有吉多·范罗苏姆，Python 的发明者和一个惊人的强大的工程师。

就灵活性而言，正如前面提到的，Java 引擎确实提供了运行由不同语言生成的 JVM 字节码的可能性，而不仅仅是 Java ——如果你在一个多语言商店，这是一个相当大的积极因素。反之亦然，如果你讨厌 Javascript 但必须在用户的浏览器中执行一些代码，那么 Java 的 GWT (通过 Java 级别的代码为你生成 Javascript)比 Python 方面的代码更丰富、更先进(实际上，如果你选择 Python，你就会为此目的自己编写一些 JS，而如果你选择 Java GWT，如果你讨厌编写 JS，那么它是一个可用的替代品)。

就库而言，它几乎是一种清洗—— JVM 受到了足够的限制(没有线程、没有自定义类加载器、没有 JNI、没有关系数据库) ，阻碍了现有 Java 库的简单重用，其程度不亚于现有 Python 库受到 Python 运行时类似限制的程度。

在性能方面，我认为这是一个洗涤，虽然你应该基准测试你自己的任务-不要依赖于高度优化的基于 JIT 的 JVM 实现的性能折扣他们的大启动时间和内存占用，因为应用引擎环境是非常不同的(启动成本将经常支付，因为你的应用实例被启动，停止，移动到不同的主机，等等，所有这些对你来说都是显而易见的-这些事件在 Python 运行时环境中通常比在 JVM 中便宜得多)。

XPath/XSLT 的情况(委婉地说... ...)在任何一方都不是完美的，唉，不过我认为在 JVM 中可能没那么糟糕(显然，在 JVM 中，可以小心地运行大量的 Saxon 子集)。我认为值得在 Appengine 问题页面上用 XPath 和 XSLT 作为标题——现在只有要求特定库的问题，这是目光短浅的: 我并不真正关心一个好的 XPath/XSLT 是如何实现的，对于 Python 和/或 Java，只要我能使用它。(特定的库可以简化现有代码的迁移，但是这不如能够以某种方式执行诸如“快速应用 XSLT 转换”之类的任务重要！-).我知道，如果措辞得当(特别是以一种独立于语言的方式) ，我会主演这样一个问题。

最后但并非最不重要的: 记住你可以有不同版本的应用程序(使用相同的数据存储) ，其中一些是用 Python 运行时实现的，一些是用 Java 运行时实现的，你可以访问不同于“默认/活动”版本的显式 URL。因此，你可以让 Python abc 0 Java 代码(在你的应用程序的不同版本中)使用和修改同一个数据存储，赋予你更大的灵活性(尽管只有一个具有“好的”URL，比如 foobar.appspot.com ——我想这可能只对浏览器上的交互式用户访问很重要; ——)。

我强烈推荐 Java 用于 GAE，原因如下:

1. 性能: Java 可能比 Python 更快。
2. Python 开发面临着缺乏第三方库的压力。例如，根本没有针对 Python/GAE 的 XSLT。几乎所有的 Python 库都是 C 绑定(GAE 不支持这些绑定)。
3. Memcache API: JavaSDK 比 PythonSDK 有更多有趣的功能。
4. 数据存储 API: JDO 非常慢，但是本地 Java 数据存储 API 非常快速和简单。

我现在正在开发中使用 Java/GAE。

还有一个 卸货燕子项目，显然是谷歌资助的，如果不是谷歌所有的。他们正在尝试为 Python 2.6.1字节码实现一个基于 LLVM 的后端，这样他们就可以使用一个 JIT 和各种不错的本地代码/GC/多核优化。(引用的不错: “我们渴望不做原创性的工作，而是尽可能多地利用过去30年的研究成果。”)他们正在寻找一个5倍加速到 CPython。

当然，这并不能回答你的直接问题，但指向了未来(希望如此)“差距的缩小”(如果有的话)。

尽管 GWT 看起来与我正在开发的应用程序非常匹配，但是 Python 已经过时了。JPA 在 GAE 上非常混乱(例如，没有@Embeddable 和其他模糊的非文档化限制)。花了一个星期的时间，我发现 Java 在 GAE 上感觉不太对劲。

观察这个应用程序在 Python 和 Java 性能方面的变化:

Http://gaejava.appspot.com/ (编辑: 对不起，链接现在中断。但下面的段落仍然适用，当我看到它运行最后)

目前，Python 和在 Java 中使用低级 API 比 JDO on Java，这个简单的测试更快。至少如果底层引擎发生变化，应用程序应该反映性能的变化。

现在 Python 的美妙之处在于它能很好地与其他语言进行交流。例如，可以将 python 和 java 与 Jython 放在同一个表上。当然，jython 尽管完全支持 java 库，但它不支持完全的 python 库。但是，如果您想要扰乱 Java 库，那么这是一个理想的解决方案。它甚至允许您将其与 Java 代码混合使用，而不需要额外的编码。

但即使是蟒蛇本身也取得了一些进展。参见例如 ctype，接近 C 语言的速度，直接访问 C 库，而不用离开 Python 编码的舒适性。Cython 更进一步，允许轻松地混合 c 代码和 python 代码，或者即使你不想搞乱 c 或 c + + ，你仍然可以使用 python 代码，但是使用静态类型变量使你的 python 程序像 C 应用程序一样快。Cython 被 google 使用和支持。

昨天，我甚至找到了可以让 python 内联到 C 甚至 Assembly 的工具(参见 CorePy) ，你不可能比它更强大了。

Python 无疑是一种非常成熟的语言，不仅能够独立运行，而且能够轻松地与任何其他语言进行合作。我认为这就是为什么 Python 是一个理想的解决方案，即使是在一个非常高级和苛刻的场景中。

使用 python，您可以访问 C/C + + 、 Java、。NET 和许多其他库几乎没有额外的编码，也给你一种语言，最小化，简化和美化编码。这是一种非常诱人的语言。

在选择 Python 和 Java 时需要考虑的一个重要问题是 你将如何使用每种语言的数据存储(本主题已经很好地涵盖了原始问题的大多数其他角度)。

对于 Java ，标准方法是使用 JDO 或 JPA。这些对于可移植性非常有用，但是不太适合数据存储。

一个低级别的 API 是可用的，但是对于日常使用来说这个级别太低了——它更适合于构建第三方库。

对于 Python ，有一个专门设计的 API，可以为应用程序提供对数据存储的简单而强大的访问。它很棒，只是它不可移植，所以它将您锁定到 GAE 中。

幸运的是，正在针对这两种语言列出的弱点开发解决方案。

For Java, the low-level API is being used to develop persistence libraries that are much better suited to the datastore then JDO/JPA (IMO). Examples include the 锡耶纳项目, and 物化.

我最近开始使用 Objectify，发现它非常容易使用，并且非常适合数据存储，它的日益流行已经转化为良好的支持。例如，Objectify 得到了 Google 新的云端点服务的官方支持。另一方面，Objectify 只与数据存储一起工作，而 Siena 受到数据存储的“启发”，但被设计用于与各种 SQL 数据库和 NoSQL 数据存储一起工作。

对于 Python ，正在努力允许在 GAE 之外使用 Python GAE 数据存储 API。一个例子就是 Google 发布的与 SDK 一起使用的 SQLite 后端，但我怀疑他们是否打算将其发展成为可以投入生产的产品。台风 AE项目可能有更多的潜力，但我不认为它是生产准备还没有(纠正我，如果我错了)。

如果任何人有任何这些选择的经验或知道其他人，请添加他们在一个评论。就我个人而言，我非常喜欢 GAE 数据存储——我发现它比 AWS SimpleDB 有了很大的改进——所以我希望这些努力能够成功，以减轻使用它时的一些问题。

这是一个很好的问题，我认为很多回答都给出了正反两方面的观点。我尝试了 Python 和基于 JVM 的 AppEngine (在我的案例中，我使用的是为 AppEngine 构建的 Groovy 应用程序框架 Gaelyk)。当涉及到平台上的性能时，有一件事我一直没有考虑到，直到它出现在我面前，那就是“加载请求”的含义，它发生在围墙的 Java 一侧。在使用 Groovy 时，这些加载请求是一个杀手。

我写了一篇关于这个主题的文章(http://distractable.net/coding/google-appengine-java-vs-python-performance-comparison/) ，希望能找到解决这个问题的方法，但是如果没有的话，我想我会回到 Python + Django 的组合，直到冷启动 Java 请求的影响减小。

与 Python 用户相比，我听到很多 Java 用户抱怨 AppEngine，我认为 Python 的使用压力要小得多。

我对 Python/Django SDK 的简洁、直观和无问题感到惊讶。然而，我开始遇到这样的情况，我需要开始做更多的 JavaScript，并认为我可能想利用 GWT 和其他 Java 实用程序。我只学习了 GAE Java 教程的一半，就遇到了一个又一个的问题: Eclipse 配置问题、 JRE 版本问题、 Java 令人头脑麻木的复杂性，以及一个令人困惑且可能已经破碎的教程。查看这个网站和其他链接从这里为我确定了它。我将继续使用 Python，并且将研究睡衣以帮助解决 JavaScript 挑战。

一个需要考虑的因素是你打算使用的框架。并非所有 Java 端的框架都非常适合运行在 AppEngine 上的应用程序，这与传统的 Java 应用程序服务器有些不同。

需要考虑的一件事是应用程序启动时间。对于传统的 Java 网络应用程序，你不需要考虑这个问题。应用程序启动，然后运行。启动时间是5秒钟还是几分钟并不重要。使用 AppEngine 时，您可能最终会遇到这样的情况，即只有在请求进入时才启动应用程序。这意味着用户正在等待应用程序启动。像保留实例这样的新 GAE 特性在这里有所帮助，但请先检查。

另一个问题是 GAE psoes 对 Java 的不同限制。并不是所有的框架都满意您可以使用的类的限制，或者不允许线程或者不能访问本地文件系统。这些问题可能很容易发现，只需要搜索一下 GAE 兼容性。

我还看到一些人抱怨现代 UI 框架(即 Wicket)中的会话大小问题。一般来说，这些框架倾向于进行某些权衡，以使开发变得有趣、快速和简单。有时这可能会导致与 AppEngine 限制冲突。

我最初开始使用 Java 开发 GAE，但后来因为这些原因转而使用 Python。我的 个人感情是 Python 是 AppEngine 开发的一个更好的选择。我认为 Java 更像是“在家里”，比如在亚马逊的 ElasticBeanstalk 上。

但是随着 App Engine 的发展，事情变化得非常快。GAE 正在改变自己，随着它变得越来越流行，框架也在改变以克服其局限性。