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 e contratti di supporto supportati e simili che piace a molti ambienti aziendali).
Molti ambienti di produzione Java sono attualmente in esecuzione su un server applicazioni . Questa sarebbe la prossima considerazione. Il confronto Wikipedia dei server delle applicazioni Java EE mostra quale versione di Java EE è supportata. Ciò è ulteriormente visibile nella panoramica sulla compatibilità JavaEE di Oracle . La configurazione testata per JBoss Enterprise Application Platform 6 è contro Java SE 6.0 aggiornamento 6u30. L'aggiornamento 6u30 di Java SE 6.0 è anche la configurazione testata per JBoss Application Server 7.1.0 Final . Questi potrebbero funzionare in Java 7, ma non sono configurazioni testate.
Espandendosi sul server delle applicazioni, esistono strumenti di analisi del codice live che vengono utilizzati per eseguire il debug dopo il fatto. Debugger onnisciente (vedi anche) e Dynatrace ne sono due esempi. 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 funzionare (come in un nuovo JRE), non funzioneranno.
Successivamente in fondo c'è il framework . Un esempio di questo è JAXB che viene fornito con Java e Spring che lo utilizza. Passando a Java 7 è stato aggiornato JAXB che ha generato codice incompatibile con alcuni framework (che richiede che vengano aggiornati e che le loro dipendenze debbano essere aggiornate ...).
Gli strumenti di costruzione sono i prossimi nell'elenco. Uno dovrebbe assicurarsi che l'ambiente di compilazione stia utilizzando la versione corretta di Java. Scrivere codice per Java 7 ma non aggiornare la versione utilizzata da Maven o Ant causerebbe quindi problemi. Ci sono momenti in cui gli strumenti di compilazione stessi sono fortemente 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 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 non lo è) (consultare le librerie di copertura del codice open source per jdk7 ). Ciò potrebbe richiedere una modifica agli script di build per passare da uno all'altro.
Poi c'è l' IDE . Uno dovrebbe aggiornare l'IDE a una versione che è a conoscenza delle nuove strutture nella lingua. L' annuncio del supporto di Eclipse per Java 7 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 impiegato del tempo per entrare nella mentalità delle nuove strutture disponibili. Allo stesso modo le collezioni rielaborano in 1.2 e allontanano gli sviluppatori dall'uso di HashTable e Vector. L'aggiornamento della versione dovrebbe essere accompagnato da una certa quantità di formazione nelle nuove strutture linguistiche.