在 Google App Engine 上选择 Java 还是 Python

Choosing Java vs Python on Google App Engine

提问by Viet

Currently Google App Engine supports both Python & Java. Java support is less mature. However, Java seems to have a longer list of libraries and especially support for Java bytecode regardless of the languages used to write that code. Which language will give better performance and more power? Please advise. Thank you!

目前 Google App Engine 支持 Python 和 Java。Java 支持不太成熟。然而，Java 似乎有更长的库列表，尤其是对 Java 字节码的支持，而不管用于编写该代码的语言如何。哪种语言会提供更好的性能和更强大的功能？请指教。谢谢！

Edit:http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1

编辑：http : //groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1

Edit:By "power" I mean better expandability and inclusion of available libraries outside the framework. Python allows only pure Python libraries, though.

编辑：“强大”是指更好的可扩展性和包含框架之外的可用库。不过，Python 只允许使用纯 Python 库。

采纳答案by Alex Martelli

I'm biased (being a Python expert but pretty rusty in Java) but I think the Python runtime of GAE is currently more advanced and better developed than the Java runtime -- the former has had one extra year to develop and mature, after all.

我有偏见（我是 Python 专家，但在 Java 方面相当生疏）但我认为 GAE 的 Python 运行时目前比 Java 运行时更先进，开发得更好——毕竟前者还有一年多的时间来开发和成熟.

How things will proceed going forward is of course hard to predict -- demand is probably stronger on the Java side (especially since it's not just about Java, but other languages perched on top of the JVM too, so it's THE way to run e.g. PHP or Ruby code on App Engine); the Python App Engine team however does have the advantage of having on board Guido van Rossum, the inventor of Python and an amazingly strong engineer.

事情将如何发展当然很难预测——Java 方面的需求可能更强劲（特别是因为它不仅与 Java 有关，而且其他语言也位于 JVM 之上，所以它是运行例如 PHP 的方式或 App Engine 上的 Ruby 代码）；然而，Python App Engine 团队的优势在于拥有 Python 的发明者和非常强大的工程师 Guido van Rossum。

In terms of flexibility, the Java engine, as already mentioned, does offer the possibility of running JVM bytecode made by different languages, not just Java -- if you're in a multi-language shop that's a pretty large positive. Vice versa, if you loathe Javascript but must execute some code in the user's browser, Java's GWT (generating the Javascript for you from your Java-level coding) is far richer and more advanced than Python-side alternatives (in practice, if you choose Python, you'll be writing some JS yourself for this purpose, while if you choose Java GWT is a usable alternative if you loathe writing JS).

在灵活性方面，如前所述，Java 引擎确实提供了运行由不同语言生成的 JVM 字节码的可能性，而不仅仅是 Java —— 如果您在多语言商店中，这是一个很大的积极因素。反之亦然，如果你讨厌 Javascript 但必须在用户的浏览器中执行一些代码，Java 的 GWT（从你的 Java 级编码为你生成 Javascript）比 Python 端的替代品（实际上，如果你选择Python，您将为此目的自己编写一些 JS，而如果您选择 Java，如果您讨厌编写 JS，GWT 是一个可用的替代方案）。

In terms of libraries it's pretty much a wash -- the JVM is restricted enough (no threads, no custom class loaders, no JNI, no relational DB) to hamper the simple reuse of existing Java libraries as much, or more, than existing Python libraries are similarly hampered by the similar restrictions on the Python runtime.

就库而言，这几乎是一种洗礼——JVM 受到足够的限制（没有线程、没有自定义类加载器、没有 JNI、没有关系数据库），阻碍了对现有 Java 库的简单重用与现有 Python 一样多，甚至更多库同样受到 Python 运行时类似限制的阻碍。

In terms of performance, I think it's a wash, though you should benchmark on tasks of your own -- don't rely on the performance of highly optimized JIT-based JVM implementations discounting their large startup times and memory footprints, because the app engine environment is very different (startup costs will be paid often, as instances of your app are started, stopped, moved to different hosts, etc, all trasparently to you -- such events are typically much cheaper with Python runtime environments than with JVMs).

在性能方面，我认为这是一种洗礼，尽管您应该对自己的任务进行基准测试——不要依赖高度优化的基于 JIT 的 JVM 实现的性能，而忽略它们的大启动时间和内存占用，因为应用程序引擎环境非常不同（启动成本将经常支付，因为您的应用程序实例的启动、停止、移动到不同的主机等，对您来说都是透明的——这些事件在 Python 运行时环境中通常比在 JVM 中便宜得多）。

The XPath/XSLT situation (to be euphemistic...) is not exactly perfect on either side, sigh, though I think it may be a tad less bad in the JVM (where, apparently, substantial subsets of Saxon can be made to run, with some care). I think it's worth opening issues on the Appengine Issuespage with XPath and XSLT in their titles -- right now there are only issues asking for specific libraries, and that's myopic: I don't really care HOW a good XPath/XSLT is implemented, for Python and/or for Java, as long as I get to use it. (Specific libraries may ease migration of existing code, but that's less important than being able to perform such tasks as "rapidly apply XSLT transformation" in SOME way!-). I know I'd star such an issue if well phrased (especially in a language-independent way).

