在 Google App Engine 上选择 Java 还是 Python [英] Choosing Java vs Python on Google App Engine
问题描述
目前 Google App Engine 支持 Python 和爪哇.Java 支持不太成熟.但是，Java 似乎有更长的库列表，尤其是对 Java 字节码的支持，而不管用于编写该代码的语言如何.哪种语言会提供更好的性能和更强大的功能?请指教.谢谢！
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!
http:///groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1
我所说的强大"是指更好的可扩展性和包含框架之外的可用库.不过，Python 只允许使用纯 Python 库.
By "power" I mean better expandability and inclusion of available libraries outside the framework. Python allows only pure Python libraries, though.
推荐答案
我有偏见(我是 Python 专家，但对 Java 相当生疏)但我认为 GAE 的 Python 运行时目前比 Java 更先进，开发得更好运行时——毕竟前者还有一年多的时间来开发和成熟.
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.
事情将如何发展当然很难预测——Java 方面的需求可能更强(特别是因为它不仅与 Java 有关，而且其他语言也位于 JVM 之上，所以这是实现的方式)在 App Engine 上运行例如 PHP 或 Ruby 代码)；然而，Python App Engine 团队的优势在于，Guido van Rossum 是 Python 的发明者，也是一位非常强大的工程师.
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 引擎确实提供了运行由不同语言生成的 JVM 字节码的可能性，而不仅仅是 Java —— 如果您在多语言商店中，这是一个很大的积极因素.反之亦然，如果你讨厌 Javascript 但必须在用户的浏览器中执行一些代码，Java 的 GWT(从你的 Java 级编码为你生成 Javascript)比 Python 端的替代品(实际上，如果你选择Python，您将为此目的自己编写一些 JS，而如果您选择 Java，如果您讨厌编写 JS，GWT 是一个可用的替代方案).
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).
就库而言，这几乎是一种洗礼——JVM 受到足够的限制(没有线程、没有自定义类加载器、没有 JNI、没有关系数据库)，以致阻碍了对现有 Java 库的简单重用，甚至更多，与现有的 Python 库相比，Python 运行时的类似限制同样受到阻碍.
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.
在性能方面，我认为这是一个洗礼，尽管您应该对自己的任务进行基准测试——不要依赖高度优化的基于 JIT 的 JVM 实现的性能，而忽略它们的大启动时间和内存占用，因为应用程序引擎环境非常不同(启动成本将经常支付，因为您的应用程序实例的启动、停止、移动到不同的主机等，对您来说都是透明的——这些事件在 Python 运行时环境中通常比使用 Python 运行时环境便宜得多JVM).
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).
XPath/XSLT 情况(委婉地说......)在任何一方都不完全完美，叹息，尽管我认为它在 JVM 中可能不那么糟糕(显然，Saxon 的大量子集可以运行，小心).我认为值得在 Appengine Issues 页面上打开问题，其中包含 XPath 和 XSLT标题——现在只有要求特定库的问题，这是短视的:我并不真正关心如何实现一个好的 XPath/XSLT，对于 Python 和/或 Java，只要我开始使用它.(特定的库可能会简化现有代码的迁移，但这不如能够以某种方式执行快速应用 XSLT 转换"之类的任务重要！-).我知道如果措辞得当(尤其是在独立于语言的方式下)，我会为这样的问题加注星标.
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 Issues page 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).
最后但并非最不重要的一点:请记住，您可以拥有不同版本的应用程序(使用相同的数据存储)，其中一些使用 Python 运行时实现，一些使用 Java 运行时实现，并且您可以访问与默认/活动"具有显式 URL 的一种.因此，您可以让 Python 和 Java 代码(在您的应用程序的不同版本中)使用和修改相同的数据存储，从而赋予您更大的灵活性(尽管只有一个具有不错"的 URL，例如foobar.appspot.com——我想这可能只对浏览器上的交互式用户访问很重要；-)
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 and Java 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;-).
这篇关于在 Google App Engine 上选择 Java 还是 Python的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
