Image Image Image Image Image
Scroll to Top

Topo

java 7

IcedTea, Harmony, IKVM e mais: altos e baixos do Java Open Source

Em 06, dez 2011 | Sem Comentários | Em Arquitetura, Blog, Java, Open Source | Por Allison

Este artigo traz um panorama de projetos open source relacionados com o coração da plataforma Java, e em que tem havido extremos de altos e baixos. Em outubro, o IcedTea liberou sua versão 2.0, baseada no OpenJDK 7, que já está disponível como o Java 7 oficial do Fedora e do Ubuntu Linux; em novembro a Apache anunciou que o Harmony estava sendo rebaixado para o “sótão” da Fundação. São dois exemplos (e dois extremos) de projetos trazendo novidades que poderão afetar o futuro da tecnologia Java, mesmo sem o apoio de gigantes como Oracle e IBM.

IcedTea

Quando a Sun liberou em 2007 os fontes da sua JVM e sua biblioteca de classes, criando o projeto OpenJDK, atual implementação de referência do Java 7, o resultado não era imediatamente usável pela comunidade open source, pois alguns componentes licenciados de terceiros não puderam ser abertos naquele momento. Exemplos de APIs que não foram incluídas no código inicial do OpenJDK são as de gerência de fontes tipográficas e de interação com dispositivos de som. Sem falar de complementos indispensáveis para algumas aplicações, como o plugin web para Applets e o Java Web Start, que embora sejam parte do produto da Sun e Oracle há tempos, cobrem funcionalidades não-padronizadas como parte do Java SE.

Para remediar esses problemas, a comunidade open source criou, com patrocínio da Red Hat, o projeto IcedTea. O objetivo era substituir os componentes proprietários necessários para compilação e execução do OpenJDK, pelos equivalentes em outros projetos open source, especialmente o projeto GNU Classpath.

Na verdade, já havia conversas entre membros importantes da comunidade open source e da Sun bem antes do lançamento do OpenJDK, e não foi acidente a opção da Sun pela licença GPL, em vez das licenças usadas no Glassfish e no extinto Open Solaris. O objetivo era permitir a mistura de código com o ecossistema do GNU Classpath, baseado na GPL.

Já há alguns anos, as distribuições do Linux incluem binários certificados do IcedTea, mas que são distribuídos usando o nome OpenJDK como parte de um acordo com a Sun para acesso ao TCK, o kit de testes de compatibilidade do Java.

Algumas distribuições ofereciam como alternativa o Java proprietário da Sun, empacotado nos repositórios “não-livres”, usando a licença DLJ (Operating System Distribution License for Java). Mas a DLJ foi descontinuada pela Oracle com a liberação do Java 7, não apenas para o novo Java mas também para as versões anteriores. Por isso o IcedTea se tornou o único Java certificado a ser fornecido como parte dos sistemas Fedora, Ubuntu e Debian, além de se tornar também o preferencial para uso em distribuições comerciais com RHEL e SuSE.

O escopo do projeto IcedTea aumentou desde a sua criação. Ele implementou melhorias sobre o OpenJDK, para melhor compatibilidade com o Linux, por exemplo o suporte ao PulseAudio para multimídia; e evoluiu para uso de JVMs alternativas, como a JamVM, entrando no lugar do HotSpot do OpenJDK original.

Ampliando o alcance do OpenJDK

A maior contribuição do IcedTea para o OpenJDK provavelmente foi os projetos Zero e Shark. O Zero é um interpretador genérico de alta performance, que torna o OpenJDK viável em várias plataformas embarcadas, em que o custo de memória e bateria de um compilador JIT seria proibitivo.

Já o Shark utiliza a infraestrutura do LLVM para criar um compilador JIT portável para múltiplas arquiteturas de CPU, evitando a necessidade de se escrever um novo JIT para cada arquitetura de processador. Graças a estes projetos o OpenJDK vem se tornando a implementação do Java preferencial em algumas CPUs populares em plataformas voltadas para a computação embarcadas, como ARM e MIPS.

Note que o IcedTea não é um fork do OpenJDK. Alguns dos seus contribuidores estão no Community Board do OpenJDK e vários dos patches do projeto migraram para o OpenJDK e se tornaram parte do Java 7 oficial.

