OSGi, Java Modularity e Jigsaw

Quindi fino a ieri mattina non avevo la più pallida idea di cosa fosse OSGi. OSGi era solo una parola d'ordine che continuavo a vedere spuntare più e più volte, e così ho finalmente messo da parte un po 'di tempo per rispolverarlo.

In realtà sembra roba piuttosto interessante, quindi vorrei iniziare affermando (per la cronaca) che non sono anti-OSGi in alcun modo, né questa è una domanda "OSGi-bashing".

Alla fine della giornata, sembra che OSGi abbia - essenzialmente - affrontato JSR 277 su Java Modularity, che ha riconosciuto che ci sono carenze nella JARspecifica del file che possono portare alla risoluzione dello spazio dei nomi e problemi di caricamento delle classi in alcuni casi angolari. OSGi fa anche molte altre cose davvero interessanti, ma da quello che posso accertare, questa è la sua più grande attrazione (o una di queste).

Per me - in quanto sviluppatore Java EE abbastanza nuovo (da pochi anni a questa parte), è assolutamente sbalorditivo che siamo nel 2011 e che stiamo attualmente vivendo nell'era di Java 7 e che questi problemi di caricamento delle classi siano ancora presenti; in particolare negli ambienti aziendali in cui un server app potrebbe contenere centinaia di JAR, molti dei quali dipendono da versioni diverse l'uno dell'altro e tutti in esecuzione (più o meno) contemporaneamente.

La mia domanda:

Per quanto mi interessi di OSGi, e per quanto voglio iniziare a impararlo per vedere dove / se potrebbe essere utile ai miei progetti, non ho il tempo di sedermi e imparare qualcosa di così grande, almeno adesso.

Quindi cosa devono fare gli sviluppatori non OSGi quando si presentano questi problemi? Quali soluzioni Java (Oracle / Sun / JCP) esistono attualmente, se esistono? Perché il seghetto alternativo è stato tagliato da J7? Quanto è sicura la comunità che Jigsaw verrà implementato il prossimo anno in J8? È possibile ottenere Jigsaw per il tuo progetto anche se non fa ancora parte della piattaforma Java?

Immagino che quello che sto chiedendo qui sia una combinazione di panico, intrigo e facepalm. Ora che finalmente capisco cos'è OSGi, semplicemente non "capisco" come qualcosa come Jigsaw abbia impiegato più di 20 anni per giungere a buon fine, e poi come avrebbe potuto essere precaricato da una versione. Sembra fondamentale.

E, come sviluppatore, sono anche curioso di sapere quali sono le mie soluzioni, senza OSGi.

Inoltre, Nota : so che questa non è una domanda di tipo " programmazione pura ", ma prima che alcuni di voi si pieghino il naso, volevo affermare (di nuovo, per la cronaca) che ho deliberatamente posto questa domanda COSÌ. Questo perché non ho altro che il massimo rispetto per i miei compagni SO e sto cercando una risposta a livello architettonico da alcuni degli "Dei dell'IT" che vedo in agguato qui intorno ogni giorno.

Ma, per quelli di voi che insistono assolutamente che una domanda SO sia supportata con un segmento di codice:

int x = 9;

(Grazie a chiunque possa valutare questo OSGi / Jigsaw / classloader / namespace / JAR roba infernale!)

In primo luogo, comprendere che il caso d'uso principale di Jigsaw è la modularizzazione dello stesso JRE. Come obiettivo secondario offrirà un sistema di moduli che può essere utilizzato da altre librerie e applicazioni Java.

La mia posizione è che qualcosa come Jigsaw è probabilmente necessario solo per JRE, ma che creerà molti più problemi di quelli che afferma di risolvere se utilizzato da altre librerie o app Java.

