O Google aumentou o suporte de seu Google App Engine (GAE) para incluir Java além do Python. Esta adição traz um grande conjunto de ferramentas do ecossistema Java como frameworks, linguagens (JRuby, Groovy e Clojure). Entretanto, isso também impõe uma variedade de limitações às aplicações Java no GAE para tornar possível ao Google escalar e fazer cluster com o mínimo de esforço. O anúncio oficial no blog do Google resume a introdução do suporte ao Java dizendo:
...Nós queríamos dar aos desenvolvedores algo que os deixasse muito felizes, mas sabíamos que teríamos que unir a simplicidade do Google App Engine com o poder e a flexibilidade da plataforma Java. Nós também queríamos alavancar a infraestrutura do App Engine -- e por extensão a infraestrutura do Google -- tanto quanto possível, sem abandonar a compatibilidade com os padrões e ferramentas Java existentes.E assim o fizemos. O App engine agora suporta os padrões que tornam o ferramental Java ótimo. (Nós estamos trabalhando em ferramental também, com o Google Plugin para o Eclipse). Ele fornece a API atual do App Engine e a encapsula com padrões onde é relevante, como a API de Servlets, JDO e JPA, javax.cache e javax.mail. Ele também fornece um ambiente seguro que é poderoso o suficiente para executar seu código de forma segura em servidores Google, enquanto é flexível o suficiente para você romper as abstrações quando quiser...
CNet destaca que o GAE está rodando o Java 6. Entretanto, como mencionado acima, várias limitações foram impostas para tornar o Java mais adaptado ao modelo do GAE. O GAE Java é baseado na Servlet API 2.4:
- Uma vez que um request é enviado para o cliente, nenhum outro processamento pode ser feito. Isso inclui streaming de dados.
- Um request será terminado se demorar mais que 30 segundos para completar. Neste ponto, uma exception é lançada. Se não for tratada, um erro 500 será retornado ao usuário.
Subindo o nível, há várias restrições:
- Aplicações não podem gravar no file system e devem usar o armazenamento de dados do App Engine como alternativa.
- Aplicações não podem criar socktes
- Aplicações não podem criar suas próprias threads ou usar utilitários relacionados, como timer.
java.lang.System recebeu restrições como segue:
- exit(), gc(), runFinalization(), e runFinalizersOnExit() não fazem nada.
- Acesso JNI não é permitido.
Além desses itens principais, há ainda outras limitações como a lista de carregamento da JRE. A partir da documentação, o GAE parece impor uma boa parte de sua mágica usando classloaders customizados. Entretanto, eles devem permitir outros classloaders a nível de aplicação desde que eles possam operar com as restrições acima.
A próxima questão lógica é o que as restrições acima fornecem aos usuários em termos de benefícios para aplicações GAE. A primeira é escalabilidade. O App Engine usa múltiplos web servers para rodar sua aplicação e automaticamente ajusta os vários servidores que ele usa para tratar os requests de forma confiável. Um dado request pode ser roteado para qualquer servidor e pode não ser o mesmo servidor que manipulou o request anterior do mesmo usuário. A documentação diz:
...uma aplicação pode processar por volta de 30 requests dinâmicos ativos simultaneamente. Isso significa que uma aplicação que leva uma média de 75 milisegundos para processar um request pode servir mais de (1000ms/seg / 75ms/seg) * 30 = 400request/seg sem recorrer a latência adicional. Aplicações que usam a CPU de forma mais pesada podem recorrer a latência adicional para requests longos com o objetivo de deixar espaço para outras aplicações que compartilham os mesmos servidores. Requests para arquivos estáticos não são afetados por este limite...
O Google também fornecer uma versão do BigTable para JDO e JPA e um Google Plugin para Eclipse que facilita o desenvolvimento para o GAE.
O Google deixou alguns desenvolvedores Java brincarem com o GAE enquanto ele estava em desenvolvimento. Paul Hammat foi um deles e fez algumas observações:
...saiba também que requests múltiplos e concorrentes do mesmo client não vão necessariamente ser tratados pela mesma instância do servlet container. Aparentemente são todos do mesmo domain name (não há encaminhamento de recursos), mas é bem provável que serão servlet container diferentes respondendo aos requests. Isso não será um problema para aplicações stateless (sem estado entre os request) escritas corretamente, mas as que usam a sessão para armazenar atributos podem encontrar problemas de concorrência ao escrever no mesmo recurso lógico dentro do mapa aparente......o Google implementou uma caixa de areia bem abrangente. Sem dúvida para protegê-los e código malicioso ... XStream é uma que é particularmente amado por parte da comunidade Java. A última versão é 1.3.1 e na inicialização em algum lugar do realm do GAE lança uma exception.
Outros engenheiros foram capazes de fazer rodar Clojure, JRuby e Groovy. Ola Bini tem um post detalhado em seu blog sobre o tratamento do GAE para linguagens dinâmicas.