Outra contribuição importante do IcedTea é um processo de compilação mais simples para o OpenJDK, reduzindo a barreira de entrada para potenciais contribuidores. O projeto OpenJDK não fornece binários para nenhuma plataforma, somente fontes. O JDK fornecido pela Oracle à partir dos fontes do OpenJDK usa uma licença proprietária. Mas, graças ao processo simplificado do IcedTea hoje é possível baixar, sob uma licença open source, binários para Windows no site do Open SCG, que é o mesmo grupo responsável pelo porte nativo do PostgreSQL para Windows.

A certificação do Java SE é realizada sobre binários, não sobre fontes, e os binários do IcedTea inclusos no Ubuntu, Fedora e derivados (como RHEL e CentOS) são certificados desde 2009. Mas os binários do OpenJDK 7/IcedTea 2 inclusos nas distribuições do Linux não são certificados ainda, e nem os fornecidos pelo OpenSCG para Windows. Ambas as comunidades estão trabalhando no processo, e estão em busca de patrocinadores.

Ainda há espaço para outras JVMs open source?

A criação do projeto OpenJDK diminuiu o incentivo a continuidade de vários projetos de JVMs open source. O SableVM foi uma das vítimas. O desenvolvimento do GNU Classpath, que fornecia a biblioteca de classes do Java SE para a maioria destes projetos, ficou congelado no Java SE 5, e o venerável Kaffe apenas recentemente voltou a ter atividade, sendo transferido para o Github.

Poderia ser argumentado que não há mais necessidade de outros projetos de JVMs open source, uma vez que a Sun abriu sua implementação, e ainda mais agora que a Oracle oficializou o OpenJDK como a implementação de referência (RI) para o Java 7. A competição trazida por estes projetos foi benéfica porque estimulou a evolução e a abertura do JDK pela Sun, mas qual seu papel no futuro do Java?

Na época o Classpath estava chegando perto do 100% do Java SE 5 e se tornaria certificável. Com dois Javas open source plenamente funcionais (GCJ+Classpath e Apache Harmony) ficaria complicado manter restrições ao TCK do Java SE, e mais importante, o fluxo de caixa originado pelo licensiamento do JDK da Sun para fabricantes de plataformas móveis e embarcadas. A criação do OpenJDK sob licença GPL permitiu unir esforços à comunidade open source, sem abrir o TCK para projetos externos.

Por outro lado, sem projetos open source independentes, deixa-se de explorar alternativas de design para a JVM, que poderiam atender a nichos específicos ou se tornarem importantes em plataformas futuras. O fato de smartphones e tablets atuais em sua maioria ignorarem a plataforma Java SE (e também a Java ME) mostra que essas alternativas podem estar fazendo falta.

Por exemplo, o GCJ, que é parte da suite de compiladores GCC, tem a opção de gerar código nativo (que não necessita de uma JVM para executar). Era uma opção interessante para aplicações desktop e sistemas embarcados, tanto que foi utilizado pelo RHEL e pela comunidade Fedora para suportar o Eclipse e o Tomcat, antes da criação do OpenJDK. Sem falar na ampla cobertura de arquiteturas de CPU e SOs do GCC, muito superior à suportada pelo Java “oficial” na época.

As releases recentes do GCC continuam suportando o GCJ, e ele continua sendo incluído nas principais distribuições do Linux; mas, infelizmente não parece haver planos para atualizar seu suporte à linguagem Java, nem para completar o GNU Classpath ou atualizá-lo para além do Java 5.

JVMs alternativas ao OpenJDK

O OpenJDK, no entanto, não parece ter diminuído o ritmo do JikesRVM, que tem o diferencial de ser escrito quase que inteiramente em Java. Infelizmente ele não tem a pretenção de ser uma JVM para “uso real”, seu objetivo é ser uma plataforma de testes para novos algoritmos internos à JVM para projetos acadêmicos.

Dois dos projetos baseados no GNU Claspath, o JamVM e o Cacao continuam vivos. Eles colaboram com o projeto IcedTea e hoje podem utilizar a biblioteca de classes do OpenJDK em lugar do GNU Classpath, voltando assim a acompanhar a evolução da plataforma oficial. Apesar de os seus releases mais recentes terem mais de um ano, existe grande atividade nos repositórios de código do JamVM e do Cacao, e espera-se para breve novos releases que finalmente atualizarão suas respectivas JVMs para compatibilidade com as novas versões do Java.

