Supporto di più versioni di Java nelle librerie OSS

Question

Supporto di più versioni di Java nelle librerie OSS

#1 da (5 voti)

1

Sono in procinto di alzare la mia prima lib Java OSS (GitHub / Maven) che una comunità di hardware open source farà un uso equo / moderato di

.

Sto scrivendo questa libreria con Java 8 e gestendo la sua build con Gradle 2.4. Più tardi quest'anno Java 9 sarà rilasciato e mi piacerebbe mantenere attivamente versioni separate della libreria (una per ogni versione della JVM) per diversi motivi:

Il supporto delle funzionalità e della lingua di Java 9 può portare a miglioramenti delle prestazioni e dell'API
Ma forzare la libreria a richiedere Java 9 pone indebite difficoltà a grandi applicazioni che non sono pronte ad aggiornarlo
Quindi supportando (ovvero, continuando a creare versioni periodiche per) sia in parallelo rende tutti felici

Sono combattuto tra la creazione di questi sottoprogetti di Gradle sotto lo stesso repository o il loro inserimento nei loro progetti di livello superiore. Quindi:

Un singolo myawesomelib progetto di primo livello con java8/ e java9/ sottoprogetti sotto di esso; o
Due progetti separati di myawesomelib-java8 e myawesomelib-java9 di livello superiore; o
Qualcos'altro?

La mia inclinazione è di andare con 2 progetti di primo livello separati a fini di CI (in modo che il commit a uno non inneschi le build sull'altro), ma non ho mai avuto a che fare con questo problema prima.

Quindi tutto questo per chiedersi: quali sono alcune tecniche comuni per gestire il supporto di più versioni di JVM nelle librerie OSS e quali sono le loro strutture in Gradle che possono aiutare a implementare queste tecniche?

open-source versioning java java8 gradle

posta smeeb 05.04.2016 - 11:40

fonte

1 risposta

Leggi altre domande sui tag open-source versioning java java8 gradle

Consenti ai client Xamarin di ascoltare quando il server invia un'API Come rompere il modello mentale degli oggetti

score 5 · Accepted Answer

Quali vantaggi porta Java-9 sulla tua attuale versione Java-8?

Intendo per la persona che usa la tua biblioteca.

Distribuire due versioni simultanee della stessa libreria ha MOLTE aspetti negativi. Hai bisogno di mantenere l'API compatibile tra i due? dovrai anche mantenere il codice due volte, correggere i bug due volte, perché inevitabilmente il codice mostrerà delle differenze. Se non ce ne sono, basta rilasciarlo in V8 e state tranquilli che funzionerà altrettanto bene con V9.

Generalmente quando si crea una libreria per un uso più ampio dei propri progetti si tende ad essere molto prudenti e supportare la versione più bassa possibile di Java che sia possibile. Hai bisogno di chiusure? usi NIO? no ? forse meglio restare fedeli a v6 anche e raggiungere un pubblico più ampio.

Il mio punto di vista personale su questo sarebbe cercare di avere una singola base di codice, rilasciata sotto la versione più bassa possibile di JDK che funzioni ancora e lo lasci perdere. L'uso di una libreria costruita sotto Java 6 sotto Java 8 funziona bene, quando arriva Java 9, funzionerà comunque senza problemi.

Se la tua biblioteca non deve essere utilizzata al di fuori del tuo progetto, puoi usare qualsiasi versione di JDK utilizzata dal progetto, ancora una volta, non mantenere due versioni separate, ma il doppio del lavoro con pochissimi benefici.

Ora, se devi supportare più versioni, ti consiglio di diramare le due versioni e mantenerle in questo modo, è naturale che i comuni strumenti VCS supportino (git, svn ecc.). Nessun layout di progetto funky da mantenere che supporti più ambienti di compilazione o che aggiri gli script di compilazione per vedere cosa compilare quando. Tuttavia, per me considerare che i benefici dovrebbero essere piuttosto consistenti.