Artigo Java Magazine 32 - Tira Dúvidas

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

Clique aqui para ler esse artigo em PDF.

Edições do Java e JavaScript

Estou querendo aprender a programar em Java e ficar bem informado sobre o assunto assinando a revista Java Magazine, mas antes gostaria de tirar algumas dúvidas. Qual a diferença entre J2ME, J2SE, J2EE e JavaScript?

Bruno S.R.

J2ME, J2SE e J2EE (que recentemente perderam o "2", passando a ter as abreviações JME, JSE e JEE) são edições da plataforma Java. Uma edição especifica recursos fundamentais e APIs disponíveis para um determinado ambiente de execução.

O Java Micro Edition (Java ME ou JME) volta-se a dispositivos com pouca memória e poder de processamento reduzido, em geral alimentados por bateria, como PDAs e celulares, além de outros tipos de hardware embarcados, como sensores e robôs industriais. O Java Standard Edition (Java SE ou JSE) é utilizado em desktops e servidores, para executar aplicações Java ou desenvolver estas aplicações. Muitos recursos disponíveis no JSE não estão disponíveis no JME, porque não seriam comportados em computadores mais simples do que um PC. A Java SE tem a condição especial de ser o coração da tecnologia Java; dele dependem, pelo menos em parte, as outras plataformas. O Java Enterprise Edition (Java EE ou JEE) é voltado a ambientes corporativos de rede, como servidores web e clusters. O JEE acrescenta ao Java SE vários recursos específicos para aplicações que rodam em servidores em vez de na máquina do usuário final.

Finalmente, o JavaScript não tem relação significativa com Java. O nome dessa linguagem, que foi criada pela Netscape, era originalmente "Livescript" sendo modificado para JavaScript quando o navegador web da empresa passou a suportar applets Java. Considera-se que o novo nome foi uma jogada de marketing, pegando carona na fama de Java, e não uma mudança tecnológica. Avaliando-se superficialmente, JavaScript tem algumas semelhanças com Java, por exemplo na sintaxe – mas na prática Java e JavaScript são linguagens muito diferentes.

Grandes volumes em memória

Tenho acompanhado os artigos de Osvaldo Doederlein sobre performance, threads e collections em Java, e de início gostaria de parabenizá-lo pela excelente qualidade dessas matérias.

Estou iniciando um estudo para migrar para Java um processo feito hoje em PowerBuilder, que demora em média uma hora. Tenho quatro fontes principais de dados para este processo: dados principais, ex. contratos (300 mil registros); dados de prestações (4 milhões de registros) e dados de rendas (400 mil registros).

Hoje o processo em  PowerBuilder recupera estes dados por cada contrato em tabela do DB2. A solução imaginada seria gerar arquivos textuais com os dados e armazená-los em objetos Hashtable. Entretanto, para as prestações o código original utiliza vários recursos do PowerBuilder, como filtros e ordenação – e a classe Hashtable não possui esses recursos.

É válida, em Java, essa estratégia de manipular grandes quantidades de dados em memória? Caso positivo, como simular com alta performance as funcionalidades faltantes nas classes de coleções?

Israel Santiago

israel.santiago@mercantil.com.br

Obrigado pela apreciação! Quanto ao seu problema, entendo que a idéia é carregar todos esses registros na memória de um só golpe, o que é bem mais rápido que fazer uma consulta para cada registro e então fazer seu processamento todo em memória.

Sobre a manipulação de grandes volumes de dados, não se preocupe. O Java agüenta com tranqüilidade o processamento de milhões de objetos em memória de uma só vez. Já escrevi aplicações que exigiam heaps de alguns gigabytes para executar tarefas semelhantes à sua, que exigiam ler milhões de registros de uma vez, sem encontrar problemas. Logicamente, com estes grandes volumes de heap, você precisa ter bastante RAM e configurar bem a JVM. Use profilers e opções como -verbose:gc. Assim, quando o uso de memória estiver próximo do limite, será fácil ver quais objetos estão enchendo o heap – e a partir daí a solução do problema pode ser simples.

Há excelentes profilers open source, como o Hyades para Eclipse ou o NetBeans Profiler. E se for usado hardware de 64 bits e SMP, melhor ainda, pois o modelo de memória de 64 bits é mais eficiente para heaps grandes (mesmo quando não se passa dos limites de 32 bits), e o multiprocessamento permite usar recursos de garbage collection paralelo e concorrente." [...] continue lendo...