Ambos o JamVM e o Cacao são focados em plataformas embarcadas, explorando diferentes designs para componentes da JVM, como o coletor de lixo, o interpretador de bytecodes e o compilador JIT. A comunidade do JamVM afirma, por exemplo, que é possível gerar um executável da sua JVM ocupando menos de 100 Kb.


Java no .NET

Outro projeto de JVM open source que continua vivo e pode ser interessante para alguns nichos é o IKVM, que roda dentro do CLR do .NET ou do Mono, e permite convivência “sem costuras” entre código escrito em Java e código escrito em C#, VB.Net ou outras linguagens que rodam sob o CLR.

O IKVM também permite empacotar aplicações Java como assemblies nativas do .NET. O projeto ganhou certa popularidade entre desenvolvedores que gostariam de continuar tendo acesso a bibliotecas Java em um projeto .NET. É também o projeto mais atualizado em relação aos padrões do Java, pois já oferece um release candidate com suporte ao Java 7.

Com o fim do Harmony, como fica o Android?

A DalvikVM, que é a base das aplicações Android, é baseada na biblioteca de classes do Java SE fornecida como parte do Apache Harmony. Originalmente este projeto tinha apoio da IBM, que contribuiu com a maior parte do código para a biblioteca de classes, mas quando a IBM decidiu focar seus esforços no OpenJDK, o Harmony ficou “órfão”. O projeto Harmony foi oficialmente descontinuado pela Apache Software Foundation em novembro deste ano. Ao contrário do que muitos esperavam, o Google não assumiu o projeto, mantendo o desenvolvimento do Dalvik como um fork separado, provavelmente devido ao processo aberto pela Oracle por violação de patentes.

O Dalvik não é exatamente uma JVM, pois roda seu próprio bytecode, e usa uma arquitetura interna bem diferente da usada no OpenJDK, embora semelhante ao JamVM e ao CacaoVM. O desenvolvimento das aplicações para o Dalvik é feito na linguagem Java, e os bytecodes Java são convertidos em bytecodes Dalvik. Está disponível apenas um subconjunto da API do Java SE, embora maior do que o incluso no Java ME, mas o Dalvilk não traz nada do Java oficial para celulares, sendo incompatível com MIDP ou CDC. Recursos que seriam parte do Java ME são fornecidos por APIs proprietárias para o Android, ou por acesso a serviços do Google.

A omissão do Google quanto ao Harmony dá margem a dúvidas sobre qual será o futuro do “Java” no Android:

  • O Google vai continuar evoluindo o Dalvik usando ideias do Java, de modo similar feito pela Microsoft com o .NET?
  • Ou será o HTML 5 quem poderá provocar um futuro abandono do DalvikVM e Java no Android?

Qualquer que seja o futuro do Dalvilk, ele representa uma linha que poderia ter sido incorporada ao Java oficial e que garantiria a popularidade do Java na computação móvel. A disputa entre Google e Oracle não atende aos interesses da comunidade Java, e a recente ênfase no HTML 5 mostra bem como o mercado ainda carece de uma solução para desenvolvimento interoperável entre smartphones e tablets de diferentes fornecedores.

Serviços nativos do Linux

O exemplo do Dalvik mostra que, apesar da necessidade de funcionalidades independentes de plataforma, há também necessidade de se incorporar suporte a recursos nativos. O Java 7 já foi uma evolução nessa direção, com a nova API de filesystem do NIO2 e se pode argumentar que o Eclipse deve grande parte do seu sucesso ao toolkit gráfico SWT, também baseado no acesso a recursos nativos de Windows, Unix e Mac.

Novamente vemos que a comunidade open source traz novidades neste sentido, dentro do ramo da computação embarcada. Por exemplo, o BUG System e o OpenEmbedded fazem uso de APIs Java para acesso ao desktop Gnome e o D-Bus – efetivamente colocando o Java em pé de igualdade com o código nativo, no acesso aos recursos do SO e Desktop do Linux.

