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


28

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.


5
Você é sortudo. A julgar pelas perguntas que ainda aparecem regularmente no Stack Overflow , algumas pessoas ainda estão presas ao Java 1.4 (uma plataforma com 11 anos de idade!).
Joachim Sauer

3
Por que você está fazendo a atualização agora se ainda não conhece alguns recursos do 7 que precisa? Talvez você esteja desperdiçando seu tempo e deva pensar um pouco mais sobre se deve justificá-lo, e não como deve justificá-lo.
Bryan Oakley

11
Sou apenas eu ou o título está ao contrário?
Radu Murzea

11
A grande questão é: por que você está com dificuldades para atualizar? Consegui atualizar um projeto de um milhão de locais em uma semana para o Java 7. Acho que a resposta para seus problemas está analisando por que você está com tanta dificuldade em fazer a atualização.
Andrew T Finnell

2
@ Andrew Finnell: Desculpe. Não achei que fosse relevante. A transferência real foi concluída em menos de uma semana. Principalmente devido à API proprietária da Sun que usamos. Era um código afetado pela compatibilidade específica da função do que o número real de linhas de código (aproximadamente 4 milhões). O atraso causado ocorreu devido a vários fatores, como ferramentas de suporte - por exemplo, cobertura de código usando a cobertura 2.0. está apenas se estabilizando. Outra ferramenta foi o Rational Functional Tester, que exigiu um upgrade (optamos por não fazer). Pode ser que eu vou escrever uma nota em fatores globais afetou o esforço ..
Jayan

Respostas:


44

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.


2
essa deve ser uma resposta aceita. O raciocínio baseado na data da EOL provou funcionar melhor para mim sempre que havia necessidade de justificar atualizações específicas de produtos, principalmente o Java. Para completar a justificativa, eu também adicionaria a nota sobre compatibilidade com os binários anteriores (de preferência com alguma declaração oficial do Oracle) e a nota sobre a necessidade de testar a atualização (no caso de, por exemplo, algumas dependências inesperadas das referências codificadas à versão " 6 "nas configurações de aplicativos)
gnat

11
é basicamente a única razão pela qual a maioria das empresas atualizará.
Jwenting

Michael, faria sentido adicionar notas que mencionei ( esclarecimentos sobre compatibilidade e testes de fumaça ) em sua resposta? por uma questão de completude, por assim dizer
gnat

11
@gnat: done, embora eu duvide que as pessoas que são contra a migração precisam ser informadas sobre a necessidade de testes e muito mais do que apenas testes de fumaça. Definitivamente, às vezes existem sérias incompatibilidades.
Michael Borgwardt

@ MichaelBorgwardt bem, contar sobre isso é algo um pouco complicado e tem mais a ver com ser convincente do que tecnicamente correto. Eu aprendi uma maneira bastante difícil de declarar coisas assim de maneira explícita e clara quando há caras "contra a mudança". Esse tipo de sinal lhes envia "escutamos e compartilhamos suas preocupações, e também nos preocupamos", faz com que se sintam valorizadas (em vez de ignoradas) ... e, eventualmente, leva a uma aprovação mais fácil da mudança :)
gnat

29

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.

11
Nit pick: Na verdade, a opção de cadeia de caracteres opera "como se estivesse usando o String.equalsmétodo" (do documento ao qual você vinculou). Na realidade, o compilador é livre para otimizar para que String.equalsnão seja usado ... desde que o efeito líquido seja o mesmo. (E, eu esperaria que ele usaria String.hashcodeacima de um certo número de casos de switch.)
Stephen C

É verdade. A maioria dos compiladores tem permissão para fazer uma tonelada de otimizações que não mudam a semântica, por isso é muitas vezes redundante apontar pequenas coisas como essa; Eu tinha mencionado apenas .equals () especificamente para ser explícito que o caso não é ignorado. No entanto, atualizei um pouco a redação.
Billy Mailman

As alternâncias de string não são uma prática recomendada, pois você alterna em um domínio não vinculado. Ligar Enums é um meio termo típico aqui, pois você pode ter uma representação semelhante a String, mas com significado semântico. Ah e +1 para a resposta completa BTW.
28813 Martijn Verburg

Quais são as vantagens de usar strings em uma instrução switch em vez de constantes inteiras?
Giorgio

3
o único motivo comercial dentre esses podem ser os aprimoramentos de segurança. Os detalhes técnicos são discutíveis e totalmente irrelevantes para os empresários.
Jwenting

8

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.


Eles também estão reduzindo a quantidade de PermGen necessária e, usando a pilha ou a memória nativa, não tenho certeza de onde será armazenado agora. Isso significa que no Java 8 você não precisará definir dois parâmetros máximos de memória.
Andrew T Finnell

A tentativa com recursos não é a mesma que a tentativa finalmente, mas com menos clichê?
jhewlett

11
Acho que a ideia é que menos clichê significa que é mais fácil acertar.
MatrixFrog

11
Menos placa da caldeira e smeantics de fechamento corretos. Eles descobriram que dentro do OpenJDK estavam fazendo errado manualmente cerca de 2/3 do tempo ... Suspeito que outras porcentagens altas disso em outros corpus de código.
Martijn Verburg

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.