Home Innovatie & Strategie Java-wereld wordt eindelijk modulair!

Java-wereld wordt eindelijk modulair!

52

Momenteel ben ik Kirk Knoernschild’s boek “Java Application Architecture” aan het lezen. Het boek gaat over “Modularity Patterns with Examples Using OSGI”.
Ik lees wel vaker vakliteratuur. Niet altijd is er even makkelijk doorheen te komen. Bij Kirk’s boek is dat in elk geval geen probleem. Het is ‘to the point’ en wat hij vertelt is relevant en herkenbaar. Een echte aanrader dus.

Ik eerder wel eens geroepen dat Java (en een hoop andere talen) een goed uitgewerkt, gestandaardiseerd, module-concept mist. Dat klopt en dat klopt niet.
Je hebt al een hele tijd dingen die in de buurt komen, zoals Jar files en de bijbehorende class-path problemen, Maven om dit (gedeeltelijk) voor je op te lossen, Webapplicaties (war & ear files), Componenten van verschillende UI-frameworks en zelfs ‘echte’ modules in de vorm van OSGI bundles. Maar wat is nu een java module?

Geen OSGI
Kirk’s boek is zo goed, omdat het niet alleen over OSGI bundles gaat. Het is uit de volgende delen opgebouwd:
1. Wat is een module en hoe dien je deze toe te passen?
2. Welke patterns herkennen we in het toepassen van modules?
3. Een aantal voorbeelden uitgewerkt in OSGI

Ik wil zeker wat meer te weten komen over OSGI, maar deel 3 is niet de reden dat ik het boek zo graag lees. Bij het lezen van deel 1 en 2 herken ik veel dingen die ik tijdens het werken met de genoemde net-niet-modules in de praktijk ben tegengekomen. Hoe zorg je ervoor dat een ontkoppelde relatie tussen classes tijdens deployment niet toch een cyclische afhankelijkheid tussen modules introduceert? Hoe ga je om met omgeving-afhankelijkheden? Wat is de juiste granulariteit van mijn modules? Dit soort vragen worden hier besproken. Bij het lezen krijg ik echter de indruk dat Kirk OSGI als de ‘holy grail’ van java-module implementaties ziet. Op dit moment is dat zeker waar. Toch denk ik niet dat we in de toekomst allemaal opeens OSGI-blundles gaan opleveren.

OSGI bestaat al jaren en heeft zeker zijn nut bij bepaalde toepassingen bewezen. Maar voor de meeste mensen blijft het extra ballast, die je als het even kan niet meeneemt. Hoe goed Kirk’s boek ook is, ik denk niet dat hij ons allemaal aan de OSGI gaat krijgen.

Wel modules
Wel voorspel ik, dat we straks allemaal in modules gaan denken. Java krijgt namelijk een gestandaardiseerd module-concept. Naast een gemodulariseerde JRE zal Project Jigsaw in Java SE 8.0 het concept ‘module’ aan de taal toevoegen. Zoals hier te lezen valt, worden module-declaraties een stukje van Java. Je kunt straks gewoon zeggen:

module foo {

exports foo;
exports foo.spi;
exports foo.util;
}

en daarmee duidelijk aangeven hoe je module heet en wat de public interface van de module is. Encapsulatie van je module is hiermee dus mogelijk. Iedere Java SE 8.0 gecertificeerde developer zal ermee bekend zijn en zal het gaan toepassen. Een applicatie zal niet langer een brei van class-instanties op een classpath zijn, applicaties zullen uit modules bestaan en modules weer uit modules.

OSGI als implementatie
Gaan we dan geen opeens OSGI meer gebruiken? In tegendeel. Ik denk dat we het heel veel zullen gebruiken, maar wellicht zonder er al te veel aandacht aan te besteden. We zullen het net zo gebruiken als we een applicationserver gebruiken om onze webapplicaties op te draaien en niet meer over de thread-afhandeling van elk web-request te hoeven nadenken. Jigsaw wordt namelijk geen kloon van OSGI.
Waar OSGI een volledig framework is, laat Jigsaw ruimte en vrijheid. Het schrijft bijvoorbeeld niet voor dat een runtime-environment meerdere versies van een module moet kunnen ondersteunen. Ook deployment terwijl de applicatie al draait wordt standaard niet ondersteund. Als je dat wilt, zul je een runtime moeten gebruiken die dat wel ondersteunt. Waarschijnlijk komen we dan weer bij OSGI implementaties uit, omdat deze volwassen genoeg zijn en Jigsaw modules zich straks als een vis in het water voelen binnen een OSGI container.

De ESB, IDE of Applicationserver waarvoor je een module ontwikkelt ondersteunt nu al vaak OSGI bundles en zal straks ook helemaal geen probleem hebben met de Jigsaw-modules. Daarmee is dan meteen ook het punt van meerdere tegelijkertijd gedeployede versies van een module afgedekt.

We zullen OSGI echter soms ook bewust niet gebruiken. Als we onze modules lokaal testen zullen we liever geen OSGI container starten en de module direct op de JVM draaien. De restrictie dat ik dan geen meerdere versies van een module op mijn class-path mag hebben lijkt me dan niet meer dan een goede sanity-check.

Over sanity gesproken. Er bestaat het risico dat mensen modules compleet verkeerd zullen gaan inzetten. Projecten zouden kunnen falen, alleen maar omdat men helemaal euforisch is geworden over de nieuwe mogelijkheden die modules bieden zodat alles een grote module-spaghetti is geworden. Laat ik dit proberen te voorkomen door nog een keer te zeggen dat we allemaal Kirk’s boek moeten lezen en het straks met gezond verstand over zaken als ‘Independent Deployment’ en ‘Acyclic Relationships’ van modules kunnen praten. Dan hoeven we het wiel op dat gebied in elk geval niet opnieuw uit te vinden.

Mark Kikken, Senior (JAVA) Lead Developer bij Salves

LAAT EEN REACTIE ACHTER

Please enter your comment!
Please enter your name here