Quando è Java 6 fine vita? (Nel contesto della scrittura di strumenti per sviluppatori)

Question

Sfondo

Questo non è così ovvio da capire come si potrebbe pensare.

Prima di tutto, mentre Oracle has stopped public support of Java 6 as of Feb 2013 ma con il supporto Premier in uscita a dicembre 2013 e il supporto esteso fino a dicembre 2016, c'è un po 'di coda lunga. Inoltre, c'è supporto per il supporto che potrebbe andare avanti per sempre.

La prossima importante vendor di Java, IBM, does not seem to have even posted an end of support for Java 6 (ed è ancora supporti Java 5 fino a settembre 2013!)

In terzo luogo, abbiamo di Apple: con il momento più recente di patch nel giugno 2013 e come "the company does not spell out its support policies in black and white" sembra si pensi a chiunque ... ma se la gestione di Java 5 può essere utilizzata come base, potremmo vedere altri 18 mesi circa ... alla fine del 2014-ish?

Infine abbiamo OpenJDK ... che Red Hat have said they will now be supporting ...

E non sto nemmeno Come iniziare a considerare i other JVM implementations solo quelle più comuni osservati in natura!

Quindi, da quello che posso vedere, finora, fino a quando si hanno i soldi per pagare Oracle/IBM/Red Hat è possibile continuare a ottenere una versione di Java 6 che è supportato a tempo indeterminato ...

Forse possiamo cominciare a inquadrare questa domanda un po 'meglio, e ottenere la possibilità di una risposta non a tempo indeterminato:

• Se non è possibile acquistare il sistema hardware/operativo che la specifica JVM funziona su qualsiasi altro, poi quello specifico JVM continua ad essere supportato è un po 'un punto controverso. I contratti di supporto esteso sono per i clienti esistenti, che probabilmente soddisfano i loro bisogni esistenti con i loro sistemi esistenti ... e se non possono cambiare a uno più nuovo

  Questo effettivamente ci dà un certo contesto su Apple ... come Apple l'hardware è supportato per 5 anni (7 se in California) quindi l'unico hardware Apple supportato dovrebbe essere basato su hardware x86 poiché lo switch è stato completato da Dec 2006 (being the last PPC based Apple hardware to ship), quindi in realtà non ci si deve preoccupare delle versioni di Apple Java che girano su PPC, come

  Analogamente, è possibile escludere eventuali versioni di Java eseguite su versioni precedenti di Windows. Il che significa che arriva Apr 2014 se il programma di installazione di Java non verrà eseguito su Windows 7 o versioni successive, quindi possiamo effettivamente ignorare che la versione di Java è supportata su Windows XP?

• Il mio vero interesse è quando gli strumenti di sviluppo possono far avanzare la loro versione Java minima.

  Jenkins ha mantenuto il supporto con Java 5 per qualche tempo, ma le modifiche più recenti significano che 1.520+ richiede Java 6 o più recente sul master e sugli slave. Ciò può causare problemi se alcuni degli slave di build, ad es. hardware legacy, non può eseguire JVM più recenti.

  Maven ha avuto una lunga storia di che ti permette di sborsare una JVM fino a J2SE 1.3 per l'esecuzione di test di unità, ma come di Surefire 2.15 sarà solo supportare l'esecuzione di unit test su a partire da Java 5.

  javac is moving to a 1 and three back politica in termini di -source e -target ... quindi dovremo aspettare fino a JDK 10 prima che il supporto del file sorgente di Java 6 venga rilasciato da javac ...con una cadenza di rilascio di 2 anni e Java 8 programmato per il rilascio all'inizio del 2014, ciò implicherebbe JDK9 all'inizio del 2016 e JDK10 all'inizio del 2018 ... ma JDK9 sarebbe disponibile con la manutenzione pubblica per altri 3 anni, il che significa che un po 'di tempo nel 2019 è quando la compatibilità del codice sorgente JDK 6 potrebbe essere abbandonata.

Domanda

C'è una data precisa che può essere utilizzato per stabilire quando toolchain di sviluppo OSS possono rilasciare il supporto per la pre-Java 7 JVM, e ciò che è quella data?

