在Google App Engine上选择Java vs Python

问题:在Google App Engine上选择Java vs Python

目前,Google App Engine同时支持Python和Java。Java支持还不成熟。但是,Java似乎具有更长的库列表,尤其是对Java字节码的支持,无论用于编写该代码的语言是什么。哪种语言将提供更好的性能和更多的功能?请指教。谢谢!

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

编辑: “能力”是指更好的可扩展性和框架外部可用库的包含。不过,Python仅允许使用纯Python库。

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!

Edit: 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.


回答 0

我有偏见(是一名Python专家,但对Java却很生疏),但我认为GAE的Python运行时目前比Java运行时更先进和更好地开发-毕竟前者还有一年多的开发和成熟时间。

事情的进展当然很难预测-Java方面的需求可能会更强(特别是因为它不仅与Java有关,而且其他语言也位于JVM之上,因此这是运行方式,例如PHP或App Engine上的Ruby代码);但是,Python App Engine团队的确拥有加入Python的发明者,非常强大的工程师Guido van Rossum的优势。

在灵活性方面,如前所述,Java引擎确实提供了运行由不同语言(不仅是Java)制作的JVM字节码的可能性-如果您在一家多语言商店中,那肯定是很大的。反之亦然,如果您讨厌Javascript但必须在用户的浏览器中执行一些代码,则Java的GWT(通过Java级编码为您生成Javascript)比Python端的替代方案(实际上,如果您选择Python,您将为此目的自己编写一些JS,而如果您选择Java GWT,则如果您讨厌编写JS,则可以使用它。

就库而言,这几乎是一种洗礼- JVM受到足够的限制(没有线程,没有自定义类加载器,没有JNI,没有关系数据库),以至于妨碍了现有Java库的简单重用,甚至超过了现有Python。类似地,Python运行时的类似限制也限制了库。

就性能而言,尽管您应该以自己的任务为基准,但我认为这是一种洗礼–不要依赖高度优化的基于JIT的JVM实现的性能,因为它们会浪费大量的启动时间和内存,因为应用引擎环境是非常不同的(启动成本将经常支付,因为您的应用实例被启动,停止,移动到其他主机等)对您来说都是透明的-与Python相比,使用Python运行时环境这些事件通常要便宜得多。

叹气,尽管我认为XPath / XSLT的情况在两侧都不是完美的,但我认为这在JVM中可能会稍微好一些(显然,可以使Saxon的实质子集运行) ,但要小心)。我认为值得在Appengine问题页面上以XPath和XSLT作为标题来打开问题-现在只有问题需要特定的库,这是近视的:我真的不在乎如何实现良好的XPath / XSLT,只要适用于Python和/或Java。(特定的库可能会简化现有代码的迁移,但是这比能够以某种方式执行“快速应用XSLT转换”这样的任务要重要!)。我知道如果措辞得当(尤其是以与语言无关的方式),我会盯上这样的问题。

最后但并非最不重要的一点:请记住,您可以拥有不同版本的应用程序(使用相同的数据存储),其中一些版本是通过Python运行时实现的,某些版本是通过Java运行时实现的,并且您可以访问不同于“默认/活动”的版本”带有明确的网址。所以你可以同时拥有Python Java代码(在应用的不同版本中)使用和修改同一数据存储,从而为您提供更大的灵活性(尽管只有一个拥有“ nice” URL,例如foobar.appspot.com)我想这可能仅对交互式用户在浏览器上的访问很重要;-)。

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.

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.

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).

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.

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).

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).

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;-).


回答 1

观看此应用,了解Python和Java性能的变化:

http://gaejava.appspot.com/ (编辑:道歉,链接现在已断开。但是,当我看到它最后运行时,以下para仍然适用)

目前,对于此简单测试,Python和在Java中使用低级API的速度比Java上的JDO快。至少如果基础引擎发生变化,则该应用应反映出性能变化。

