Atualizações menores geralmente são correções de bugs e atualizações de segurança, portanto, elas devem sempre ser aplicadas. Isso é especialmente uma preocupação com qualquer VM Java que se comunica com o mundo externo (serviços da Web e clientes). Atualizações importantes (1.5 a 1.6, 1.6 a 1.7) são geralmente compatíveis com versões anteriores. Isso é algo pelo qual o Java tem sido realmente confiável desde sua criação.
A compatibilidade com versões anteriores é geralmente a principal preocupação, e os aplicativos ou plataformas (por exemplo, Eclipse, Tomcat) que dependem de novos recursos Java (por exemplo, genéricos Java 5, anotações Java 6, expressões lambda Java 8) geralmente decisão de grandes atualizações de plataforma em nossa loja. Como um exemplo, você pode achar que os clientes Java 6 subitamente não conseguiram acessar alguns sites HTTPS desde os últimos meses devido à resposta à vulnerabilidade SSL de logging , que levou muitos administradores da web a atualizar seus certificados SSL para chaves de 2048 bits, um tamanho de chave que o Java 6 não suporta, mas um que o Java 7 e 8 suportam .
No passado, geralmente havia uma janela de três a cinco anos em que duas ou três versões principais diferentes de Java são de uso geral, até que algum recurso crítico, como os listados acima, indique uma mudança para uma versão mais recente.
Nosso ambiente de desenvolvimento ainda está direcionando o Java 6 onde necessário (para clientes OS X mais antigos), Java 7 para novos desenvolvimentos e Java 8 para nosso ambiente de servidor. Basicamente, queremos um ambiente de produção estável baseado no Java 8 antes de começarmos a confiar nos recursos do Java 8 em nosso ambiente de desenvolvimento. A compatibilidade retroativa do Java nos dá muito tempo para fazer essa transição.
Para o Java 6, acredito que a falta de suporte 1024DH é o prego no caixão.