Como justificar a migração do Java 6 para o Java 7?

Estávamos migrando do Java 6 para o Java 7 . O projeto está atrasado e corre o risco de ser descartado; nesse caso, ele continuará usando o Java 6.

Quais são as melhorias específicas no Java 7 com as quais poderíamos voltar ao nosso gerente e convencê-lo de que é importante usar o JDK 7? Procurando correções de erros que eu poderia destacar no Oracle Java 7 (com relação ao Java 6). Correções em segurança, desempenho, Java 2D / impressão etc. serão mais vendáveis ​​no meu caso. As correções do compilador, por exemplo, não serão muito úteis.

[Estou passando por muitos sites, como o guia de adoção da Oracle , banco de dados de bugs, perguntas sobre o estouro de pilha].

Atualização: Obrigado pelas respostas. Remarcamos a atualização para o próximo lançamento. O mais próximo que chegamos era de segurança. Aceitando a resposta mais votada.

O Java 6 atingiu a EOL em fevereiro deste ano e não receberá mais atualizações públicas (incluindo segurança), a menos que você compre um suporte corporativo muito caro.

Essa deve ser toda a razão necessária.

Além disso, evidências esmagadoras sugerem que a compatibilidade com versões anteriores dos tempos de execução do Java é excelente. As chances são de que você apenas precise substituir as instalações do Java 6 pelo Java 7 e todos os aplicativos continuarão funcionando sem problemas. Obviamente, isso não é garantido e testes extensivos são recomendados para confirmar que realmente não haverá problemas.

Em geral, há várias alterações bastante amplas para facilitar as coisas do programador. Seu gerente pode não se importar muito com essas coisas, mas faz com que os programadores passem menos tempo pensando no código padrão e, assim, tenham mais tempo para pensar no objetivo real do que estão implementando, aumentando a eficiência, diminuindo bugs etc. o que pode ser um argumento muito poderoso. O Oracle tem uma lista bastante extensa de alterações , mas é bastante longa, então vou resumir o máximo possível.

Os recursos de idioma incluem:

• Menos clichê sobre os genéricos. O código Map<String, String> myMap = new HashMap<String, String>();pode ser reduzido para Map<String, String> myMap = new HashMap<>(). O compilador pode inferir os tipos genéricos necessários do lado direito da esquerda, para que seu código fique um pouco mais curto e mais rápido de ler.
• As strings funcionam nas instruções switch agora , usando a semântica do .equals()método em vez de ==.
• Gerenciamento automático de recursos usando tentativa com recursos. Isso torna o código mais limpo, mas também tem uma vantagem sobre o código antigo baseado em tentativa / finalmente. Se uma exceção for lançada na instrução try e outra for lançada durante o fechamento, o código que usa as instruções try / finalmente tradicionais perderá completamente a exceção original e passará apenas a que foi lançada no bloco finally. Em uma instrução try-with-resources, o tempo de execução suprime a exceção que o close () chama lançada e coloca a exceção original acima da pilha, supondo que essa exceção original seja a que causou todos os problemas no primeiro Lugar, colocar. Além disso, em vez de abandonar a outra exceção para o coletor de lixo, essa supressão permite que as exceções lançadas próximo sejam recuperadas usando Throwable.getSuppressed.
• Literais numéricos podem ser mais fáceis de ler. Todos os literais numéricos permitem sublinhados , portanto, coisas como essas int n = 1000000000podem ser transformadas em muito mais legíveis int n = 1_000_000_000, o que é muito mais fácil de analisar como sendo um bilhão e mais difícil de digitar incorretamente, sem perceber. Além disso, literais binários são permitidos no formulário 0b10110101, tornando o código que funciona com campos de bits um pouco mais agradável de ler.
• O tratamento de vários tipos de exceção na mesma instrução catch pode ser feito, reduzindo o código duplicado e potencialmente facilitando a refatoração mais tarde.

Cada uma dessas mudanças é algo com o qual seu gerente pode não se importar diretamente, mas facilita um pouco a escrita do código correto sem muito esforço e pensamento, liberando sua mente para se concentrar um pouco mais na lógica real que você está tentando para implementar e também facilitam um pouco a leitura do código posteriormente, tornando a depuração um pouco mais rápida.

No lado da API, várias atualizações de API também ocorreram:

• Em termos de segurança , vários métodos de criptografia foram adicionados / descontinuados, à medida que a criptografia avança sempre.
• O arquivo de entrada / saída foi alterado ( embora isso possa ser um link melhor ), adicionando uma abstração melhor em vários locais. Eu não mergulhei pessoalmente no novo material de IO, mas parece uma revisão muito útil, facilitando o trabalho com o sistema de arquivos sem muita dor.
• O Suporte Unicode é compatível com Unicode 6.0, juntamente com vários outros aprimoramentos de internacionalização.
• O Java2D , que você mencionou na sua pergunta, foi aprimorado. Melhor suporte a fontes Linux, melhor renderização X11 em máquinas modernas e manipulação de scripts tibetanos.

O try-with-resources é um recurso que vale a pena atualizar para o Java 7, por si só. Vazamentos de recursos / vazamentos de memória são um grande risco no desenvolvimento Java e o TWR reduz esse risco significativamente.

Acrescentarei os novos recursos de abstração de arquivo NIO.2 e assíncrono, também vale a pena mudar se o seu aplicativo tiver recursos de E / S de arquivo / rede.

Pode haver uma razão para você não mudar para o Java 7: se você precisar usar a VM da Oracle e seu software for executado em hardware incorporado ou você a distribuirá com hardware incorporado: a Oracle alterou a licença do JRE para que não seja licenciada se acima condições são atendidas; você precisará comprar uma licença incorporada do Java SE. Consulte O que significa "sistema de uso geral" para Java SE Embedded?