Watch this app for changes in Python and Java performance:

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

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.


回答 2

基于在其他平台上运行这些VM的经验,我想说Java可能会比Python带来更多原始性能。但是,请不要小看Python的卖点:Python语言在代码行方面的生产力要高得多-普遍的共识是,Python需要等效Java程序代码的三分之一,同时保持可读性或可读性。这种优势乘以无需立即进行编译步骤即可立即运行代码的能力。

关于可用的库,您会发现很多扩展的Python运行时库都是现成的(就像Java一样)。AppEngine还支持流行的Django Web框架(http://www.djangoproject.com/)。

关于“电源”,很难理解您的意思,但是Python已在许多不同的领域中使用,尤其是在Web上:YouTube是用Python编写的,Sourceforge也是如此(截至上周)。

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.

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.

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).


回答 3

2013年6月:此视频是Google工程师的一个很好的回答:

http://www.youtube.com/watch?v=tLriM2krw2E

TLDR;是:

  • 选择您和您的团队最能用的语言
  • 如果您想为生产而构建:Java或Python(而非Go)
  • 如果您有一个庞大的团队和一个复杂的代码库:Java(由于静态代码分析和重构)
  • 快速迭代的小型团队:Python(尽管Java也可以)

June 2013: This video is a very good answer by a google engineer:

http://www.youtube.com/watch?v=tLriM2krw2E

TLDR; is:

  • Pick the language that you and your team is most productive with
  • If you want to build something for production: Java or Python (not Go)
  • If you have a big team and a complex code base: Java (because of static code analysis and refactoring)
  • Small teams that iterate quickly: Python (although Java is also okay)

回答 4

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

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

可以使用低级API,但是对于日常使用而言,该级别太低-它更适合于构建第三方库。

对于Python,有一个专门设计用于向应用程序提供对数据存储的轻松但强大的访问的API。很棒,但是它不是便携式的,因此将您锁定在GAE中。

幸运的是,已经针对两种语言列出的弱点开发了解决方案。

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

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

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

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

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).

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.

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.

For Python there 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.

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.

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.

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 TyphoonAE project probably has more potential, but I don’t think it is production ready yet either (correct me if I am wrong).

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.


回答 5

我强烈推荐Java for GAE,这是为什么:

  1. 性能:Java可能比Python快。
  2. Python开发面临缺乏第三方库的压力。例如,根本没有用于Python / GAE的XSLT。几乎所有的Python库都是C绑定(GAE不支持这些绑定)。
  3. Memcache API:Java SDK比Python SDK具有更多有趣的功能。
  4. 数据存储区API:JDO速度很慢,但是本机Java数据存储区API却非常快速和容易。

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

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

  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.

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


回答 6

如您所确定的,使用JVM并不限制您使用Java语言。JVM语言和链接的列表可以在这里找到。然而,Google App Engine确实限制了您可以从常规Java SE集中使用的类集,并且您将要研究是否可以在App Engine上使用这些实现中的任何一种。

编辑:我看到你已经找到了这样的列表

我无法评论Python的性能。但是,由于JVM具有在运行时动态编译和优化代码的能力,因此它是一个非常强大的平台性能。

最终,性能将取决于您的应用程序的工作方式以及编码方式。在没有更多信息的情况下,我认为无法在此区域中提供更多的指针。

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.

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.

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.


回答 7

我对Python / Django SDK的干净,直接和无问题感到惊讶。但是,我开始遇到需要开始做更多JavaScript的情况,并认为我可能想利用GWT和其他Java实用程序。我只完成了GAE Java教程的一半,却又遇到了一个问题:Eclipse配置问题,JRE版本问题,Java令人麻木的复杂性以及一个令人困惑甚至可能损坏的教程。查看此站点以及从此处链接的其他站点对我来说很重要。我将回到Python,然后研究睡衣以帮助我应对JavaScript挑战。

