AN style="FONT-SIZE: 10pt; BACKGROUND: white; COLOR: red; FONT-FAMILY: Verdana; moz-background-clip: -moz-initial; moz-background-origin: -moz-initial; moz-background-inline-policy: -moz-initial">
PAN>
lo style="MARGIN: 0cm 0cm 12pt">A natureza da plataforma Java, hoje e amanhã
Uma profunda investigação das plataformas Java SE e ME, uma visão do seu futuro próximo... e uma porção de curiosidades
De que se trata o artigo:
Exploramos uma diversidade de aspectos da plataforma Java: os motivos do seu sucesso, sua natureza, potenciais de evolução... damos uma olhada em novidades do Java SE 7 e do OpenJDK, investigamos o suporte a novas linguagens, fazemos comparações com a plataforma .NET. Por fim, começamos a especular sobre as plataformas Java FX e Java FX Mobile.
Para que serve:
Quem programa em Java mas é antenado em outras tecnologias, acompanhando o noticiário técnico, pode estar sempre numa grande confusão vendo o grande número de direções nas quais o Java (bem como outras linguagens plataformas) parece seguir. Linguagens dinâmicas, plataformas móveis, Java FX, novos frameworks, paradigmas, competidores (de linguagens nativas às da .NET)... Neste artigo, procuramos jogar alguma luz sobre todo este panorama, focando nas plataformas Java e nas suas evoluções para o futuro próximo.
Na busca por novos temas para escrever, volta e meia me inspiro em eventos relevantes, como as últimas conferências que apresentam novidades de produtos, tecnologias ou pesquisas. Assim, recentemente ‘digeri’ as apresentações da JVM Language Summit, que aconteceu no final de Setembro, no campus da Sun (e tratando não só de Java, mas abrindo espaço para plataformas como .NET e Perl). Embora esta seja uma conferência técnica avançada, dirigida ao pessoal que cria linguagens e VMs, os temas discutidos me pareceram muito relevantes por revelar uma série de avanços e tendências que já vêm sendo “sentidos” pelos desenvolvedores de aplicação. Neste artigo, vamos fazer um mergulho na essência da plataforma Java, do desenvolvimento de software em geral, de hoje e amanhã.
A maior parte do artigo trata das plataformas Java SE / EE ou do Java como um todo. Mas aproveitamos para fazer um “Quick Update” também no Java ME, veja o quadro “O Java FX e o novo Java ME”.
The Feel of Java
Começando pelo título do clássico paper de James Gosling (1997), e aproveitando a polêmica recente das closures do Java SE 7 (ver Edição 62), gostaria de dar minha contribuição do debate sobre a “natureza” ou o “estilo” do Java. Na questão das closures, a reclamação de alguns é que esta nova facilidade não seria compatível com o Java que conhecemos hoje: tornaria a linguagem mais complexa, ou mais funcional, ou de alguma outra forma, diferente da linguagem atual. Em menor proporção, o mesmo bate-boca sempre acompanha qualquer proposta de alteração da linguagem: como decidir quais novas características combinam harmoniosamente com a linguagem (e APIs) existente? Como mensurar o equilíbrio entre o tamanho da linguagem (que em geral, só pode crescer e ficar mais complexa com novas sintaxes) e os benefícios de novos recursos?
Que espécie de linguagem é Java... qual é o seu DNA?
Figura 1. O “quadrante das linguagens” pré-Java, na visão de James Gosling.
Um slide da keynote de James Gosling na JVM Language Summit (Figura 1) complementa esta visão, mostrando o estado de coisas que incomodava os criadores do Java no início dos anos 90. Num extremo, linguagens eficientes, mas de baixo nível como C; do outro, linguagens de scripting produtivas, dinâmicas e modernas, mas com baixo desempenho. Já havia soluções que poderiam combinar o melhor destes dois mundos – mas estas são representadas, no canto superior direito, por “linguagens malucas de pesquisa” que jamais fizeram sucesso no mundo real.
O slide não cita nomes, mas eu apontaria para os suspeitos mais óbvios como Self ou ML: linguagens simultaneamente dinâmicas e avançadas e (pelo menos relativamente) eficientes; porém, muito “malucas” para fazerem sucesso fora do mundo acadêmico, pelo menos na sua época.
Em seguida, Gosling revela o plano do Java de ser um “lobo em pele de cordeiro”: uma sintaxe parecida com C para manter os desenvolvedores confortáveis, e por trás disso, um design baseado em linguagens como “Lisp, Simula, Smalltalk e Mesa... para dar conta do serviço”.
Não é uma idéia original. Desde que o C se tornou a linguagem dominante nos anos 80, vários candidatos à sua sucessão seguiram o mesmo plano, como C++ (também com sucesso) e Objective-C. A diferença é que estas linguagens fizeram muito poucos avanços, pelo menos em características valorizadas por Gosling. Não possuem runtimes dinâmicos, mantendo o modelo de compilação estática. Não são “gerenciadas”, carecendo de typesystems fortes e outras salvaguardas. Não adotam alocação automática (GC), um recurso ainda polêmico na época em que o Java surgiu, mas hoje em dia dado como obrigatório em qualquer linguagem moderna e de nível de abstração acima do C.
Pragmatismo = Desempenho
Embora as primeiras versões do Java não tivessem bom desempenho, isso era apenas uma insuficiência de implementação – por exemplo, o bytecode era totalmente interpretado. Mas o design do Java foi bolado desde o início com grande ênfase no desempenho, e com o decorrer dos anos e aperfeiçoamento das implementações, vimos que este design foi acertado. Hoje o Java é muito competitivo em termos de performance, e não há dúvida que este desempenho foi crucial para que o Java se tornasse o sucesso que é. Por isso, Gosling continua à vontade, em pleno 2008, para continuar defendendo decisões como ter tipos primitivos.
No high-end Enterprise, o design do Java nos permite implementar uma aplicação sofisticada, capaz de taxas como 100 transações por segundo numa única CPU – falo de transações complexas: distribuídas, com acesso a dados, mensageria, e processamento não-trivial. Um cenário mais próximo da regra do que da exceção, nesta época de SOA.
Já no low-end, o Java conseguiu se mostrar competitivo também em dispositivos limitados, desde os relativamente poderosos smartphones e PDAs até plataformas paupérrimas como smartcards. Na faixa de dispositivos cobertos pelo CLDC/MIDP, o sucesso do Java ME é incontestável.
O melhor argumento que algum “purista” pode levantar é que o sucesso do Java deve menos ao seu desempenho que a outras qualidades como facilidade de programação, portabilidade etc. Eu já vi este comentário em fóruns por aí, mas acho-o difícil de engolir. Já usei Java com sucesso em diversos projetos com requisitos de desempenho apertados – nos quais, se o Java não estivesse no mesmo patamar que C/C++, não teria sido uma linguagem viável para o projeto.
Entendendo o desempenho do Java
Evangelismo à parte, afirmações do tipo “o Java é tão rápido quanto C/C++” são relativas, pois existem realidades como o tempo de inicialização de grandes aplicações, ou um maior consumo de memória em comparação com linguagens nativas. Não se vê muito uso do Java em certas aplicações de grande visibilidade pela sua exigência por desempenho, como games de ação modernos.
O Java possui limitações, sim. Na linguagem e VM, falta suporte a alguns recursos importantes para certas aplicações. Em especial, o Java não possui os chamados lightweight objects – objetos “leves”, similares às structs do C, que não carregam um header de 8 bytes para cada objeto (para suporte a monitores, polimorfismo e outros recursos de OO do Java). Ou arrays de objetos por valor (e não por referência). Isso pode fazer diferença, por exemplo, num jogo 3D que manipula muitos milhões de objetos minúsculos, como triângulos. Eu estimo (e a Sun admite, numa apresentação de John Pampuch sobre o HotSpot) que Java deve ter no pior caso uns 50% do desempenho do C. Este pior-caso vale para aplicações que dependem muito destes recursos de baixo nível que o Java não oferece – mas felizmente, este não é o caso da enorme maioria das aplicações.
Num jogo 3D, o grosso do trabalho é realizado pela GPU, que o Java pode acessar via OpenGL. (Veja lwjgl.org. Ou, mais convincente, bytonic.de/html/jake2.html: um porte do Quake 2 para Java.) Mas a GPU não faz tudo, e os games mais avançados se diferenciam por engines que executam – na CPU – uma “calculeira braba” para criar efeitos que vão além dos recursos padrão das GPUs, expostos por APIs como Direct3D e OpenGL.
Mas a maioria dos casos de mau desempenho do Java são problemas de percepção, geralmente causados por bibliotecas – com um design OO purista, voltado à riqueza de funcionalidades, segurança, produtividade, portabilidade, flexibilidade, etc.; tudo isso tem um custo
Uma Historinha de OO x Desempenho
Quando eu estava cursando minha graduação, o status quo em GUIs era C com APIs de baixo nível como GDI/USER (Windows) ou X11 (Unix). Então comecei a usar a OWL (ObjectWindows Library) da Borland, um framework de aplicações para C++. Era uma maravilha de programar; mas os programas ficavam bem maiores, e um pouco mais lentos, que os tradicionais... mesmo considerando que a linguagem usada era eficiente – embora os compiladores da época fossem relativamente imaturos.
Essa história teve um final triste: a OWL enfrentou concorrência da MFC (Microsoft Foundation Classes), biblioteca similar da Microsoft, que era bem pior – porém, mais eficiente (não por qualquer mérito: só devido ao grau de abstração e design OO bem inferiores). A vantagem de desempenho foi um dos motivos pelos quais a MFC varreu a OWL do mapa, monopolizando até hoje o desenvolvimento de aplicações nativas para Windows.
Posteriormente a Borland descontinuou a OWL em favor da sua sucessora VCL, criada para o Delphi (que também usei brevemente), depois usada também pelo C++Builder. O projeto open source OWLNext continua o suporte à OWL, para benefício de aplicações OWL legadas. Achei curioso o comentário no site owlnext.org: “OWLNext é um framework OO, criado sobre a Windows API sem adicionar muito overhead”. De fato, o que era considerado “muito overhead” lá por 1995, hoje em dia é “pouco overhead”. Isso é um efeito tanto da evolução dos frameworks (aposto que a MFC moderna é muito mais “pesada” que a original), quanto das CPUs cada vez mais rápidas e compiladores com otimizações cada vez mais eficientes.
Figura 2. O Java PC, mostrando a capacidade da JVM.