Em vez de criar todo um “universo paralelo”, como feito pelo Android, estes projetos buscam maximizar a utilidade de recursos já conhecidos dos desenvolvedores em plataformas embarcadas, e abrem espaço para a plataforma Java como “linguagem de sistema” para o Linux, viabilizando o desenvolvimento de aplicações de gerência de hardware sem recorrer diretamente a código nativo.

Conclusões

Podemos ver que, apesar do foco de grandes empresas no projeto OpenJDK, ainda há vários outros projetos open source com potencial de contribuir para a evolução da plataforma, especialmente em nichos ainda negligenciados pela plataforma oficial, como o de dispositivos embarcados. Vale a pena acompanhar o amadurecimento destes projetos, pois de um deles pode sair o diferencial competitivo para os produtos da sua empresa, ou surgirem evoluções importantes para a plataforma oficial do Java.

Fonte: Fernando Lozano/InfoQ

Tags | , , , , , , , ,

17

nov
2011

8 Comentários

Em Blog

Por Allison

Fedora Linux 16 em detalhes: foco em cloud computing

Em 17, nov 2011 | 8 Comentários | Em Blog | Por Allison

A comunidade Fedora lançou a versão 16 da popular distribuição do Linux. Entre as principais novidades, estão o suporte ao Kernel 3.1, Gnome 3.2 e KDE Plasma 4.7, além de várias melhorias em relação ambientes de nuvem e virtualização.

Embora seja tradicionalmente voltada para desenvolvedores de projetos open source, oferecendo as últimas atualizações (potencialmente instáveis) destes projetos, a distribuição Fedora vem também sendo reconhecida como uma boa distribuição para usuários domésticos e corporativos. A nova versão foi dedicada pela comunidade a Dennis Ritche, um dos criadores da Linguagem C e do Unix.

Recursos para nuvem

Vários recursos de cloud computing estão embutidos no novo Fedora, com destaque para:

  • Aeolus Conductor – Interface web para gerenciamento de ambientes de nuvem de vários fornecedores, públicos e privados, por exemplo Amazon EC2, Rackspace, VMWare VSphere e Eucalyptus.
  • OpenStack e Condor Cloud – Duas opções que fornecem infraestrutura completa para criação nuvens privativas.
  • HekaFS – Antigo GlusterFS, é um sistema de arquivos de cluster com recursos de multitenancy para nuvem e criptografia OpenSSL.
  • pacemaker-cloud – Extensão do pacemaker (para do Red Hat Cluster Suite) para gerenciar disponibilidade e fail-over de aplicações e recursos em nuvem.
  • Matahari – Coleção de APIs e agentes para monitoramento e gerenciamento de sistemas.

Virtualização e mudanças para o administrador de sistemas

O Fedora é a base para o desenvolvimento do RHEL (Red Hat Enterprise Linux) e suas distribuição derivadas, como o CentOS. Assim o administrador de sistemas corporativo (também conhecido como sysadmin) tem no Fedora uma prévia do que virá em versões futuras destas distribuições; por exemplo:

  • Capacidade de inspecionar o conteúdo de arquivos em imagens de VM (read-only), e o conteúdo do Windows Registry armazenado nestas imagens.
  • Suporte a Dom0 do Xen (parte do kernel 3.1), de modo que não é mais necessário usar um kernel modificado com o Xen Server da Cytrix, Oracle VM e outros produtos baseados no Xen. O Dom0 é o domínio que realiza todas as operações de entrada e saída, para os demais domínios (VMs); ou seja, é ele quem fornece os drivers para o hypervisor.
  • Mudanças no processo boot, que agora usa Grub2, permite particionamento utilizando GPT em lugar do antigo MBR do MS-DOS (fim dos limites de tamanho das partições!) e suporta o Trusted Boot da Intel, quando disponível no hardware. O antigo subsistema HAL para detecção de novo hardware foi descontinuado, sendo substituído pelo udev e serviços relacionados.
  • Chrony, novo servidor NTP mais tolerante a relógios imprecisos de PCs e sistemas que passam longo tempo desconectados da internet, como notebooks e VMs que ficam suspensas frequentemente.
  • Ike (Shrew Soft VPN Client), novo cliente VPN que facilita o uso do IPsec.

Também há suporte ao compartilhamento de dispositivos USB 2.0 do host com máquinas virtuais KVM. Isso, somado ao suporte a SPICE, torna o Fedora Linux uma plataforma melhorada para virtualização de desktop. Um dispositivo USB também pode ser compartilhado com outras máquinas em rede.

