Saya bias (menjadi ahli Python tetapi cukup berkarat di Jawa) tapi saya pikir runtime Python dari GAE saat ini lebih maju dan lebih berkembang daripada runtime Java - yang pertama memiliki satu tahun ekstra untuk berkembang dan matang, setelah semua .
Bagaimana hal-hal akan berjalan maju tentu saja sulit untuk diprediksi - permintaan mungkin lebih kuat di sisi Jawa (terutama karena itu bukan hanya tentang Jawa, tetapi bahasa lain juga bertengger di atas JVM, jadi itu adalah cara untuk menjalankan misalnya PHP atau kode Ruby di App Engine); Namun tim Mesin App Python memang memiliki keuntungan memiliki Guido van Rossum, penemu Python dan insinyur yang luar biasa kuat.
Dalam hal fleksibilitas, mesin Java, seperti yang telah disebutkan, memang menawarkan kemungkinan menjalankan bytecode JVM yang dibuat oleh berbagai bahasa, bukan hanya Java - jika Anda berada di toko multi-bahasa yang positif cukup besar. Begitu juga sebaliknya, jika Anda membenci Javascript tetapi harus menjalankan beberapa kode di peramban pengguna, Java GWT (menghasilkan Javascript untuk Anda dari pengkodean tingkat Java) jauh lebih kaya dan lebih maju daripada alternatif sisi Python (dalam praktiknya, jika Anda memilih Python, Anda akan menulis sendiri beberapa JS untuk tujuan ini, sementara jika Anda memilih Java GWT adalah alternatif yang dapat digunakan jika Anda tidak suka menulis JS).
Dalam hal perpustakaan, ini cukup mudah - JVM cukup terbatas (tidak ada utas, tidak ada pemuat kelas khusus, tidak ada JNI, tidak ada DB relasional) untuk menghambat penggunaan kembali yang sederhana dari perpustakaan Java yang ada sebanyak, atau lebih, daripada Python yang ada perpustakaan sama-sama terhambat oleh pembatasan serupa pada runtime Python.
Dalam hal kinerja, saya pikir ini adalah pekerjaan biasa, meskipun Anda harus melakukan tolok ukur pada tugas Anda sendiri - jangan mengandalkan kinerja implementasi JVM berbasis JIT yang sangat dioptimalkan dengan diskon waktu startup dan jejak kaki memori yang besar, karena mesin aplikasi lingkungan sangat berbeda (biaya awal akan sering dibayar, karena instance aplikasi Anda dimulai, dihentikan, dipindahkan ke host yang berbeda, dll, semua benar-benar untuk Anda - peristiwa seperti itu biasanya jauh lebih murah dengan lingkungan runtime Python daripada dengan JVM).
Situasi XPath / XSLT (menjadi eufemistik ...) tidak sepenuhnya sempurna di kedua sisi, huh, meskipun saya pikir ini mungkin tidak terlalu buruk di JVM (di mana, tampaknya, subset besar dari Saxon dapat dibuat untuk dijalankan , dengan hati-hati). Saya pikir itu layak membuka masalah pada halaman Appengine Issues dengan XPath dan XSLT dalam judul mereka - saat ini hanya ada masalah meminta perpustakaan tertentu, dan itu rabun: Saya tidak begitu peduli BAGAIMANA XPath / XSLT yang baik diimplementasikan, untuk Python dan / atau untuk Java, selama saya bisa menggunakannya. (Perpustakaan tertentu dapat memudahkan migrasi kode yang ada, tapi itu kurang penting daripada mampu melakukan tugas-tugas seperti "cepat menerapkan transformasi XSLT" dengan BEBERAPA cara! -). Saya tahu saya akan membintangi masalah seperti itu jika diutarakan dengan baik (terutama dengan cara yang mandiri dalam bahasa).
Last but not least: ingat bahwa Anda dapat memiliki versi aplikasi yang berbeda (menggunakan datastore yang sama) beberapa di antaranya diimplementasikan dengan runtime Python, beberapa dengan runtime Java, dan Anda dapat mengakses versi yang berbeda dari "default / aktif "satu dengan URL eksplisit. Jadi Anda bisa menggunakan kode Python dan Java (dalam versi berbeda dari aplikasi Anda) menggunakan dan memodifikasi penyimpanan data yang sama, memberi Anda lebih banyak fleksibilitas (walaupun hanya satu yang akan memiliki URL "bagus" seperti foobar.appspot.com - yang mungkin penting hanya untuk diakses oleh pengguna interaktif di browser, saya kira ;-).
