Sono di parte (essendo un esperto di Python ma piuttosto arrugginito in Java) ma penso che il runtime Python di GAE sia attualmente più avanzato e meglio sviluppato rispetto al runtime Java - il primo ha avuto un anno in più per svilupparsi e maturare, dopo tutto .
Ovviamente è difficile prevedere in che modo procederanno le cose: la domanda è probabilmente più forte dal lato Java (soprattutto perché non si tratta solo di Java, ma anche di altre lingue arroccate su JVM, quindi è IL modo di eseguire ad es. PHP o codice Ruby su App Engine); il team di Python App Engine ha tuttavia il vantaggio di avere a bordo Guido van Rossum, l'inventore di Python e un ingegnere incredibilmente forte.
In termini di flessibilità, il motore Java, come già accennato, offre la possibilità di eseguire il bytecode JVM realizzato da lingue diverse, non solo Java - se ti trovi in un negozio multilingue che è piuttosto positivo. Viceversa, se detesti Javascript ma devi eseguire un po 'di codice nel browser dell'utente, il GWT di Java (che genera JavaScript per te dalla tua codifica a livello Java) è molto più ricco e più avanzato rispetto alle alternative lato Python (in pratica, se scegli Python, scriverai un po 'di JS per questo scopo, mentre se scegli Java GWT è un'alternativa utilizzabile se detesti scrivere JS).
In termini di librerie è praticamente un lavaggio: la JVM è abbastanza limitata (nessun thread, nessun caricatore di classi personalizzato, nessun JNI, nessun DB relazionale) per ostacolare il semplice riutilizzo delle librerie Java esistenti tanto quanto, o più, rispetto a Python esistente le librerie sono analogamente ostacolate dalle restrizioni simili sul runtime di Python.
In termini di prestazioni, penso che sia un lavaggio, anche se dovresti fare un benchmark su attività per conto tuo - non fare affidamento sulle prestazioni di implementazioni JVM basate su JIT altamente ottimizzate che scontano i loro grandi tempi di avvio e footprint di memoria, perché il motore dell'app l'ambiente è molto diverso (i costi di avvio verranno pagati spesso, poiché le istanze della tua app vengono avviate, arrestate, spostate su host diversi, ecc., tutto in modo trasparente per te - tali eventi sono in genere molto più economici con gli ambienti di runtime Python rispetto alle JVM).
La situazione XPath / XSLT (essere eufemistici ...) non è esattamente perfetta su entrambi i lati, sospiro, anche se penso che potrebbe essere un po 'meno male nella JVM (dove, a quanto pare, si possono far funzionare sottoinsiemi sostanziali di Saxon , con una certa cura). Penso che valga la pena aprire i problemi sulla pagina dei problemi di Appengine con XPath e XSLT nei loro titoli - in questo momento ci sono solo problemi che richiedono librerie specifiche, ed è miope: non mi interessa davvero COME sia implementato un buon XPath / XSLT, per Python e / o per Java, purché riesca a usarlo. (Librerie specifiche possono facilitare la migrazione del codice esistente, ma è meno importante che essere in grado di eseguire attività come "applicare rapidamente la trasformazione XSLT" in QUALUNQUE modo! -). So che sarei il protagonista di questo problema se ben definito (soprattutto in modo indipendente dalla lingua).
Ultimo ma non meno importante: ricorda che puoi avere versioni diverse dell'app (usando lo stesso archivio dati) alcune delle quali sono implementate con il runtime Python, alcune con il runtime Java e puoi accedere a versioni diverse da "default / active "uno con URL espliciti. Quindi potresti avere sia il codice Python che il codice Java (in diverse versioni della tua app) utilizzare e modificare lo stesso archivio dati, garantendo una flessibilità ancora maggiore (anche se solo uno avrà l'URL "carino" come foobar.appspot.com - che è probabilmente importante solo per l'accesso degli utenti interattivi sui browser, immagino ;-).
