Com JDK7, OpenJDK e IcedTea todos evoluindo em paralelo pode confundir sobre como esses projetos relacionam entre si. David Herron, que é OpenJDK Quality Lead, tenta traçar a reta e explica porquê o JDK7 tem demorado tanto tempo.
David começa descrevendo as diferenças entre OpenJDK 6 and JDK 6:
OpenJDK 6 começou como um "fork" do OpenJDK 7, e a equipe retirou o código do OpenJDK7 até setornar compatível com a especificação Java6 verificado pela suíte de testedo JCK.
A questão a fundo é que o OpenJDK 6 funciona muito bem, várias distribuições Linux estão usando-o como seu JDK, que pode ser utilizado para passar a suite de testes do JCK6b, o que significa que o OpenJDK 6 pode ser usado para construir um JDK compatível, e infelizmente é essa desvio evolutivo de que esperamos que venha ser relativamente curto. Ele serve para uma finalidade que é ter uma OpenJDK totalmente aberta e compatível com Java 6
Ele en seguida foi explicando a relação sobre OpenJDK e IcedTea:
Parece que alguma pessoas realmente gostam mais de digitar "./configure" do que configurar variáveis de ambiente e rodar "make". O projeto IcedTea originalmente começou devido ao caráter incompleto do OpenJDK (lacunas devido ao comprometimento) e à exigência de uma comunidade totalmente open source e baseada no código. IcedTea foi durante muito tempo um conjunto de patches aplicados ao OpenJDK, juntamente com um diferente sistema de build que é baseado em "./configure" como eu disse.
No OpenJDK temos substituído código confuso tal que não haja mais lacunas. Tal como temos feito, acredito que o projeto IcedTea esteja usando todos patches do OpenJDK. Uma coisa boa parece ser que o script configure do IcedTea faz o build facilmente do OpenJDK em muitos modos diferentes, como usar o Zero Assembler port para suportar compilação no non-x86/sparc chipsets, etc.
Uma grande parte que o IcedTea fornece é uma infra-estrutura plugin/java-web-start. Não fomos capazes de abrir o fonte de nosso plugin e é claro para o 6u10 nós rescrevemos completamente o plugin. Espera-se que disponibilizaremos open source o novo plugin no projeto OpenJDK mas ao meu conhecimento a decisão não foi escrita em pedra.
David sugere que JDK7 e OpenJDK7 terão (quase) códigos bases idênticos:
… o plano é que começando com OpenJDK7/JDK7 o código base será quase idêntico. É obviamente caro manter um fork, e se o JDK7 estiver divegindo fortemente do OpenJDK7 isso fará duas coisas: a) ser muito caro, b) minar nossos esforços em um ecossistema de código aberto.
Mas "quase idêntico" significa que terão algumas diferenças.
Lembra-se daquelas lacunas devido ao comprometimento? Algumas daquelas lacunas foram simples códigos que não pudemos disponibilizar open source como de Maio de 2007 mas temos desde então feito isso. Outras lacunas são para código que nós ainda temos obtido aprovação no (e.g. SNMP), mas existe algum código que deve ser substituição para open source, onde ainda usamos o velho código fonte. Trata-se essencialmente no tipo e rasterização de gráficos. O velho código fonte, sendo sobrecarregado, teve mais de 10 anos de correção e ajustes finos, etc e, para qualquer substituição para código fonte aberto para deslocar esse código no build do JDK produzido, terá uma rápida, estável e boa qualidade com o código existente.
A entrega do fonte OpenJDK, JavaFX e uma escassez global de recursos são, de acordo com David as razões para o JDK7 demorar tanto:
Se tivéssemos seguido padrões normais de entrega, o JDK7 já estaria sendo usado. Isso é, o Java6 seria lançado em dezembro de 2006 pelo padrão normal de 8-24 meses. Os principais lançamentos, como o JDK7, teria sido lançado de 2-5 meses atrás. O que aconteceu?
Por exemplo, obtendo quase completo o fonte OpenJDK entregue em maio de 2007, houve um grande esforço de várias pessoas. Mas houve também alguns anúncios no JavaOne em maio de 2007 (uma pequena coisa chamada JavaFX) que também virou um maior repensamento do Java (como alguns tem dito, esse não é o pai do Java) e também uma grande parte de trabalho para realizar.
Em outras palavras em vez de produzir o JDK7 nós fizemos o JDK6u10 e JavaFX.
Créditos similares sobre como o JavaFX abrangendo a evolução da plataforma, também foram feitas por Joe Winchester em um recente editorial para o Java Developers Journal onde ele compara a adoção de linguagens dinâmicas e tecnologias como JavaFX pelo Java, aos esforços da equipe do Smalltalk na década de 90, para fazer o java rodar na sua VM (chamada de Universal VM). O autor afirma que, como no caso do Smalltalk seria muito melhor concentrar a atenção no próprio Java "em vez de inchar e cortar a JVM".
É importante notar que com a Administração da vida do OpenJDK estamos nos aproximando do fim, existem aqueles como Neal Gafter que estão concentrados nessa nova composição:
O concelho diretivo do OpenJDK, tendo tido sua vida prorrogada por um ano, porém está agora agendado para dissolver em quatro meses, com duas das suas posições não-Sun restantes a preencher. A última reunião publicada foi de abril de 2008, em que foi acordado que o GB iria lutar por um projeto de Constituição até o final de 2008.
Quem é o sétimo membro dessa administração? Podemos ver as atas das reuniões após abril, e obter um relatório de status sobre a Constituição?
O que você pensa sobre JDK da Sun e o futuro do Java Open Source?