Considerações sobre qual versão Java executar na Produção


14

Algumas pessoas executam o que há de mais avançado em tecnologias - atualizando no dia em que algo é atualizado. Na produção, isso não é tão apropriado.

Pesquisando se a versão atual (Java 7) está pronta para produção produz uma quantidade significativa de material antigo que pode não estar mais correto (no momento em que escrevo este artigo, o Java 7 está fora há um ano e meio, o que parece bastante longo) .

Que considerações eu preciso fazer para determinar se é apropriado atualizar o ambiente de produção para uma versão posterior do Java?


Mesmo se fosse, qualquer biblioteca / plug-in de terceiros que seja usada (se houver) no referido aplicativo também precisaria ser compatível com o Java 7 (negócios arriscados).
Arin17

2
Sim. O único problema que encontrei é que não consegui instalar o Java 7 no Red Hat Enterprise Linux 4, mas, em seguida, esse sistema operacional é obsoleto. Eu o uso na produção em qualquer outro lugar há cerca de 6 meses, sem problemas.
GlenPeterson

@arin: não com Java, na verdade não. Tende a ser ridiculamente compatível com versões anteriores.
Michael Borgwardt

@MichaelBorgwardt em teoria, concordo com você, mas no ambiente de teste, vi bibliotecas de terceiros causarem comportamento / falhas erradas em nosso código de teste, mesmo após a atualização para uma atualização de versão pequena.
Arin 17/01

@arin: claro, isso pode acontecer. Mas, na minha experiência, é tão raro que há menos motivos para ter medo de atualizar o Java do que alterar quase qualquer outra coisa (especialmente o próprio código).
Michael Borgwardt

Respostas:


11

A primeira pergunta a fazer é "A versão do Java é suportada na máquina?" Embora a atualização do JRE seja uma coisa, pode ser que o SO subjacente não seja suportado executando a nova versão do Java (certificações e contratos de suporte suportados e similares que muitos ambientes corporativos gostam de ter).

Muitos ambientes de produção java estão realmente em execução em um servidor de aplicativos . Essa seria a próxima consideração. A comparação da Wikipedia de Java EE App Servers mostra qual versão do Java EE é suportada. Isso pode ser visto em mais detalhes na visão geral de compatibilidade do JavaEE da Oracle . A configuração testada para o JBoss Enterprise Application Platform 6 é contra a atualização 6u30 do Java SE 6.0. A atualização 6u30 do Java SE 6.0 também é a configuração testada para o JBoss Application Server 7.1.0 Final . Eles podem funcionar no Java 7, mas não são configurações testadas.

Expandindo no servidor de aplicativos, existem ferramentas de análise de código ativo que são usadas para depuração após o fato. Omniscient Debugger (veja também) e Dynatrace são dois exemplos disso. Esses aplicativos funcionam instrumentando (modificando) o código de byte ativo da execução do java para reportá-lo novamente. Como esses aplicativos funcionam modificando o código de byte, se o código de byte mudar de uma maneira com a qual eles não são capazes de trabalhar (como em um novo JRE), eles não funcionarão.

A seguir, estão os frameworks . Um exemplo disso é o JAXB que vem com java e Spring que o utiliza. Mudando para JAXB atualizado do Java 7, que gerou um código incompatível com algumas estruturas (o que requer que eles sejam atualizados e que suas dependências precisem ser atualizadas ...).

As ferramentas de compilação são as próximas na lista. Seria necessário garantir que o ambiente de construção esteja usando a versão adequada do Java. Escrever código para Java 7, mas não atualizar a versão usada pelo Maven ou Ant, causaria problemas. Há momentos em que as próprias ferramentas de construção estão fortemente vinculadas a uma versão com plugins específicos.

Ferramentas de teste . Coisas como PMD, findbugs e checkstyle podem não reconhecer novas estruturas em uma nova versão do Java - elas podem ficar muito confusas com instruções de troca de string ou capturas compostas. Ferramentas que entram na instrumentação, como cobertura de código, podem não funcionar na nova JVM. No contexto do Java 7, Cobertura e Emma não foram atualizadas para o novo JRE (novamente, esses aplicativos modificam o código de bytes para ver qual código é executado e o que não é) (consulte as bibliotecas de cobertura de código-fonte aberto para jdk7 ). Isso pode exigir uma alteração nos scripts de construção para alternar de um para outro.

Depois, há o IDE . Seria necessário atualizar o IDE para uma versão que esteja ciente das novas estruturas no idioma. O anúncio de suporte do Eclipse para Java 7 mostra esses problemas.

Por último e certamente não menos importante, é o desenvolvedor . Cabe ao desenvolvedor escrever o novo código e estar ciente de como o código pode ser reestruturado. Passando do Java 1.4 para 1.5, foram introduzidos modelos e anotações e levou tempo para os desenvolvedores entrarem na mentalidade das novas estruturas disponíveis. Da mesma forma, as coleções retrabalham novamente no 1.2 e afastam os desenvolvedores do uso do HashTable e Vector. A atualização da versão deve ser acompanhada de uma certa quantidade de treinamento nas novas estruturas de idiomas.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.