Novidades para o desenvolvedor

O Fedora Linux traz recursos importantes para o desenvolvedor corporativo. É a distribuição do Linux com suporte mais abrangente ao Eclipse e outros recursos para desenvolvimento Java, PHP, Python e Ruby.

Entre as novidades do Fedora 16 para desenvolvedores, podemos destacar:

  • BE (Bugs Everywhere) – Um bug tracker integrado a sistemas de controle de versões distribuídos, para simplificar a gerência e o rastreamento de mudanças.
  • btparser – Ferramenta para análise de backtraces do gdb.
  • D2 – Nova linguagem que tenta reunir as vantagens de Java e C++.
  • WSO2 – Framework de Web Services SOA e WS-* para C++.

O OpenJDK 7 também é oferecido, mas apenas como Technology Preview. O Eclipse, o Tomcat e outras aplicações Java continuam sendo compiladas com o Open JDK 6. O motivo é a falta de um TCK (kit oficial de testes de compatibilidade/aderência) para o Java 7, de modo que empresas que usam o Fedora em produção podem preferir usar os downloads (proprietários) da Oracle. (Também foram descobertas diversas pequenas incompatibilidades entre bibliotecas Java populares e o Java 7, que não puderam ser resolvidas a tempo para o lançamento do Fedora 16.)

Novidades para usuários finais

Para usuários finais, a grande novidade é a inclusão do Gnome 3.2, que continua despertando reações ame-ou-odeie pela sua nova interface com desktop limpo e suporte a tablets. Um destaque é o gerenciamento integrado de contas de serviços internet (Google, Facebook, Jabber etc.) e de serviços de armazenamento em nuvem.

Entre as novas aplicações inclusas no Fedora 16, podemos citar:

  • Routino – Navegação via OpenStreetMaps.
  • WriteType – Ajuda crianças a escrever corretamente, com predição de palavras, autocorreção e suporte a voz para leitura.
  • Ease – Software de apresentações baseado no Cutter, integrado ao Gnome 3 e com interface otimizada para tablets.

Obtendo e instalando o Fedora 16

É possível baixar imagens ISO para mídias live em CD ou pendrive, ou então baixar um DVD (.iso) contendo os principais pacotes para servidores e desenvolvimento. É possível também usar uma mídia para instalação a partir da internet. Além disso, já estão disponíveis imagens prontas para nuvens Amazon.

Quem já tem o Fedora 15 ou versões anteriores, pode fazer uma atualização diretamente pelo gerenciador de atualizações gráfico da distribuição, ou pela ferramenta preupgrade.

É importante lembrar que o Fedora não inclui softwares proprietários, como alguns drivers para placas Wi-Fi e vídeo NVidia, ou codecs para MP3. Mas estes são facilmente instalados usando o EasyLife (que em breve estará atualizado para o Fedora 16), ou então o repositório RPM Fusion (já atualizado). Usuários habituados ao Debian e Ubuntu podem consultar este Guia de Transição do Ubuntu para Fedora.

Fonte: Fernando Lozano/InfoQ

Tags | , , , , , , , , , , , , , ,

28

out
2011

Sem Comentários

Em Blog

Por Allison

Update para Java 7 corrige problemas com Apache Lucene

Em 28, out 2011 | Sem Comentários | Em Blog | Por Allison

Quando o Java 7 foi lançado, ele veio com uma falha: usado com Apache Lucene e Apache Solr, o Java 7 causava cálculos incorretos e travava a Java Virtual Machine. Lucene e Solr ficavam praticamente paralisados.

Agora, a Oracle confirmou oficialmente que algumas das falhas foram corrigidas no Java 7 Update 1.

O problema foi descoberto alguns dias antes do lançamento do JDK 7, mas não houve tempo para corrigi-lo.

Embora a atualização tenha ficado pronta há alguns dias, as notas de lançamento não continham informações sobre o status dos bugs. Agora as IDs das falhas foram liberadas: 7068051, 7044738 e 7077439; e apesar de o bug 7070134 não estar identificado, ele também foi corrigido.

A Oracle também atualizou as notas de lançamento, confirmando que quatro problemas relacionados a JIT e a loop foram corrigidos.

