Sou tendencioso (sendo um especialista em Python, mas bastante enferrujado em Java), mas acho que o tempo de execução Python do GAE atualmente é mais avançado e melhor desenvolvido do que o tempo de execução Java - o primeiro teve mais um ano para desenvolver e amadurecer, afinal .
Naturalmente, é difícil prever como as coisas vão progredir - a demanda provavelmente é mais forte no lado do Java (especialmente porque não se trata apenas de Java, mas de outras linguagens que também estão na parte superior da JVM, é a maneira de executar, por exemplo, PHP ou código Ruby no App Engine); a equipe do Python App Engine, no entanto, tem a vantagem de ter Guido van Rossum, o inventor do Python e um engenheiro incrivelmente forte.
Em termos de flexibilidade, o mecanismo Java, como já mencionado, oferece a possibilidade de executar o bytecode da JVM feito por diferentes linguagens, não apenas o Java - se você estiver em uma loja multilíngue, é um grande positivo. Vice-versa, se você detesta o Javascript, mas precisa executar algum código no navegador do usuário, o GWT do Java (gerando o Javascript para você a partir da codificação no nível do Java) é muito mais rico e avançado do que as alternativas do lado do Python (na prática, se você escolher Python, você mesmo escreverá algumas JS para esse fim, enquanto que se escolher Java GWT é uma alternativa utilizável se detestar escrever JS).
Em termos de bibliotecas, é praticamente uma lavagem - a JVM é restrita o suficiente (sem encadeamentos, sem carregadores de classes personalizados, sem JNI, sem banco de dados relacional) para dificultar a reutilização simples das bibliotecas Java existentes tanto quanto mais do que o Python existente bibliotecas são igualmente impedidas pelas restrições semelhantes no tempo de execução do Python.
Em termos de desempenho, acho que é uma lavagem, embora você deva avaliar suas próprias tarefas - não confie no desempenho de implementações de JVM baseadas em JIT altamente otimizadas, descontando seus grandes tempos de inicialização e pegadas de memória, porque o mecanismo de aplicativo o ambiente é muito diferente (os custos de inicialização serão pagos com frequência, à medida que as instâncias do seu aplicativo são iniciadas, paradas, movidas para hosts diferentes, etc., tudo isso para você - esses eventos geralmente são muito mais baratos nos ambientes de tempo de execução Python do que nas JVMs).
A situação XPath / XSLT (para ser eufemística ...) não é exatamente perfeita de nenhum lado, suspiro, embora eu ache que pode ser um pouco menos ruim na JVM (onde, aparentemente, subconjuntos substanciais de saxão podem ser executados , com algum cuidado). Acho que vale a pena abrir problemas na página Appengine Issues com XPath e XSLT em seus títulos - no momento, existem apenas problemas solicitando bibliotecas específicas, e isso é míope: eu realmente não me importo com o modo como um bom XPath / XSLT é implementado, para Python e / ou Java, desde que eu possa usá-lo. (Bibliotecas específicas podem facilitar a migração do código existente, mas isso é menos importante do que ser capaz de executar tarefas como "aplicar rapidamente a transformação XSLT" de alguma maneira! -). Sei que estrelaria esse problema se fosse bem formulado (especialmente de maneira independente do idioma).
Por último, mas não menos importante: lembre-se de que você pode ter uma versão diferente do seu aplicativo (usando o mesmo armazenamento de dados), alguns dos quais são implementados com o tempo de execução do Python, outros com o tempo de execução do Java e é possível acessar versões diferentes do "padrão / ativo" "um com URLs explícitos. Assim, você pode fazer com que os códigos Python e Java (em versões diferentes do seu aplicativo) usem e modifiquem o mesmo repositório de dados, concedendo a você ainda mais flexibilidade (embora apenas um tenha o URL "legal", como foobar.appspot.com - o que provavelmente é importante apenas para o acesso de usuários interativos nos navegadores, imagino ;-).