I’ve been amazed at how clean, straightforward, and problem free the Python/Django SDK is. However I started running into situations where I needed to start doing more JavaScript and thought I might want to take advantage of the GWT and other Java utilities. I’ve gotten just half way through the GAE Java tutorial, and have had one problem after another: Eclipse configuration issues, JRE versionitis, the mind-numbing complexity of Java, and a confusing and possibly broken tutorial. Checking out this site and others linked from here clinched it for me. I’m going back to Python, and I’ll look into Pyjamas to help with my JavaScript challenges.


回答 8

我的谈话有点晚了,但这是我的两分钱。我真的很难在Python和Java之间进行选择,因为我精通两种语言。众所周知,两者都有优点和缺点,您必须考虑自己的要求和最适合您的项目的框架。

像我通常在这种困境中所做的那样,我会寻找数字来支持我的决定。我决定使用Python的原因有很多,但就我而言,有一个情节是临界点。如果您从2014年9月开始在GitHub上搜索“ Google App Engine” ,则会发现下图:

这些数字可能有很多偏差,但总的来说,GAE Python存储库的数量是GAE Java存储库的三倍。不仅如此,而且如果按“星数”列出项目,您会看到大多数Python项目都出现在顶部(您必须考虑到Python的使用时间更长)。对我来说,这对于Python来说是一个很好的例子,因为我考虑了社区的采用和支持,文档以及开源项目的可用性。

I’m a little late to the conversation, but here are my two cents. I really had a hard time choosing between Python and Java, since I am well versed in both languages. As we all know, there are advantages and disadvantages for both, and you have to take in account your requirements and the frameworks that work best for your project.

As I usually do in this type of dilemmas, I look for numbers to support my decision. I decided to go with Python for many reasons, but in my case, there was one plot that was the tipping point. If you search “Google App Engine” in GitHub as of September 2014, you will find the following figure:

There could be many biases in these numbers, but overall, there are three times more GAE Python repositories than GAE Java repositories. Not only that, but if you list the projects by the “number of stars” you will see that a majority of the Python projects appear at the top (you have to take in account that Python has been around longer). To me, this makes a strong case for Python because I take in account community adoption & support, documentation, and availability of open-source projects.


回答 9

这是一个很好的问题,我认为许多回应都很好地说明了围栏两侧的利弊。我已经尝试了基于Python和基于JVM的AppEngine(以我为例, Gaelyk,它是为AppEngine构建的Groovy应用程序框架)。当谈到平台的性能时,我一直没有想到的一件事就是它一直盯着我,这是在“ Java防护”方面的“加载请求”的含义。使用Groovy时,这些加载请求是致命的。

