Artigo Java Magazine 65 - Java: Uma perspectiva

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

O artigo faz uma profunda investigação das plataformas Java SE e ME, uma visão do seu futuro próximo e traz uma porção de curiosidades.

Esse artigo faz parte da revista Java Magazine edição 65. Clique aqui para ler todos os artigos desta edição

Java: Uma perspectiva

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? Em The Feel of Java, Gosling resumiu sua visão numa sentença famosa: Java is a blue collar language – “Java é uma linguagem de colarinho azul”. Uma linguagem pragmática: criada para evoluir a tecnologia, mas mantendo o foco nas necessidades e na realidade do desenvolvimento de software profissional, de larga escala.

 

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 em desempenho. Por exemplo, a Swing implementa a pintura de todos os componentes, ao invés de pedir ao toolkit nativo do S.O. que faça isso. Mas oferece portabilidade total, facilidade de customizar a pintura de qualquer componente, e uma API sofisticada para programar GUIs. É uma troca. Veja o quadro “Uma Historinha de OO x Desempenho”.

 

Uma Historinha de OO x Desempenho

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?