Je suis partial (étant un expert Python mais assez rouillé en Java) mais je pense que le runtime Python de GAE est actuellement plus avancé et mieux développé que le runtime Java - le premier a eu un an supplémentaire pour se développer et mûrir, après tout .
Il est bien sûr difficile de prévoir la manière dont les choses se passeront à l'avenir - la demande est probablement plus forte du côté Java (d'autant plus qu'il ne s'agit pas seulement de Java, mais aussi d'autres langages perchés au-dessus de la JVM, donc c'est LA façon d'exécuter par exemple PHP ou code Ruby sur App Engine); L'équipe Python App Engine a cependant l'avantage d'avoir à bord Guido van Rossum, l'inventeur de Python et un ingénieur incroyablement fort.
En termes de flexibilité, le moteur Java, comme déjà mentionné, offre la possibilité d'exécuter un bytecode JVM créé par différents langages, pas seulement Java - si vous êtes dans une boutique multilingue, c'est un avantage assez important. Vice versa, si vous détestez Javascript mais devez exécuter du code dans le navigateur de l'utilisateur, le GWT de Java (générant le Javascript pour vous à partir de votre codage au niveau Java) est beaucoup plus riche et plus avancé que les alternatives côté Python (en pratique, si vous choisissez Python, vous allez écrire vous-même du JS à cette fin, tandis que si vous choisissez Java, GWT est une alternative utilisable si vous détestez écrire JS).
En termes de bibliothèques, c'est à peu près un lavage - la JVM est suffisamment restreinte (pas de threads, pas de chargeur de classe personnalisé, pas de JNI, pas de base de données relationnelle) pour entraver la simple réutilisation des bibliothèques Java existantes autant, voire plus, que Python existant Les bibliothèques sont également gênées par les restrictions similaires sur le runtime Python.
En termes de performances, je pense que c'est un lavage, même si vous devriez vous comparer à vos propres tâches - ne vous fiez pas aux performances des implémentations JVM hautement optimisées basées sur JIT en réduisant leurs temps de démarrage et leur empreinte mémoire importants, car le moteur d'application l'environnement est très différent (les coûts de démarrage seront souvent payés, car les instances de votre application sont démarrées, arrêtées, déplacées vers différents hôtes, etc., le tout de manière transparente pour vous - de tels événements sont généralement beaucoup moins chers avec les environnements d'exécution Python qu'avec les JVM).
La situation XPath / XSLT (pour être euphémique ...) n'est pas exactement parfaite de chaque côté, soupir, même si je pense que cela peut être un peu moins mauvais dans la JVM (où, apparemment, des sous-ensembles substantiels de Saxon peuvent être exécutés , avec une certaine prudence). Je pense que cela vaut la peine d'ouvrir des problèmes sur la page Appengine Issues avec XPath et XSLT dans leurs titres - pour le moment, il n'y a que des problèmes demandant des bibliothèques spécifiques, et c'est myope: je ne me soucie pas vraiment de la façon dont un bon XPath / XSLT est implémenté, pour Python et / ou pour Java, tant que je peux l'utiliser. (Des bibliothèques spécifiques peuvent faciliter la migration du code existant, mais c'est moins important que de pouvoir effectuer des tâches telles que "appliquer rapidement la transformation XSLT" de quelque manière! -). Je sais que je serais la vedette d'un tel problème s'il était bien formulé (en particulier d'une manière indépendante de la langue).
Dernier point mais non le moindre: rappelez-vous que vous pouvez avoir différentes versions de votre application (en utilisant le même magasin de données) dont certaines sont implémentées avec le runtime Python, d'autres avec le runtime Java, et vous pouvez accéder à des versions qui diffèrent de "default / active "un avec des URL explicites. Ainsi, vous pouvez faire en sorte que le code Python et Java (dans différentes versions de votre application) utilise et modifie le même magasin de données, vous offrant encore plus de flexibilité (même si un seul aura la "belle" URL telle que foobar.appspot.com - ce qui n'est probablement important que pour l'accès des utilisateurs interactifs sur les navigateurs, j'imagine ;-)