Soy parcial (siendo un experto en Python pero bastante oxidado en Java), pero creo que el tiempo de ejecución de Python de GAE es actualmente más avanzado y mejor desarrollado que el tiempo de ejecución de Java: el primero ha tenido un año adicional para desarrollarse y madurar, después de todo .
Por supuesto, es difícil predecir cómo avanzarán las cosas: la demanda es probablemente más fuerte en el lado de Java (especialmente porque no se trata solo de Java, sino también de otros lenguajes ubicados en la parte superior de la JVM, por lo que es LA manera de ejecutar, por ejemplo, PHP o código Ruby en App Engine); Sin embargo, el equipo de Python App Engine tiene la ventaja de tener a bordo a Guido van Rossum, el inventor de Python y un ingeniero increíblemente fuerte.
En términos de flexibilidad, el motor de Java, como ya se mencionó, ofrece la posibilidad de ejecutar el código de bytes JVM hecho por diferentes idiomas, no solo Java, si está en una tienda multilingüe, eso es bastante positivo. Viceversa, si detesta Javascript pero debe ejecutar algún código en el navegador del usuario, el GWT de Java (que genera el Javascript para usted a partir de su codificación de nivel Java) es mucho más rico y avanzado que las alternativas del lado de Python (en la práctica, si elige Python, usted mismo escribirá algo de JS para este propósito, mientras que si elige Java GWT es una alternativa útil si detesta escribir JS).
En términos de bibliotecas, es casi un lavado: la JVM está lo suficientemente restringida (sin hilos, sin cargadores de clases personalizados, sin JNI, sin base de datos relacional) para obstaculizar la reutilización simple de las bibliotecas Java existentes tanto o más que Python existente las bibliotecas están igualmente obstaculizadas por restricciones similares en el tiempo de ejecución de Python.
En términos de rendimiento, creo que es un lavado, aunque debe comparar sus propias tareas: no confíe en el rendimiento de las implementaciones JVM basadas en JIT altamente optimizadas que descuentan sus grandes tiempos de inicio y huellas de memoria, porque el motor de la aplicación el entorno es muy diferente (los costos de inicio se pagarán a menudo, ya que las instancias de su aplicación se inician, se detienen, se mueven a diferentes hosts, etc., todo de manera transparente para usted; tales eventos suelen ser mucho más baratos con entornos de tiempo de ejecución de Python que con JVM).
La situación XPath / XSLT (para ser eufemístico ...) no es exactamente perfecta en ninguno de los lados, suspiro, aunque creo que puede ser un poco menos malo en la JVM (donde, aparentemente, se puede hacer que corran grandes subconjuntos de Saxon) , con un poco de cuidado). Creo que vale la pena abrir problemas en la página de problemas de Appengine con XPath y XSLT en sus títulos; en este momento solo hay problemas para solicitar bibliotecas específicas, y eso es miope: realmente no me importa CÓMO se implementa un buen XPath / XSLT, para Python y / o Java, siempre que pueda usarlo. (Las bibliotecas específicas pueden facilitar la migración del código existente, ¡pero eso es menos importante que poder realizar tareas como "aplicar rápidamente la transformación XSLT" de ALGUNA forma!). Sé que destacaría este problema si estuviera bien redactado (especialmente en una forma independiente del idioma).
Por último, pero no menos importante: recuerde que puede tener una versión diferente de su aplicación (usando el mismo almacén de datos), algunas de las cuales se implementan con el tiempo de ejecución de Python, algunas con el tiempo de ejecución de Java y puede acceder a versiones que difieren de la "predeterminada / activa "uno con URL explícitas. Por lo tanto, puede hacer que tanto el código Python como Java (en diferentes versiones de su aplicación) usen y modifiquen el mismo almacén de datos, lo que le otorga aún más flexibilidad (aunque solo uno tendrá la URL "agradable" como foobar.appspot.com - lo cual probablemente sea importante solo para el acceso de los usuarios interactivos en los navegadores, me imagino ;-).