De acordo com Uwe Schindler, comitter para Apache Lucene e Solr, agora é seguro usar Lucene e Solr com o 7 Update 1. Entretanto, ele aponta que não é recomendável utilizar o XX:AggressiveOpts em qualquer JVM em uso de produção.

Informações publicadas originalmente em The H

Fonte: IMasters

Tags | , , , ,

11

set
2011

Sem Comentários

Em Blog

Por Allison

Trabalhando com closures no Java 8

Em 11, set 2011 | Sem Comentários | Em Blog | Por Allison

Criar em Java um simples Runnable ou ActionListener pode ocupar muitas linhas de código. A solução preferida dos programadores hoje é usar as classes anônimas do Java:

Runnable r = new Runnable() {

public void run() {

System.out.println(“Caelum”);

}

};

new Thread(r).start();

Depois de muitas propostas para closures no Java, a proposta atual de Lambdas para o Java 8 permite omitir a declaração do método, no caso de haver apenas um método abstrato naquela classe abstrata/interface (single abstract method):

Runnable r = #{System.out.println(“Caelum”)};

new Thread(r).start();

Mais ainda: o compilador consegue inferir um passo adiante, descobrindo que há um construtor em Thread que recebe como argumento uma interface que possui apenas um método abstrato. Repare que agora não precisamos escrever nem Runnable, nem run:

