quarta-feira, 3 de agosto de 2011

Uma dura crítica a Oracle pelos Usuários Java

Texto de Andrew Binstock traduzido por ALJUG,

A noticia que houve erros no compilador Java HotSpot 7 começou a vazar rapidamente, mas o que realmente aconteceu foi uma ruim tomada de decisão da Oracle para enviar o compilador ciente de que os defeitos conhecidos causaria um ou dois tipos de erros: pendurar o programa ou silenciosamente gerar resultados incorretos. Dado que Java 7 levou cinco anos para ver a luz, parece-me, e para muitos outros, que a Oracle poderia ter esperado um pouco mais para corrigir o bug antes de liberar o software. Na grande maioria, há um sentimento na comunidade Java que a Oracle não entende Java (apesar da aquisição anterior da empresa BEA). Que pode ou não ser, mas eu teria esperado para compreender o software da empresa o suficiente para não enviar um compilador com defeitos.

O problema, pelo que se sabe até agora, deriva de um interruptor de otimização da linha de comando do compilador Java. Este switch de loops incorretamente otimizado , resultando em vários erros relatados. No Java 7, essa opção é ativada por padrão, enquanto ele estava desligado por padrão nas versões anteriores. Independentemente do estado do interruptor, as otimizações resultante não foram testados suficientemente.

Este é um problema curioso, porque os compiladores são um dos produtos mais comprovadamente fácil de testar. Arquivo de texto, fora do arquivo binário facilmente analisado. Ou no início do processo de compilação: arquivo de texto in, out AST. A geração de fácil entrada e validação simples de saída tornando possível criar literalmente dezenas de milhares de testes de regressão que podem explorar cada detalhe do código gerado de forma automatizada. Estes testes são conhecidos por ser especialmente importante no caso de otimizações porque os defeitos no código otimizado é muito mais difícil para os desenvolvedores localizar e identificar. O contrato implícito pelo compilador é que vai a partir do código de depuração durante o desenvolvimento de código otimizado para a liberação que não muda a funcionalidade. Conseqüentemente, otimizações devem ser testados com cuidado extra.

Mas mesmo se o teste da Oracle em casa não estava completa, eu tenho que saber porque eles não estavam testando o código em algumas das grandes bases de código open-source disponíveis no momento. Um programa que reportou o bug fatal foi Apache Solr, que a maioria dos desenvolvedores concordaria é um alto perfil, projeto open source. Projetos como Solr fornece bancos de ensaio quase ideal: uma base de código grande que é amplamente utilizado. Certamente, a Oracle não teria que decifrar para escrever UATs e outros testes para validar o que o compilador fez com o código Solr. Mas, na verdade, não tem que escrever um teste em tudo. Ele simplesmente são necessários para executar o pacote da falha de segmentação SIGSEGV.
Eu tenho a esperança de que este evento será uma lição afiada para Oracle para começar a usar os codebases que está à sua disposição como um terreno fértil para provar suas ferramentas. Enquanto o desleixo é perturbador, é agravada pelo fato de que os mesmos defeitos podem ser encontrados no Java 6. A razão, de repente, aparecem agora é que o interruptor de otimização está desativado por padrão no Java 6, enquanto que no Java 7 não está. Isto sugere que os testes da Sun não era melhor do que da Oracle. (E, dado que grande parte da equipe do JDK da Oracle é a mesma equipe que estava na Sun, esta não é uma surpresa.) A diferença crucial é que a Oracle sabia sobre os bugs antes do lançamento e foi adiante com o lançamento de qualquer maneira consciente dos problemas.

Decisão da Oracle era política, não técnica. E aqui a Oracle realmente precisa reavaliar seu compromisso com seus usuários. Java é uma tecnologia da empresa suficientemente importante .O futuro a longo prazo de Java, pelo menos a linguagem, está na balança.

Update: Os defeitos serão corrigidos na Java 7 Update 2. Claramente, sugerimos que esperem até que os navios da liberação sejam descaregados e é um conselho que dou para qualquer migração de projetos para esta versão.

Texto Original: Dr.Dobbs

Nenhum comentário:

Postar um comentário