Come giustificare la migrazione da Java 6 a Java 7?


28

Stavamo migrando da Java 6 a Java 7 . Il progetto è in ritardo e rischia di essere abbandonato, nel qual caso continuerà a utilizzare Java 6.

Quali sono i miglioramenti specifici di Java 7 con cui potremmo tornare dal nostro manager e convincerlo che è importante usare JDK 7? Alla ricerca di correzioni di bug che potrei evidenziare in Oracle Java 7 (rispetto a Java 6). Le correzioni in termini di sicurezza, prestazioni, 2D 2D / stampa, ecc. Saranno più vendibili nel mio caso. Le correzioni del compilatore, ad esempio, non serviranno molto.

[Sto visitando molti siti come la guida all'adozione di Oracle , il database dei bug, le domande su Stack Overflow].

Aggiornamento: grazie per le risposte. Abbiamo riprogrammato l'aggiornamento alla prossima versione. Il più vicino che abbiamo avuto è stata la sicurezza. Accettare la risposta più votata.


5
Sei fortunato. A giudicare dalle domande che ancora appaiono regolarmente su Stack Overflow , alcune persone sono ancora bloccate con Java 1.4 (una piattaforma di 11 anni!).
Joachim Sauer,

3
Perché stai eseguendo l'aggiornamento ora se non conosci già alcune funzionalità di 7 di cui hai bisogno? Forse stai sprecando il tuo tempo e dovresti pensare un po 'di più a capire se dovresti giustificarlo piuttosto che come dovresti giustificarlo.
Bryan Oakley,

1
Sono solo io o il titolo è indietro?
Radu Murzea,

1
La domanda più grande è: perché stai facendo un aggiornamento così difficile? Sono stato in grado di aggiornare un progetto di un milione di loc in una settimana a Java 7. Penso che la risposta ai tuoi problemi sia analizzare perché stai facendo un così duro aggiornamento.
Andrew T Finnell,

2
@ Andrew Finnell: mi dispiace. Non pensavo fosse così rilevante. Il porting effettivo è stato completato in meno di una settimana. Abbiamo usato principalmente api proprietarie del sole. Era un codice interessato dalla compatibilità specifica della funzione rispetto al numero effettivo di righe di codice (circa 4 milioni). Il ritardo causato era dovuto a vari fattori come il supporto degli strumenti, ad esempio la copertura del codice tramite cobertura 2.0. si sta solo stabilizzando. Un altro strumento era Rational Functional Tester che richiedeva un aggiornamento (abbiamo scelto di non farlo). Forse scriverò una nota sui fattori generali che hanno influenzato lo sforzo.
Jayan,

Risposte:


44

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 devi solo sostituire le installazioni Java 6 con Java 7 e tutte le applicazioni continueranno a funzionare senza problemi. Naturalmente questo non è garantito e si raccomandano test approfonditi per confermare che non ci saranno effettivamente problemi.


2
quella dovrebbe essere una risposta accettata. Il ragionamento basato su EOL ha dimostrato di funzionare meglio per me ogni volta che era necessario giustificare particolari aggiornamenti del prodotto, in particolare Java. Per completare la giustificazione, aggiungerei anche la nota sulla compatibilità binaria all'indietro (preferibilmente il backup con qualche dichiarazione ufficiale Oracle) e una nota sulla necessità di fumare test dell'aggiornamento (nel caso, ad esempio, di alcune dipendenze impreviste su riferimenti codificati alla versione " 6 "in application configs)
moscerino del

1
è sostanzialmente l'unica ragione per cui la maggior parte delle aziende eseguirà l'aggiornamento.
jwenting

Michael, avrebbe senso aggiungere note che ho citato ( chiarimenti sulla compatibilità e i test del fumo ) nella tua risposta? per completezza per così dire
moscerino

1
@gnat: fatto, anche se dubito che le persone che sono contrarie alla migrazione debbano essere informate della necessità di test e piuttosto di qualcosa di più che di fumo. A volte ci sono sicuramente incompatibilità gravi.
Michael Borgwardt,

@MichaelBorgwardt bene, raccontarlo è una cosa un po 'complicata e ha più a che fare con l'essere irresistibile piuttosto che tecnicamente corretto. Per uno ho imparato un modo piuttosto difficile per dichiarare cose del genere in modo esplicito e chiaro quando ci sono ragazzi "di fronte al cambiamento". Questo tipo di segnale invia loro "ascoltiamo e condividiamo le tue preoccupazioni e anche noi ci preoccupiamo", le fa sentire apprezzate (anziché ignorate) ... e alla fine porta a una più facile approvazione della modifica :)
moscerino

29

In generale, ci sono una serie di modifiche abbastanza ampie per rendere le cose più facili per il 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 della caldaia, e quindi abbiano più tempo per pensare all'obiettivo reale di ciò che stanno implementando, dovrebbe aumentare l'efficienza, ridurre i bug, ecc., che può essere un argomento molto potente. Oracle ha un elenco abbastanza ampio di modifiche , ma è piuttosto lungo, quindi riassumerò il più possibile.

