Selecionamos aqui algumas das reações na web sobre a adoção do OpenJDK pelo Google para futuras versões do Android.
Escrevemos no final do ano passado que o Google decidiu substituir a implementação Harmony das bibliotecas Java usadas no Android pelo OpenJDK. Os detalhes podem ser encontrados aqui. Apesar do anúncio vir na época do Natal, a decisão do Google causou algumas reações na web, algumas das quais gostaríamos de resumir aqui.
A decisão do Google em mudar para o OpenJDK pode ser vista no código passado, pelo menos em fevereiro de 2015 de acordo com este ticket no Git. O commit de código que colocou esta questão sob análise da mídia em dezembro inclui uma importante mudança de licença. As novas bibliotecas Java para o Android N não são mais licenciadas sob a Apache License 2.0 (APL), mas sob a GNU GPL 2, e a nota sobre direitos autorais incluem a seguinte declaração: "Copyright (c) 1997, 2011, Oracle e seus afiliados. Todos os direitos reservados".
Andreas Gal, ex CTO na Mozilla, escreveu um post enfaticamente intitulado "Oracle afunda suas garras no Android", argumentando que o Google tem tentado por um longo tempo usar o Harmony e a licença Apache porque:
se pode usar e modificar o código sob a licença APL sem ter que publicar as alterações. Em outras palavras, pode-se fazer mudanças proprietárias e melhorias. Isso não é possível com o GNU libc, que está sob a LGPL. Tenho certeza que sei por que o Google pensou que isso é importante, porque como parte do lançamento do Firefox OS conversei com muitos dos mesmos fornecedores de chipsets e fabricantes que Google trabalha. Os fornecedores e fabricantes gostam de diferenciar no nível de software, tentando aperfeiçoar o código Android sobre todo o resto. Especialmente os fornecedores, que muitas vezes modificam o código das bibliotecas para tentar tirar vantagem de seus equipamentos proprietários, e não querem compartilham essas mudanças com o mundo. É o mote competitivo - a sua vantagem proprietária.
Comentando o post do Andreas Gal, Bob Ross, que se autodescreve como um empregado de uma empresa que fabrica equipamentos, é sútil em uma questão sobre o APL vs GPL:
Fazemos mudança no núcleo das bibliotecas. O problema com o código aberto, neste caso, seria a tremenda sobrecarga, não o sigilo, pelo menos para as mudanças que já participei.
Bradley M. Kuhn, atual presidente do Software Freedom Conservancy e membro do Conselho de Administração da Free Software Foundation, tem uma opinião diferente sobre a forma como GPL pode afetar o desenvolvimento Android. Em um post recente, "Sun, Oracle, Android, Google e a cópia do JDK", Kuhn chama a atenção para o fato de que OpenJDK está licenciado sob uma licença "extremamente fraca", GNU mais a Classpath exception. Kuhn estava envolvido no design e nomeando o Classpath exception que estava destinado a evitar a "contaminação" de todo o ecossistema Java com uma proteção copyleft que forçaria todos os programas em Java a serem livres para usar e redistribuir. E isso torna o uso do OpenJDK não muito diferente que o Harmony do ponto de vista da licença. De acordo com Kuhn:
Sendo assim, qual a diferença entre incorporar o JDK da Oracle mais a GPL Classpath exception do que ter uma licença Apache para o Java? Não é muito diferente! Os distribuidores Android tem rígidas obrigações copyleft no espaço kernel, e lembremos que o Webkit é LGPL; também há fracas obrigações de conformidade copyleft ao redor do Android. Assim, se um distribuidor já está atendendo aqueles, não é muito mais trabalho para atender aos já enfraquecidos requisitos adicionados agora ao código JDK incorporado.
Mas Andreas Gal considera que agora a Oracle tem uma importante influência sobre o futuro do Android, não só devido à licença, mas através do roadmap, marcas, acordos e patentes do Java:
Como a Oracle tem meios de controlar o Java além do código fonte, o OpenJDK é tão aberto como uma prisão. É possível votar em quão alto os muros são, e até mesmo ajudar na construção dos muros, mas é preciso a andar dentro dos muros, só a Oracle pode decidir quando e se pode sair. A Oracle detém grande parte do roadmap do OpenJDK, e através de requisitos de compatibilidade, marcas comerciais, acordos existentes, e processos de direitos autorais API (Oracle vs Google). A Oracle praticamente tem pleno controle dos rumos do OpenJDK.
Muitos leitores comentaram o post de Andreas Gal dizendo que se a Oracle não jogar limpo com o OpenJDK, nada impede o Google de fazer um fork, e direcionar o desenvolvimento da maneira que desejarem.
Gal também prevê um "ano difícil pela frente" para o Android:
Todo essa rotatividade de código e tecnologia terá implicações enormes para Android em termos táticos. Literalmente milhões de linhas de código estão mudando, e a nova implementação do OpenJDK frequentemente terá correções ou comportamento de desempenho sutilmente diferentes que o código do Harmony usado anteriormente pelo Google. Aqui é possível ver um teste atualizado do Google para uma condição específica na manipulação de data. O Harmony tinha um comportamento diferente do OpenJDK, e o teste teve que ser corrigido.
O ecossistema das aplicações executa em cima dessa areia movediça. A loja de aplicativos do Google tem milhões de aplicações que confiam nas classes padrão do Java, e assim como os testes tem que ser corrigidos, as aplicações irão parar aleatoriamente devido a mudança sútil que a transição para o OpenJDK traz.
Também imagino quanto tempo demorará para o Android N ser lançado no prazo, com mudanças dessa magnitude acontecendo nos bastidores. O Google está mudando os engines em pleno voo. A principal prioridade será a de não falhar. Eles não têm muito tempo para se preocupar sobre entregar no prazo.
Brendan Eich apoiou a opinião de Andreas Gal em um tweet: "Não sabemos muito ainda, mas concordo com o @andreasgal que as mudanças no código mostram o custo+risco aumentando".
Shai Almog, cofundador de Codename One, concordou que, de fato, há algum trabalho pela frente para o Google e os desenvolvedores Android, mas não tanto quanto
Andreas Gal e Brendan Eich sugerem, e há alguns benefícios provenientes da utilização OpenJDK:
Embora existam algumas mudanças que beneficiem diretamente os usuários, a maioria das mudanças de desenvolvimento de software não. Nem todos os desenvolvedores também se beneficiam de todos os recursos de linguagem/API.
Os usuários irão se beneficiar do fato que a base de código estará unificada e a auditoria de segurança agora vai se concentrar em uma base de código mais uniforme. Como resultado uma série de ferramentas Java podem funcionar melhor com o Android.
Sim, isso exigirá algum esforço do Google. Sim, algumas aplicações podem ser afetadas, aposto que isso seria muito menos do que os afetados pelas alterações do Marshmallow e o Google tem as ferramentas para aliviar uma série desses problemas (dicas de versão do sdk).
Algumas pessoas perguntam se a adoção do Google ao OpenJDK tem algo a ver com o processo que eles têm com a Oracle. Bradley M. Kuhn acredita que existem razões técnicas por trás da decisão do Google:
Um analista Java (com mais de uma década de experiência na área) me disse acreditar que a decisão foi principalmente técnica. Autores de aplicativos Android focados no usuário buscam (aparentemente) uma implementação mais recente do Java e dado que havia disponível um Software Livre razoavelmente licenciado, o Google fez uma opção técnica para base de código superior, como ele dá aos usuários da API tecnicamente o que eles querem ao mesmo tempo que reduzem a carga de manutenção. Isso parece muito razoável. Embora seja menos chocante do que o que os especialistas dizem, provavelmente razões técnicas foram o impulso primário.
Talvez seja muito cedo para avaliar completamente as implicações do Android usar o OpenJDK para futuras versões do sistema operacional. Isso depende muito da Oracle e o processo judicial em tramitação com o Google. Ainda não está claro se uma interface de API é protegida por direitos autorais ou não, e a lei e as cortes devem esclarecer isso. Partes do Android, ambos códigos Java e C, devem ser reconstruídos partindo de versões anteriores de bibliotecas e apagando o código para manter a interface ou os arquivos header. O Android é livre de problemas? Ainda não se sabe.. Adotando o OpenJDK deve aliviar alguns dos problemas, o Google agora tendo cobertura de licença e patentes Java, fornece subsídios para proteger o Android da Oracle.