new Thread(#{System.out.println(“Caelum”)}).start();

Esses recursos, somados aos polêmicos defender methods (que permitem indicar “defaults” para métodos em interfaces), permitirão escrever lista.sortBy(#Usuario.getNome), muito mais sucinto do que invocar Collections.sort(lista, …) passando um  new Comparator() {…} que invoca

u1.getNome.compareTo().

Como rodar esses testes? O Java 7 está previsto já para junho, mas infelizmente não contemplará muitos dos esperados avanços na linguagem. Esses ficarão para meados de 2012, com o Java 8, mas você já pode experimentá-los. Para isso, precisa ter o Java 7 instalado (mac aqui). Depois precisa clonar o repositório do langtools:

hg clone http://hg.openjdk.java.net/lambda/lambda/langtools

Para compilar esse projeto, de dentro de langtools/make, executamos o ant passando referência para os diretórios de instalação do seu Java 6 e Java 7:

ant -Dboot.java.home=/usr/lib/jvm/java-6-sun -Dtarget.java.home=/algumdiretorio/jdk1.7.0 build-all-tools

Para compilar nosso código que utilize esses recursos do Java 8, precisamos do classes.jar gerado em dist/bootstrap/lib, que contem as classes necessárias para o compilador e também para a execução:

jdk1.7.0/bin/java -cp classes.jar com.sun.tools.javac.Main Classe.java

E para executar:

jdk1.7.0/bin/java -cp classes.jar:. Classe

Fonte: Paulo Silveira/Caelum

Tags | , ,

07

set
2011

Sem Comentários

Em Blog

Por Allison

Oracle Apresenta Java 7

Em 07, set 2011 | Sem Comentários | Em Blog | Por Allison

A Oracle Corporation trouxe à público o Java 7, incluindo atualizações de segurança, novos recursos e muitas melhorias significativas. O Java 7 está disponível no site da Oracle, junto com a versão de desenvolvedores (JDK). De acordo com o que consta nas notas de lançamento, a principal melhoria de segurança está relacionada ao JSSE (Java Secure Socket Extension) e comunicações TLS (Transporte Layer Security).

Sob a ótica da segurança, se o Java 7 for instalado em um sistema que já possui o Java6, as duas versões permanecem; ou seja, se o usuário deseja executar apenas a última versão, é necessário ter certeza de que tenha desinstalado quaisquer versões anteriores.

Fonte: Under-Linux

Tags | , , , ,

29

ago
2011

Sem Comentários

Em Blog

Por Allison

Ainda faltam ferramentas no Java 7

Em 29, ago 2011 | Sem Comentários | Em Blog | Por Allison

O Java 7, a primeira versão da plataforma de desenvolvimento aberto criada sob gestão da Oracle, foi lançada na última semana e pareceu não agradar usuários, que reclamaram da falta de alguns componentes prometidos inicialmente e de algumas falhas que poderiam estourar o compilador NullPointerException.

Para verificar o que há de errado com a nova versão do Java, o IT Web entrou em contato com o especialista em desenvolvimento para a plataforma Paulo Silveira, da Caelum. Segundo ele, inicialmente o Java 7 teria uma série de novidades, desde modularidade, com sistema de gestão integrada (SGI), até Off Closure, Defender Method e novidades para a inicialização de colections de forma mais sucinta.

Porém, ele afirmou que o atraso de mais de dois anos no lançamento da ferramenta fez com que a Oracle optasse por uma versão menos parruda do Java. “Alguém de dentro da Oracle disse que se a empresa fosse colocar todo o prometido dentro do pacote, o lançamento só iria ocorrer no final de 2012. Então o pessoal não quis esperar, porque já demorava quatro anos e iria levar mais outros dois”, pontuou. Silveira, explicou que, por isso, decidiram pela separação da plataforma de desenvolvimento aberto em duas versões: a que foi lançada na última semana e a Java 8, programada para o para inicio de outubro de 2012 com tudo o que falta.

Apesar das mudanças, ele garante que os desenvolvedores não vão sentir dificuldades de adaptação na nova plataforma. “De maneira alguma. Como todas as outras versões do Java ela é compatível com as anteriores. Então, tudo o que funcionava antes, funciona agora. Você pode continuar programando no Java 7 assim como fazia no Java 6.”

Quanto à falha com o compilador:

NullPointerException, Silveira revelou que a Oracle já tinha sido avisada pelos desenvolvedores de Apache Lucine de que não era compatível com o software, o que é um bug grande. Porém a empresa preferiu lançar a versão. O especialista explica como contornar esse bug. “Se você utilizar algumas opções por linha de comando para desabilitar algumas dessas otimizações mais agressivas, ele funciona perfeitamente, como da maneira antiga.” Segundo ele, a correção dessa falha já está prevista para a atualização do Java 7.

A reportagem procurou a Oracle para comentar o tema, mas até o fechamento da matéria, não obteve resposta.

Fonte: ItWeb

Tags | , , , , , ,

28

jul
2011

Sem Comentários

Em Blog

Por Allison

Especialista da Oracle lança Java 7 no Cesumar

Em 28, jul 2011 | Sem Comentários | Em Blog | Por Allison

O engenheiro sênior da Oracle nos Estados Unidos, Roger Brinkley, líder mundial da Comunidade Java ME, esteve na Cesumar para fazer o lançamento do Java 7, a mais recente versão dessa ferramenta utilizada na construção de sistemas web, móveis (celular, tablets), embarcados (videogames, televisões, robôs, carros) e corporativos.

Maringá foi uma das poucas cidades brasileiras privilegiadas com o lançamento. De acordo com o especialista, que passou por 11 cidades do país, Maringá esteve no roteiro de lançamento da nova ferramenta “por causa dos profissionais aqui existentes, que estão à frente da comunidade de usuários Java na região, e da ótima receptividade que sempre temos”.

Presente pela segunda vez na instituição, Brinkley fez palestra para estudantes, professores dos cursos de tecnologia da informação e profissionais da comunidade, discorrendo sobre as novidades do programa e as características brasileiras e regionais desse mercado.

As principais novidades introduzidas no Java 7 conforme explicou, são o framework Fork/Join, que permite aumentar o desempenho de aplicações Java aproveitando os múltiplos núcleos/processadores das máquinas atuais; o invokedynamic, que permitirá que linguagens dinâmicas possam executar de modo mais rápido na JVM; a nova sintaxe da linguagem para o gerenciamento automático de recursos de I/O; e outras melhorias introduzidas pelo Project Coin.

Brinkley disse ainda que duas razões colocaram o Brasil na lista dos países visitados para o lançamento do produto: uma foi o número de desenvolvedores Java e outra por causa dos esforços e do engajamento das comunidades de desenvolvedores no campo do Open Source, muitas vezes sem interesse comercial ou mesmo do governo.

Além de Maringá, receberam a visita do especialista Porto Alegre, São José do Rio Preto, Brasília, Goiânia, São Paulo, João Pessoa, Natal, Fortaleza, Salvador, Toledo (PR).

Fonte: imprensa@cesumar.br

Tags | , , , , , , , , , ,