piano di migrazione premuroso per applicazioni Java5 / java6 per Java 7?

Question

Attualmente sto indagando se ha senso di ritardare un po 'minore pianificato refactoring lavoro e combinarlo con la migrazione verso Java 7, ma io sono un po' preoccupato che potrebbe rendere più difficile rintracciare le cause di alcuni bug se sia il codice e cambiamento piattaforma allo stesso tempo.

Il vantaggio del movimento sarebbe la capacità di ripulire e migliorare molte cose IO-correlati nella applicazione con NIO.2.

Ho tutte le fonti necessarie delle applicazioni e le relative librerie (se sarebbero necessari cambiamenti). Considerando che Java 7 ha solo alcuni piccoli miglioramenti - dopo che la maggior parte degli aggiornamenti VM sono già in Java 6 e le variazioni più grandi come chiusure o Chainsaw vengono cancellati - dovrebbe essere sufficientemente stabile per usarlo dopo pochi mesi, a destra

Answer 1

  

Attualmente sto indagando se ha senso di ritardare un po 'minore pianificato refactoring lavoro e combinarlo con la migrazione verso Java 7

Bene, c'è ancora molta incertezza sul programma Java 7, come ha recentemente spiegato da Mark Reinhold (Chief Architect del gruppo piattaforma Java di Oracle) su il suo blog e sul OpenJDK mailing list :

  

E 'stato chiaro da tempo che la più recente JDK 7 programma di sviluppo è, per usare un eufemismo, non realistico.

     

(...)

     

Il nostro presente migliore stima è che siamo riusciti a completare, di prova, e stabilizzare il lavoro previsto in tempo per un rilascio verso la metà del 2012.

     

(...)

     

La nostra attuale stima di questo “Piano B”   è che abbiamo potuto spedirli una ridotta JDK 7   a metà del 2011 e JDK 8 nel secondo   metà del 2012.

     

Per riassumere:

Plan A:     JDK 7 (as currently defined)                     Mid 2012
Plan B:     JDK 7 (minus Lambda, Jigsaw, and part of Coin)  Mid 2011
            JDK 8 (Lambda, Jigsaw, the rest of Coin, ++)    Late 2012

Quindi, nel migliore dei casi, Java 7 sarà lì a un po 'meno di un anno e Java 8 (con i grandi cambiamenti) in un po' più di due anni. E nel peggiore dei casi, Java 7 sarà lì a un po 'meno di due anni.

  

Il vantaggio del movimento sarebbe la capacità di ripulire e migliorare molte cose IO-correlati nella applicazione con NIO.2.

Per la parte successiva (NIO.2), avrete bisogno di Java 7. Ma per l'ex parte (fino pulito), non v'è alcuna IMO buone ragioni per attendere se si ottiene benefici immediati, soprattutto in considerazione l'incertezza del Java 7 programma.

  

Considerando che Java 7 ha solo alcuni piccoli miglioramenti - dopo che la maggior parte degli aggiornamenti VM sono già in Java 6 e le variazioni più grandi come chiusure o Chainsaw vengono cancellati - dovrebbe essere sufficientemente stabile per usarlo dopo pochi mesi, giusto?

In primo luogo, anche se la comunità sembra favorire Plan B , non c'è nulla di scritto nella pietra in modo da non basare una decisione su di esso. In secondo luogo, anche se Sun ha sempre cercato di massimizzare la compatibilità ascendente tra le versioni Java e alle piattaforme stabili di offerta, non posso prevedere il futuro :) E anche se sono abbastanza fiducioso, alcune aziende conservatori probabilmente aspettare un po '(a prescindere dal scenario scelto).

Bibliografia

• Ripensare JDK 7 da Mark Reinhold (Chief Architect del gruppo piattaforma Java di Oracle)
• Ripensare JDK 7 da Mark Reinhold (Chief Architect della piattaforma Java Gruppo a Oracle)