Considerazioni su quale versione Java eseguire in produzione


14

Alcune persone gestiscono il limite delle tecnologie, aggiornando il giorno in cui qualcosa viene aggiornato. In produzione, questo non è appropriato.

Ricercare se la versione corrente (Java 7) è pronta per la produzione produce una quantità significativa di vecchio materiale che potrebbe non essere più corretto (al momento della stesura di questo documento Java 7 è uscito da un anno e mezzo e sembra molto lungo) .

Quali considerazioni devo prendere per determinare se è appropriato aggiornare l'ambiente di produzione a una versione successiva di Java?


Anche se lo fosse, qualsiasi libreria / plug-in di terze parti utilizzato (se presente) in detta applicazione dovrebbe essere OK anche con Java 7 (attività rischiosa).
Arin,

2
Sì. L'unico problema che ho riscontrato è che non sono riuscito a installare Java 7 su Red Hat Enterprise Linux 4, ma che il sistema operativo è obsoleto. Lo sto usando in produzione ovunque da circa 6 mesi senza intoppi.
GlenPeterson,

@arin: non con Java, non proprio. Tende a essere ridicolmente compatibile verso il basso.
Michael Borgwardt,

@MichaelBorgwardt in teoria sono d'accordo con te, ma in ambiente di test ho visto librerie di terze parti causare comportamenti / arresti anomali nel nostro codice di test anche dopo l'aggiornamento a un aggiornamento di versione ridotta.
Arin,

@arin: certo, può succedere. Ma nella mia esperienza è così raro che ci sono meno motivi per avere paura di aggiornare Java che di cambiare quasi qualsiasi altra cosa (specialmente il proprio codice).
Michael Borgwardt,

Risposte:


11

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.

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.