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.