Come giustificare la migrazione da Java 6 a Java 7?

Java 6 ha raggiunto EOL a febbraio di quest'anno e non riceverà più aggiornamenti pubblici (inclusa la sicurezza) a meno che non acquisti un supporto aziendale molto costoso.

Questo dovrebbe essere tutto il motivo necessario.

Inoltre, prove schiaccianti suggeriscono che la retrocompatibilità per i runtime Java è eccellente. È probabile che tu debba solo sostituire le installazioni di Java 6 con Java 7 e tutte le applicazioni continueranno a funzionare senza problemi. Ovviamente questo non è garantito e sono raccomandati test approfonditi per confermare che non ci saranno davvero problemi.

In generale, ci sono una serie di modifiche abbastanza ampie per semplificare le cose sul programmatore. Il tuo manager potrebbe non preoccuparsi troppo di queste cose, ma fare in modo che i programmatori trascorrano meno tempo a pensare al codice boilerplate, e quindi avere più tempo per pensare all'obiettivo reale di ciò che stanno implementando, dovrebbe aumentare l'efficienza, diminuire i bug, ecc. che può essere un argomento potente molto . Oracle ha un elenco abbastanza ampio di modifiche , ma è piuttosto lungo, quindi riassumeremo il più possibile.

Le funzionalità della lingua includono:

• Less boilerplate su Generics. codice Map<String, String> myMap = new HashMap<String, String>(); può essere ridotto a Map<String, String> myMap = new HashMap<>() . Il compilatore può dedurre i tipi generici necessari sul lato destro da sinistra, quindi il tuo codice diventa un po 'più breve e più veloce da leggere.
• Le stringhe funzionano nelle istruzioni switch , utilizzando la semantica del .equals() metodo invece di == .
• Gestione automatica delle risorse utilizzando try-with-resources. Ciò rende il codice più pulito, ma ha anche un vantaggio rispetto al vecchio codice try / finally-based. Se viene lanciata un'eccezione nella dichiarazione try, e poi viene lanciata un'altra, durante la chiusura, il codice che utilizza le istruzioni try / finally tradizionali perderà completamente l'eccezione originale e passerà solo quella che è stata lanciata nel blocco finally. In una dichiarazione try-with-resources, il runtime sopprimerà l'eccezione che le chiamate close () hanno gettato e bolla l'eccezione originale sullo stack, nel presupposto che questa eccezione originale sia quella che ha causato tutti i problemi nel primo posto. Inoltre, anziché abbandonare l'altra eccezione al garbage collector, questa soppressione consente di recuperare le eccezioni close-throw utilizzando Throwable.getSuppressed .
• I letterali numerici possono essere resi più facili da leggere. Tutti i valori letterali numerici consentono i trattini bassi , quindi cose come int n = 1000000000 può essere trasformato in un int n = 1_000_000_000 molto più leggibile, che è molto più facile da analizzare come un miliardo e più difficile da digitare in modo errato senza accorgersene. Inoltre, i valori letterali binari sono consentiti nella forma 0b10110101 , rendendo il codice che funziona con campi di bit un po 'più bello da leggere.
• Gestione di più tipi di eccezione int la stessa dichiarazione di cattura può essere eseguita , riducendo la duplicazione del codice e potenzialmente rendendo più semplice il refactoring in seguito.

Ognuno di questi cambiamenti è qualcosa a cui il tuo manager potrebbe non interessare direttamente, ma rende un po 'più facile scrivere il codice corretto senza tanti sforzi e pensieri, liberando la mente per concentrarsi un po' più sulla logica effettiva stai provando a implementare e rendono anche più semplice leggere il codice in un secondo momento, rendendo il debug un po 'più veloce.

Sul lato API, si sono verificati anche numerosi aggiornamenti API:

• Security-wise , sono stati aggiunti / deprecati diversi metodi di crittografia , come cripto si muove sempre avanti.
• File IO è stato modificato, ( questo potrebbe essere un link migliore, sebbene ) aggiungendo qualche astrazione migliore in un numero di punti. Non mi sono mai immerso personalmente nella nuova roba di I / O, ma sembra una revisione molto utile, rendendo molto più semplice lavorare con il filesystem senza la stessa pena.
• Supporto Unicode è fino a Unicode 6.0, insieme a un numero di altri miglioramenti di internazionalizzazione.
• Java2D , che hai menzionato nella tua domanda, è stato migliorato. Migliore supporto per font Linux, migliore rendering X11 su macchine moderne e gestione di script tibetani.

try-with-resources è una funzionalità che vale la pena di aggiornare a Java 7 per , tutto da solo. Perdite di risorse / perdite di memoria sono un grosso rischio nello sviluppo Java e TWR riduce significativamente il rischio.

Aggiungerò la nuova NIO.2 Astrazione dei file e funzionalità asincrone vale anche la pena spostarsi se l'applicazione dispone di funzionalità I / O file / rete.

Potrebbe esserci una ragione per cui dovresti non passare a Java 7: se devi utilizzare la VM di Oracle e il tuo software gira su hardware embedded o lo distribuisci con hardware embedded: Oracle è cambiato la licenza di JRE in modo che sia non concesso in licenza se sono soddisfatte le condizioni di cui sopra; dovrai acquistare una licenza integrata Java SE. Vedi Che cosa significa "sistema generico" per Java SE Embedded?