Il JRE è un caso molto difficile e speciale. Ha più di 12 anni ed è un pasticcio spaventoso, pieno di cicli di dipendenza e dipendenze prive di senso. Allo stesso tempo viene utilizzato da circa 9 milioni di sviluppatori e probabilmente miliardi di sistemi in esecuzione. Pertanto non è assolutamente possibile eseguire il refactoring del JRE se tale refactoring crea modifiche sostanziali.

OSGi è un sistema modulare che ti aiuta (o addirittura ti obbliga a) creare software che sia modulare. Non si può semplicemente aggiungere la modularità a un codice base non modulare esistente. Trasformare una base di codice non modulare in una modulare richiede inevitabilmente un refactoring: spostare le classi nel pacchetto corretto, sostituire l'istanziazione diretta con l'uso di servizi disaccoppiati e così via.

Questo rende difficile applicare OSGi direttamente alla base di codice JRE, tuttavia abbiamo ancora la necessità di dividere JRE in parti separate o "moduli" in modo che possano essere fornite versioni ridotte di JRE.

Considero quindi Jigsaw una sorta di " misura estrema " per mantenere in vita il codice JRE mentre lo divide. Lo fa Non codice di aiuto per diventare più modulare, e sono convinto che sarà effettivamente aumentare la manutenzione necessaria per evolvere qualsiasi libreria o applicazione che l'utilizza.

Infine: OSGi esiste mentre Jigsaw non esiste ancora e potrebbe non esistere mai. La comunità OSGi ha 12 anni di esperienza nello sviluppo di applicazioni modulari. Se sei seriamente interessato allo sviluppo di applicazioni modulari, OSGi è l'unico gioco in città.

È semplice, se vuoi fare un vero sviluppo basato su componenti in Java oggi, OSGi è l'unico gioco in città.

Secondo me, Jigsaw è una combinazione di un compromesso tra ciò che è fattibile nel JDK e le precedenti cattive relazioni tra SUN e i ragazzi di OSGi. Forse verrà spedito con Java 8, ma dobbiamo aspettare e vedere.

OSGi non è una panacea se lavori in un ambiente aziendale tipico e dovrai acquisire familiarità con il funzionamento del caricamento delle classi poiché un certo numero di librerie ben note (guardandoti, Hibernate) ha fatto ipotesi sulla visibilità della classe che non sono più valide all'interno di OSGi.

Mi piace OSGi, ma non tenterei di adattarlo a un sistema esistente. Valuterei anche i pro ei contro in termini di sviluppo greenfield: consiglierei di guardare i prodotti Apache o Eclipse che semplificano la vita di OSGi e di non fare tutto da soli.

Se non stai utilizzando OSGi, sei sfortunato se hai trovato un sistema che ha dipendenze da diverse versioni della stessa libreria: tutto ciò che puoi fare è cercare di evitare il problema, anche se hai bisogno di più versioni di una la biblioteca mi sembra un "odore" di architettura.

Mi piace il tuo uso della frase "casi d'angolo" per descrivere la situazione attuale.

ci sono carenze con la specifica del file JAR che possono portare a problemi di risoluzione dello spazio dei nomi e di caricamento classi in alcuni casi angolari

Ad ogni modo, da molti anni sono interessato a strumenti e tecniche che supportano la creazione e, ancora meglio, l'applicazione di un codice più pulito, più disaccoppiato, più coerente e più manutenibile di quello che probabilmente sarebbe stato il risultato senza di loro. Test Driven Design e Junit erano una tale combinazione.

Dopo aver trascorso un paio di mesi a spostare una parte sostanziale della nostra base di codice su OSGi, direi che OSGi è uno strumento ancora migliore in questo senso. E questo è davvero un motivo sufficiente per passare a OSGi. A lungo termine ti farà risparmiare un sacco di soldi.

E, come bonus, ti darà la possibilità di fare molte cose interessanti. Immagina, durante una demo, di aggiornare senza problemi il modulo di autenticazione, senza perdita di traffico, per supportare OAuth ... è improvvisamente di nuovo una gioia creare cose!