Bezoek aan JSpring 2017 | Semantica
10 May 2017 • Auke • Column • 3 minuten leestijd
De complexiteit van mijn vader
Maurice Naftalin (auteur van o.a. Java Generics and Collections) had een onderwerp dat gelukkig wat dichter bij huis kwam met 'de complexiteit van mijn vader'. Mijn vader? Onze computervaders bedoelde hij natuurlijk! Heren als Alan Turing en Donald Knuth die aan het voorfront van de computerwetenschap stonden en waar de big-O notatie zijn oorsprong vond. Echter, sinds de jaren 80 zijn de processoren vele malen sneller geworden dan het computergeheugen dat ze gebruiken. Daarom zijn er caches op verschillende niveaus ontworpen die data sneller aan de processor kunnen leveren en voorkomen dat die zich gaat vervelen.
De caches moeten natuurlijk wel gevuld worden en daarom moet het voorspelbaar zijn waar het volgende stukje benodigde data te vinden is in het geheugen. Met een objectgeoriënteerde programmeertaal zit je eigenlijk meteen al fout wat betreft het geheugen, maar het werd duidelijk dat als je een linked list wil gebruiken, je toch wel een erg goede reden nodig hebt. Zoals Joshua Blog zich al eerder afvroeg: "Does anyone actually use LinkedList? I wrote it, and I never use it.".
Natuurlijk is de big-O niet afgeschreven maar het mag duidelijk wezen dat de situatie minder simpel is dan die notatie doet vermoeden. Duidelijk is ook dat een array toch geen deprecated type is aangezien die de data naast elkaar in het geheugen opslaat, maar echte oplossingen lijken ook niet voorhanden zijn.
Voor nu zullen we gezond verstand moeten gebruiken en kunnen hulpmiddelen als ObjectLayout verlichting brengen. Voor de toekomst kunnen we uitkijken naar het Valhalla project, dan zul je wel moeten wachten tot JDK 11 (als je geluk hebt..).
Java 9 feature: Modularity
Nadat alle features in Java 9 eens goed doorgezaagd waren door het duo van Simon Maple en Oleg Selajev (ZeroTurnaround), was het tijd om meer te weten te komen over de key feature van Java 9: Modulariteit (al staat alles momenteel op losse schroeven ).
Sander Mak werkt al jarenlang met modulariteit in Java met frameworks als OSGi en vertelt ons over Modulariteit (in Java 9) vs Microservices. Zoals tijdens de keynote presentatie van Daniel Gebler (Picnic) al werd opgemerkt, is het ondanks de hype toch niet slim om als start-up met de ontwikkeling met microservices te beginnen. Eigenlijk laat de volgende grafiek alles zien:
Als je dan toch wil dat je applicatie en bedrijf kan groeien zonder tegen een 'Brick Wall' van een monoliet aan te lopen, kun je beter je applicatie op een modulaire manier ontwerpen. Waarom dan niet microservices van het begin af aan? Je startup kosten zijn nu eenmaal veel lager doordat je veel overhead die bij microservices komen kijken mist (security overhead, service discovery, api gateways, inter-process communication).
Ja, als je modulair begint, zijn de startup kosten iets groter dan zonder, maar relatief veel lager dan bij microservices. Ook kun je ontwikkelen met alle voordelen van de compiler en IDE's en ben je vrij in het kiezen van synchrone of asynchrone communicatie tussen de verschillende modules. Bovendien kun je later veel makkelijker overschakelen naar een microservices architectuur omdat je applicatie al modulair ontworpen is. Zo kun je ook al met een modulaire architectuur de modules ontwerpen zodat ze ieder één ding goed doen en de zeggenschap hebben over hun eigen data.
Het devies is: ontwerp als microservices, bouw modulair.
Auke is nieuwsgierig, naar de zin van het leven, maar vooral naar Java. Als een pitbull bijt hij zich vast in een probleem (en dat is gelukkig niet verboden).