La prima domanda da porsi è "La versione di Java è supportata sulla macchina?" Mentre l'aggiornamento di JRE è una cosa, è possibile che il sistema operativo sottostante non sia supportato con la nuova versione di Java (certificazioni supportate e contratti di supporto e simili che molti ambienti aziendali preferiscono avere).
Molti ambienti di produzione Java sono effettivamente in esecuzione su un server delle applicazioni . Questa sarebbe la prossima considerazione. Confronto di Wikipedia di Java EE App Server mostra quale versione di Java EE è supportata. Questo può essere ulteriormente visto in panoramica sulla compatibilità JavaEE di Oracle . La configurazione testata per JBoss Enterprise Application Platform 6 è contro l'aggiornamento di Java SE 6.0 6u30. L'aggiornamento 6u30 di Java SE 6.0 è anche la configurazione testata per JBoss Application Server 7.1.0 finale . Questi possono funzionare in Java 7, ma non sono configurazioni testate.
Espandendoti sul server delle applicazioni, ci sono gli strumenti analisi del codice in tempo reale che vengono utilizzati per eseguire il debug dopo il fatto. Omniscient Debugger (vedi anche) e Dynatrace sono due esempi di questo. Queste applicazioni funzionano strumentando (modificando) il codice byte live di java in esecuzione per riportarlo ad esso. Poiché queste applicazioni funzionano modificando il codice byte, se il codice byte cambia in un modo in cui non sono in grado di lavorare (come in un nuovo JRE), non funzioneranno.
Il prossimo in basso è il framework . Un esempio di questo è JAXB che viene fornito con Java e Spring che lo usa. Passaggio a JAXB aggiornato di Java 7 che generava codice incompatibile con alcuni framework (che richiede che vengano aggiornati e che le loro dipendenze debbano essere aggiornate ...).
Strumenti di compilazione sono i prossimi nell'elenco. Uno avrebbe bisogno di assicurarsi che l'ambiente di costruzione stia usando la versione corretta di Java. Scrivere codice per Java 7 ma non aggiornare la versione utilizzata da Maven o Ant causerebbe problemi. Ci sono volte in cui gli strumenti di compilazione sono strettamente legati a una versione con plug-in particolari.
Strumenti di test . Cose come PMD, findbugs e checkstyle potrebbero non riconoscere nuove strutture in una nuova versione di Java - queste potrebbero essere molto confuse con le istruzioni switch di stringa o i catch di materiali composti. Gli strumenti che entrano nella strumentazione come la copertura del codice potrebbero non funzionare nella nuova JVM. Nel contesto di Java 7, Cobertura ed Emma non sono stati aggiornati al nuovo JRE (di nuovo, queste applicazioni modificano il codice byte per vedere quale codice viene eseguito e quale no) (vedi open delle librerie di copertura del codice sorgente per jdk7 ). Questo potrebbe richiedere una modifica degli script di compilazione per passare da uno all'altro.
Poi c'è IDE . Uno avrebbe bisogno di aggiornare l'IDE a una versione che è a conoscenza delle nuove strutture nella lingua. Il annuncio di supporto per Java 7 di Eclipse mostra questi problemi.
Ultimo e certamente non meno importante è lo sviluppatore . Spetta allo sviluppatore scrivere il nuovo codice ed essere consapevole di come il codice può essere ristrutturato. Passando da Java 1.4 a 1.5, sono stati introdotti modelli e annotazioni e gli sviluppatori hanno avuto bisogno di tempo per entrare nella mentalità delle nuove strutture disponibili. Allo stesso modo, le raccolte si rielaborano in 1.2 e impediscono agli sviluppatori di utilizzare HashTable e Vector. L'aggiornamento della versione deve essere accompagnato da una certa quantità di formazione nelle nuove strutture linguistiche.