XPath/XSLT 情况（委婉地说......）在任何一方都不完全完美，叹息，尽管我认为它在 JVM 中可能不那么糟糕（显然，可以使 Saxon 的大量子集运行，小心点）。我认为值得在Appengine 问题页面上打开标题中包含 XPath 和 XSLT 的问题——现在只有要求特定库的问题，这是短视的：我真的不在乎一个好的 XPath/XSLT 是如何实现的，对于 Python 和/或 Java，只要我开始使用它。（特定的库可能会简化现有代码的迁移，但这不如能够以某种方式执行“快速应用 XSLT 转换”之类的任务重要！-）。我知道如果措辞得当（尤其是在与语言无关的方式下），我会为这样的问题加注星标。

Last but not least: remember that you can have different version of your app (using the same datastore) some of which are implemented with the Python runtime, some with the Java runtime, and you can access versions that differ from the "default/active" one with explicit URLs. So you could have both Python andJava code (in different versions of your app) use and modify the same data store, granting you even more flexibility (though only one will have the "nice" URL such as foobar.appspot.com -- which is probably important only for access by interactive users on browsers, I imagine;-).

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

回答by Brian Agnew

As you've identified, using a JVM doesn't restrict you to using the Java language. A list of JVM languages and links can be found here. However, the Google App Engine does restrict the set of classes you can use from the normal Java SE set, and you will want to investigate if any of these implementations can be used on the app engine.

正如您所确定的，使用 JVM 并不限制您使用 Java 语言。可以在此处找到 JVM 语言和链接的列表。但是，Google App Engine 确实限制了您可以从普通 Java SE 集中使用的类集，您需要调查是否可以在应用引擎上使用这些实现中的任何一个。

EDIT: I see you've found such a list

编辑：我看到你找到了这样一个列表

I can't comment on the performance of Python. However, the JVM is a very powerful platform performance-wise, given its ability to dynamically compile and optimise code during the run time.

我无法评论 Python 的性能。然而，JVM 在性能方面是一个非常强大的平台，因为它能够在运行时动态编译和优化代码。

Ultimately performance will depend on what your application does, and how you code it. In the absence of further info, I think it's not possible to give any more pointers in this area.

最终性能将取决于您的应用程序的功能以及您如何对其进行编码。在没有更多信息的情况下，我认为不可能在这方面提供更多指示。

回答by Judy2K

Based on experience with running these VMs on other platforms, I'd say that you'll probably get more raw performance out of Java than Python. Don't underestimate Python's selling points, however: The Python language is much more productive in terms of lines of code - the general agreement is that Python requires a third of the code of an equivalent Java program, while remaining as or more readable. This benefit is multiplied by the ability to run code immediately without an explicit compile step.

根据在其他平台上运行这些 VM 的经验，我认为您可能会从 Java 中获得比 Python 更多的原始性能。然而，不要低估 Python 的卖点：Python 语言在代码行方面的效率要高得多——普遍的共识是 Python 需要等效 Java 程序代码的三分之一，同时保持其可读性或更高的可读性。无需显式编译步骤即可立即运行代码的能力使这一优势倍增。