La distinzione OSS è importante in quanto gli sviluppatori OSS in genere non dispongono di finanziamenti per l'acquisto di contratti di supporto di tipo esteso/premium/di supporto e molto probabilmente non hanno accesso all'hardware oscuro/mainframe.

Aggiornamento: By "rilasciare il supporto per la pre-Java 7 JVM" Voglio dire che sarebbe stato sicuro per compilare l'intera toolchain con -target 7 vale a dire che il bytecode richiede Java 7 per l'esecuzione.

Aggiornamento 2: Questo dovrebbe, come incorniciato, essere una domanda rispondente basata sui fatti. La risposta corretta dovrebbe essere sia della forma

risposta chiara, ecco un link per "alcune persone che stanno fornendo aggiornamenti gratuiti per OSS persone su Java 6" e non hanno detto quando si fermeranno ancora.

o

Sì, c'è una data definitiva di AAAA-MM-DD e qui è la prova

Answer 1

C'è una data precisa che può essere utilizzato per stabilire quando I toolchains per sviluppatori OSS possono eliminare il supporto per JVM pre-Java 7 e qual è la data in questione?

No. Non esiste tale data.

Le persone che sviluppano catene di strumenti sono liberi di abbandonare il supporto per le versioni EOL di Java quando preferiscono ... o non lo fanno affatto. Ipoteticamente, se le persone (o le società) hanno stipulato accordi contrattuali con altre società (ad esempio i clienti) per fornire supporto per un determinato periodo, tali accordi ovviamente le vincolerebbero. Tuttavia, è improbabile che ciò limiti il ​​progetto nel suo complesso.

(Tuttavia, la praticità è che mantenere il supporto per le versioni precedenti di Java diventa sempre più difficile da sostenere. Gli sviluppatori vogliono/devono essere in grado di utilizzare le nuove funzionalità Java nel code-base del toolchain. casi in cui è possibile utilizzare la toolchain per sviluppare codice per Java precedente, ma è necessario eseguire la toolchain su Java moderno.)

Nel caso di versioni OSS del codice Java, l'utente (l'utente di Java) è in una posizione migliore:

• Non è probabile che sia un certo livello di comunità di supporto/sviluppo a lungo oltre il Po int a cui sarebbe commercialmente fattibile per fare questo.

• E se no, si ha accesso al codice sorgente in modo da poter (in teoria) supportare se stessi, o pagare qualcun altro per farlo per te.

---

Steve Conolly ha commentato:

La comunità OSS non può stipulare contratti di assistenza.

Questo è completamente sbagliato.

Chiunque nella comunità OSS può stipulare un contratto con l'utente per fornire supporto per un prodotto OSS. Questo è il modo in cui alcuni sviluppatori guadagnano il denaro che consente loro di continuare a sviluppare le loro cose.

Inoltre, tutte le principali licenze OSS consentono questo ... inclusa la GPL e tutte le sue varianti.

Ma se non è possibile per una comunità OSS far crescere gli sviluppatori perché non è possibile accedere alla tecnologia senza incorrere in costi, allora questo impone il supporto di pre-java 7 come impossibile.

Anche questo è sbagliato.

Sun (in precedenza) e ora Oracle offrono download gratuiti di versioni EOL delle versioni gratuite di Java ... fino a Java 1.1. EOL-ing non modifica la disponibilità. Si tratta in realtà della disponibilità di versioni patch di vecchie versioni di Java per problemi di sicurezza scoperti di recente e altri bug. Devi pagare per quello. (Abbastanza corretto, costa a Oracle i soldi per fare il lavoro.)

Il problema è che Java 5 e precedenti erano e non sono liberamente disponibili in forma di codice sorgente. Ciò significa che i clienti non hanno realisticamente la possibilità di risolvere (diciamo) i buchi di sicurezza in Java 5. Al contrario, in Java 6 hanno quell'opzione. Il codebase di OpenJDK 6 è stato rilasciato come open source e quello non può essere annullato. Inoltre, poiché Java 7 e Java 8 sono anche open source, le persone possono tenere traccia delle correzioni di sicurezza in Java 7 e 8 e tentare di eseguire il back-port delle modifiche alla base di codici OpenJDK 6 ...