我在该主题上发表了一篇文章(http://distractable.net/coding/google-appengine-java-vs-python-performance-comparison/),希望找到解决此问题的方法,但是如果不是这样的话,我想我会回到Python + Django的组合,直到冷启动Java请求的影响减小为止。

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 Gaelyk which 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.

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.


回答 10

根据我听到的Java人与Python用户相比抱怨AppEngine的情况,我会说Python的使用压力要小得多。

Based on how much I hear Java people complain about AppEngine compared to Python users, I would say Python is much less stressful to use.


回答 11

还有一个项目Unladen Swallow,如果不是Google所有,显然是Google资助的。他们正在尝试为Python 2.6.1字节码实现基于LLVM的后端,因此他们可以使用JIT和各种不错的本机代码/ GC /多核优化。(很好的说法:“我们希望不做任何原始工作,而是尽可能多地利用过去30年的研究成果。”)他们正在寻求将CPython的速度提高5倍。

当然,这并不能回答您的紧迫问题,而是指向未来(希望)“缩小差距”(如果有)。

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.

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


回答 12

如今,python的魅力在于它与其他语言的交流程度。例如,您可以使用Jython将python和java放在同一表上。当然,即使jython完全支持Java库,它也不完全支持python库。但是,如果您想弄乱Java库,它是一个理想的解决方案。它甚至允许您将其与Java代码混合使用而无需额外的编码。

但是,即使python本身也已经采取了一些措施。例如,参见ctypes,接近C速度,直接访问C库,而无需离开python编码。Cython更进一步,允许轻松地将c代码与python代码混合,或者即使您不想弄乱c或c ++,您仍然可以在python中进行编码,但使用静态类型变量使python程序与C应用程序一样快。顺便说一下,Cython既被Google使用也受其支持。

昨天我什至发现了用于python内联C或Assembly的工具(请参阅CorePy),您将无法获得比它更强大的功能。

Python当然是一种非常成熟的语言,不仅可以独立存在,而且可以轻松地与任何其他语言配合。我认为,即使在非常高级和苛刻的情况下,这也是使python成为理想解决方案的原因。

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

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.

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.

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

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.

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.


回答 13

即使GWT对于我正在开发的应用程序来说似乎是一个完美的选择,但Python已经不复存在。JPA在GAE上非常混乱(例如,没有@Embeddable和其他晦涩的未记录限制)。花了一个星期的时间,我可以说Java暂时不适用于GAE。

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.


回答 14

要考虑的是您打算使用的框架。并非Java方面的所有框架都非常适合在App Engine上运行的应用程序,这与传统的Java应用程序服务器有些不同。

要考虑的一件事是应用程序启动时间。使用传统的Java Web应用程序,您实际上不需要考虑这一点。应用程序启动,然后运行。启动时间是5秒钟还是几分钟并不重要。使用App Engine,您可能会遇到仅在请求进入时才启动应用程序的情况。这意味着用户在应用程序启动时正在等待。GAE的新功能(如预留实例)在这里有帮助,但请先检查。

另一件事是GAE对Java的限制不同。并非所有的框架都对可以使用哪些类的限制或不允许使用线程或无法访问本地文件系统的事实感到满意。仅通过搜索GAE兼容性,可能很容易发现这些问题。

我还看到有些人抱怨现代UI框架(即Wicket)上的会话大小问题。通常,这些框架倾向于进行某些折衷,以使开发变得有趣,快速且容易。有时,这可能会导致与App Engine限制冲突。

我最初开始使用Java开发GAE,但由于这些原因,后来切换到Python。我个人的感觉认为Python是App Engine开发的更好选择。我认为Java在Amazon的Elastic Beanstalk上更“居家”。

但是使用App Engine的事情正在发生非常迅速的变化。GAE本身正在发生变化,并且随着它的日益流行,其框架也在发生变化以克服其局限性。

One think to take into account are the frameworks you intend yo use. Not all frameworks on Java side are well suited for applications running on App Engine, which is somewhat different than traditional Java app servers.

One thing to consider is the application startup time. With traditional Java web apps you don’t really need to think about this. The application starts and then it just runs. Doesn’t really matter if the startup takes 5 seconds or couple of minutes. With App Engine you might end up in a situation where the application is only started when a request comes in. This means the user is waiting while your application boots up. New GAE features like reserved instances help here, but check first.

Another thing are the different limitations GAE psoes on Java. Not all frameworks are happy with the limitations on what classes you can use or the fact that threads are not allowed or that you can’t access local filesystem. These issues are probably easy to find out by just googling about GAE compatibility.

I’ve also seen some people complaining about issues with session size on modern UI frameworks (Wicket, namely). In general these frameworks tend to do certain trade-offs in order to make development fun, fast and easy. Sometimes this may lead to conflicts with the App Engine limitations.

I initially started developing working on GAE with Java, but then switched to Python because of these reasons. My personal feeling is that Python is a better choice for App Engine development. I think Java is more “at home” for example on Amazon’s Elastic Beanstalk.

BUT with App Engine things are changing very rapidly. GAE is changing itself and as it becomes more popular, the frameworks are also changing to work around its limitations.