Le funzionalità della lingua includono:

  • Meno boilerplate su Generics. Il 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 codice diventa un po 'più breve e più veloce da leggere.
  • Le stringhe funzionano ora nelle istruzioni switch , usando la semantica del .equals()metodo anziché ==.
  • Gestione automatica delle risorse tramite prova con risorse. Ciò rende il codice più pulito, ma presenta anche un vantaggio rispetto al codice try / finally basato su vecchio stile. Se viene generata un'eccezione nell'istruzione try, e poi un'altra durante la chiusura, il codice che utilizza le istruzioni try / finally tradizionali perderà completamente l'eccezione originale e passerà solo a quella lanciata nel blocco finally. In un'istruzione try-with-resources, il runtime sopprimerà l'eccezione generata dalle chiamate close () e distribuirà l'eccezione originale nello stack, presupponendo che questa eccezione originale sia quella che ha causato tutti i problemi nel primo posto. Inoltre, invece di abbandonare l'altra eccezione al Garbage Collector, questa soppressione consente di recuperare le eccezioni ravvicinate utilizzando Throwable.getSuppressed.
  • I letterali numerici possono essere più facili da leggere. Tutti i letterali numerici consentono i caratteri di sottolineatura , quindi cose come int n = 1000000000possono essere rese molto più leggibili int n = 1_000_000_000, il che è molto più facile da analizzare come un miliardo e più difficile da scrivere in modo errato senza accorgersene. Inoltre, nel modulo sono consentiti valori letterali binari0b10110101 , rendendo il codice che funziona con i campi di bit un po 'più piacevole da leggere.
  • La gestione di più tipi di eccezione nella stessa dichiarazione catch può essere eseguita, riducendo la duplicazione del codice e potenzialmente facilitando il refactoring in seguito.

Ognuna di queste modifiche è qualcosa a cui il tuo manager potrebbe non interessarti direttamente, ma rende un po 'più semplice scrivere il codice corretto senza troppi sforzi e pensieri, liberando la tua mente per concentrarti un po' di più sulla logica reale che stai provando da implementare e rendono anche più semplice la lettura del codice in un secondo momento, rendendo il debug un po 'più veloce.

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

  • Per quanto riguarda la sicurezza , diversi metodi di crittografia sono stati aggiunti / deprecati, poiché la crittografia si sposta sempre in avanti.
  • Il file IO è stato modificato, ( questo potrebbe essere un collegamento migliore, tuttavia ) aggiungendo una migliore astrazione in un numero di posizioni. Personalmente non mi sono tuffato nella nuova roba di IO, ma sembra una revisione molto utile, rendendo molto più facile lavorare con il filesystem senza troppa fatica.
  • Il supporto Unicode dipende da Unicode 6.0, insieme a numerosi altri miglioramenti all'internazionalizzazione.
  • Java2D , che hai citato nella tua domanda, è stato migliorato. Migliore supporto per i font Linux, migliore rendering X11 su macchine moderne e gestione degli script tibetani.

1
Nit pick: In effetti switch stringa funziona "come se stesse usando il String.equalsmetodo" (dal documento a cui ti sei collegato). In realtà, il compilatore è libero di ottimizzare in modo che String.equalsnon venga utilizzato ... purché l'effetto netto sia lo stesso. (E, mi aspetto che avrebbe usato String.hashcodesopra un certo numero di casi di switch.)
Stephen C

Abbastanza vero. Alla maggior parte dei compilatori è consentito fare un sacco di ottimizzazioni che non cambiano la semantica, quindi è spesso ridondante sottolineare piccole cose del genere; Avevo menzionato specificamente .equals () per essere esplicito che il caso non è ignorato. Tuttavia, ho aggiornato un po 'la formulazione.
Billy Mailman,

Le opzioni di stringa non sono consigliate poiché si passa a un dominio non associato. Accendere Enums è una tipica via di mezzo qui perché puoi avere una rappresentazione simile a una stringa, ma con significato semantico. Oh e +1 per la risposta completa BTW.
Martijn Verburg,

Quali sono i vantaggi dell'utilizzo di stringhe in un'istruzione switch anziché in costanti intere?
Giorgio,

3
l'unico motivo commerciale tra questi potrebbe essere il miglioramento della sicurezza. Gli aspetti tecnici sono discutibili e assolutamente irrilevanti per gli uomini d'affari.
jwenting

8

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

Aggiungerò che valgono la pena di spostare anche le nuove funzionalità di astrazione dei file NIO.2 e le funzionalità asincrone se l'applicazione dispone di funzionalità I / O di file / rete.


Stanno anche riducendo la quantità di PermGen necessaria e usando invece Heap o memoria nativa, non sono sicuro su dove verrà archiviato ora. Ciò significa che con Java 8 non sarà necessario impostare due parametri di memoria massima.
Andrew T Finnell,

Provare-con-risorse non è uguale a provare-finalmente ma con meno boilerplate?
jhewlett,

1
Penso che l'idea sia che meno boilerplate significhi che è più facile ottenere il risultato giusto.
MatrixFrog,

1
Meno piastra della caldaia e smeantics di chiusura corretta. Hanno scoperto che all'interno dell'OpenJDK lo stavano facendo manualmente in modo errato circa i 2/3 del tempo ... Sospetto che altre percentuali elevate di questo in altri corpus di codice.
Martijn Verburg,

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.