With regards to available libraries, you'll find that much of the extensive Python runtime library works out of the box (as does Java's). The popular Django Web framework (http://www.djangoproject.com/) is also supported on AppEngine.

关于可用的库，您会发现很多广泛的 Python 运行时库都是开箱即用的（Java 也是如此）。AppEngine 还支持流行的 Django Web 框架 ( http://www.djangoproject.com/)。

With regards to 'power', it's difficult to know what you mean, but Python is used in many different domains, especially the Web: YouTube is written in Python, as is Sourceforge (as of last week).

关于“权力”，很难理解您的意思，但是 Python 用于许多不同的领域，尤其是 Web：YouTube 是用 Python 编写的，Sourceforge 也是如此（截至上周）。

回答by Paul

I'm strongly recommending Java for GAE and here's why:

我强烈建议将 Java 用于 GAE，原因如下：

1. Performance: Java is potentially faster then Python.
2. Python development is under pressure of a lack of third-party libraries. For example, there is no XSLT for Python/GAE at all. Almost all Python libraries are C bindings (and those are unsupported by GAE).
3. Memcache API: Java SDK have more interesting abilities than Python SDK.
4. Datastore API: JDO is very slow, but native Java datastore API is very fast and easy.

1. 性能：Java 可能比 Python 快。
2. Python 开发面临着缺乏第三方库的压力。例如，根本没有用于 Python/GAE 的 XSLT。几乎所有 Python 库都是 C 绑定（GAE 不支持这些库）。
3. Memcache API：Java SDK 比 Python SDK 有更多有趣的能力。
4. 数据存储 API：JDO 很慢，但原生 Java 数据存储 API 非常快速和简单。

I'm using Java/GAE in development right now.

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

回答by synchromesh

There's also project Unladen Swallow, which is apparently Google-funded if not Google-owned. They're trying to implement a LLVM-based backend for Python 2.6.1 bytecode, so they can use a JIT and various nice native code/GC/multi-core optimisations. (Nice quote: "We aspire to do no original work, instead using as much of the last 30 years of research as possible.") They're looking for a 5x speed-up to CPython.

还有一个Unladen Swallow项目，如果不是谷歌所有的话，它显然是由谷歌资助的。他们正在尝试为 Python 2.6.1 字节码实现基于 LLVM 的后端，因此他们可以使用 JIT 和各种不错的本机代码/GC/多核优化。（不错的引述：“我们不希望做原创工作，而是尽可能多地使用过去 30 年的研究成果。”）他们正在寻找比 CPython 快 5 倍的速度。

Of course this doesn't answer your immediate question, but points towards a "closing of the gap" (if any) in the future (hopefully).

当然，这并不能回答您当前的问题，而是指向未来（希望）“缩小差距”（如果有的话）。

回答by yanchenko

Gone with Python even though GWT seems a perfect match for the kind of an app I'm developing. JPA is pretty messed up on GAE (e.g. no @Embeddable and other obscure non-documented limitations). Having spent a week, I can tell that Java just doesn't feel right on GAE at the moment.

尽管 GWT 似乎与我正在开发的应用程序类型完美匹配，但我已经放弃了 Python。JPA 在 GAE 上非常混乱（例如，没有 @Embeddable 和其他晦涩的未记录限制）。花了一周的时间，我可以看出 Java 目前对 GAE 感觉不太合适。

回答by Richard Watson

Watch this app for changes in Python and Java performance:

观看此应用以了解 Python 和 Java 性能的变化：

http://gaejava.appspot.com/(edit: apologies, link is broken now. But following para still applied when I saw it running last)

http://gaejava.appspot.com/（编辑：抱歉，链接现在坏了。但是当我最后看到它运行时，以下段落仍然适用）

Currently, Python and using the low-level API in Java are faster than JDO on Java, for this simple test. At least if the underlying engine changes, that app should reflect performance changes.

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

回答by kilon

The beauty of python nowdays is how well it communicates with other languages. For instance you can have both python and java on the same table with Jython. Of course jython even though it fully supports java libraries it does not support fully python libraries. But its an ideal solution if you want to mess with Java Libraries. It even allows you to mix it with Java code with no extra coding.

现在 Python 的美妙之处在于它与其他语言的沟通能力。例如，您可以使用 Jython 在同一张表上同时使用 python 和 java。当然，即使 jython 完全支持 java 库，它也不完全支持 python 库。但如果你想弄乱 Java 库，它是一个理想的解决方案。它甚至允许您将它与 Java 代码混合使用，而无需额外编码。

But even python itself has made some steps forwared. See ctypes for example, near C speed , direct accees to C libraries all of this without leaving the comfort of python coding. Cython goes one step further , allowing to mix c code with python code with ease, or even if you dont want to mess with c or c++ , you can still code in python but use statically type variables making your python programms as fast as C apps. Cython is both used and supported by google by the way.

但即使是python本身也提前做了一些步骤。例如，参见 ctypes，接近 C speed ，直接访问 C 库所有这些，而不会离开 Python 编码的舒适度。Cython 更进一步，允许轻松地将 c 代码与 python 代码混合，或者即使您不想与 c 或 c++ 混在一起，您仍然可以在 python 中编码，但使用静态类型变量使您的 python 程序与 C 应用程序一样快. 顺便说一下，谷歌使用和支持 Cython。

Yesterday I even found tools for python to inline C or even Assembly (see CorePy) , you cant get any more powerful than that.

昨天我什至找到了 Python 内联 C 甚至是 Assembly（见 CorePy）的工具，你无法获得比这更强大的工具。

Python is surely a very mature language, not only standing on itself , but able to coooperate with any other language with easy. I think that is what makes python an ideal solution even in a very advanced and demanding scenarios.

Python无疑是一门非常成熟的语言，不仅自立，而且可以轻松地与任何其他语言合作。我认为这就是使 python 成为理想解决方案的原因，即使在非常先进和要求苛刻的场景中也是如此。

With python you can have acess to C/C++ ,Java , .NET and many other libraries with almost zero additional coding giving you also a language that minimises, simplifies and beautifies coding. Its a very tempting language.

使用 python，您可以访问 C/C++、Java、.NET 和许多其他库，几乎零附加编码，为您提供一种可以最小化、简化和美化编码的语言。它是一种非常诱人的语言。

回答by Tom

An important question to consider in deciding between Python and Java is how you will use the datastore in each language(and most other angles to the original question have already been covered quite well in this topic).

在决定使用 Python 还是 Java 时要考虑的一个重要问题是您将如何使用每种语言中的数据存储（并且本主题已经很好地涵盖了原始问题的大多数其他角度）。

For Java, the standard method is to use JDO or JPA. These are great for portability but are not very well suited to the datastore.

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

A low-level API is available but this is too low level for day-to-day use - it is more suitable for building 3rd party libraries.

有一个低级 API 可用，但这对于日常使用来说太低了 - 它更适合构建 3rd 方库。

For Pythonthere is an API designed specifically to provide applications with easy but powerful access to the datastore. It is great except that it is not portable so it locks you into GAE.

对于 Python，有一个 API 专门设计用于为应用程序提供对数据存储的简单但强大的访问。它很棒，只是它不便于携带，因此会将您锁定在 GAE 中。

Fortunately, there are solutions being developed for the weaknesses listed for both languages.

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

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 Siena project, and Objectify.

对于 Java，低级 API 用于开发比 JDO/JPA (IMO) 更适合数据存储的持久性库。示例包括Siena 项目和Objectify。

I've recently started using Objectify and am finding it to be very easy to use and well suited to the datastore, and its growing popularity has translated into good support. For example, Objectify is officially supported by Google's new Cloud Endpoints service. On the other hand, Objectify only works with the datastore, while Siena is 'inspired' by the datastore but is designed to work with a variety of both SQL databases and NoSQL datastores.

我最近开始使用 Objectify，我发现它非常易于使用并且非常适合数据存储，而且它的日益流行已经转化为良好的支持。例如，Google 的新 Cloud Endpoints 服务正式支持 Objectify。另一方面，Objectify 仅适用于数据存储，而 Siena 受数据存储“启发”，但旨在与各种 SQL 数据库和 NoSQL 数据存储一起使用。

For Python, there are efforts being made to allow the use of the Python GAE datastore API off of the GAE. One example is the SQLite backend that Google released for use with the SDK, but I doubt they intend this to grow into something production ready. The TyphoonAEproject probably has more potential, but I don't think it is production ready yet either (correct me if I am wrong).

对于 Python，正在努力允许在 GAE 之外使用 Python GAE 数据存储 API。一个例子是 Google 发布的用于 SDK 的 SQLite 后端，但我怀疑他们是否打算将其发展为生产就绪的东西。该TyphoonAE项目可能有更多的潜力，但我不认为这是生产准备好了吗或者（纠正我，如果我错了）。

If anyone has experience with any of these alternatives or knows of others, please add them in a comment. Personally, I really like the GAE datastore - I find it to be a considerable improvement over the AWS SimpleDB - so I wish for the success of these efforts to alleviate some of the issues in using it.

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

回答by Damon Oehlman

It's a good question, and I think many of the responses have given good view points of pros and cons on both sides of the fence. I've tried both Python and JVM-based AppEngine (in my case I was using Gaelykwhich is a Groovy application framework built for AppEngine). When it comes to performance on the platform, one thing I hadn't considered until it was staring me in the face is the implication of "Loading Requests" that occur on the Java side of the fence. When using Groovy these loading requests are a killer.

这是一个很好的问题，我认为很多回答都对双方的利弊给出了很好的观点。我已经尝试过基于 Python 和 JVM 的 AppEngine（在我的例子中，我使用的是Gaelyk，它是一个为 AppEngine 构建的 Groovy 应用程序框架）。当谈到平台上的性能时，我一直没有考虑过的一件事是在围栏的 Java 一侧发生的“加载请求”的含义。当使用 Groovy 时，这些加载请求是一个杀手。

I put a post together on the topic (http://distractable.net/coding/google-appengine-java-vs-python-performance-comparison/) and I'm hoping to find a way of working around the problem, but if not I think I'll be going back to a Python + Django combination until cold starting java requests has less of an impact.

我在这个主题上发表了一篇文章（http://distractable.net/coding/google-appengine-java-vs-python-performance-comparison/），我希望找到一种解决问题的方法，但是如果不是，我想我会回到 Python + Django 组合，直到冷启动 Java 请求的影响较小。