Versões baseadas em tempo do Java

Estamos todos familiarizados com o antigo, codificado emJEP 223. Esse esquema tornou os números de versão incrementais e retransmitiu informações extras.

Se executarmosjava -version em uma JVM para a versão 8 ou anterior, veremos algo como:

Nesse caso, podemos supor que seja para o Java 6, que está correto, e a 27ª atualização, que está errada. O esquema de numeração não é tão intuitivo quanto parece.

As versões secundárias eram múltiplas de 10 e as versões de segurança preenchiam todo o resto. Normalmente, veríamos a string curta anexada às nossas instalações locais, comoJDK 1.8u174.. A próxima versão pode serJDK 1.8u180, que seria uma versão secundária com novas correções.

O novo esquema de string de versão será “recast version numbers to encode not compatibility and significance but, rather, the passage of time, in terms of release cycles,”according to Mark Reinhold in the JEP.

Vamos dar uma olhada em alguns:

À primeira vista, isso parece ser um versionamento semântico; however, this is not the case. 

Com o controle de versão semântico, a estrutura típica é$MAJOR.$MINOR.$PATCH, mas a nova estrutura de versão do Java é:

$FEATURE is what we might think of as the major version, mas aumentará a cada seis meses, independentemente das garantias de compatibilidade. E$PATCH é para versões de manutenção. Mas é aqui que as semelhanças param.

Primeiro,$INTERIM é um espaço reservado, reservado pela Oracle para necessidades futuras. For the time being, it will always be zero.

E, em segundo lugar,$UPDATE is time-based like $FEATURE, updating monthly após o lançamento do recurso mais recente.

E, finalmente, zeros à direita são truncados.

Isso significa que11 é o número do lançamento do Java 11, lançado em setembro de 2018,11.0.1  é seu primeiro lançamento de atualização mensal em outubro e11.0.1.3 seria um hipotético terceiro lançamento de patch da versão de outubro .

Simplificando, o Java agora tem um canal rápido, a cada seis meses, e um canal lento, a cada três anos. Cada versão do terceiro ano é chamada de versão LTS.

No canal rápido, o idioma libera recursos na incubação. Esses recursos de idioma estabilizam na versão LTS.

Portanto, para empresas que podem adotar a volatilidade em troca de usar novos recursos, elas podem usar o canal rápido. Para empresas que apreciam a estabilidade e podem esperar para atualizar, elas podem atualizar a cada versão do LTS.

A experiência com versões do JDK permite que os desenvolvedores encontrem o melhor ajuste.

Também há, é claro, a questão do suporte. Agora que o suporte ao Java 8 terminou, o que fazemos?

E, conforme discutido anteriormente, a resposta vem em versões LTS,Java 11 being the most recent LTS release and 17 being the next. As atualizações estarão disponíveis e suportadas por fornecedores como Oracle e Azul.

Se podemos confiar no suporte da comunidade, Redhat, IBM e outros declararam seu apoio à aplicação de correções de bugs no OpenJDK. Além disso, o projetoAdoptOpenJDK fornece binários pré-compilados para OpenJDK.

Uma área de confusão para alguns é a diferença entre o OpenJDK e o Oracle JDK.

Na verdade, eles são quase idênticos, diferindo apenas em quais correções de bugs e patches de segurança foram obtidos,according to Brian Goetz.

OpenJDK acts as the source of most derived JDKs and remains free. A partir do Java 11, a Oracle cobrará taxas de licença comercial do Oracle JDK com suporte e serviços adicionais incluídos.

Com lançamentos mais frequentes, a fragmentação pode se tornar um problema. Hipoteticamente, todo mundo poderia estar executando em diferentes versões do Java, com recursos diferentes ainda mais do que agora.

Obviamente, a conteinerização pode ajudar a resolver isso. Do Docker e CoreOS ao OpenShift da Red Hat, a conteinerização fornece o isolamento necessário e não força mais um local de instalação do Java a ser usado no servidor.