De grootste Java conferentie van Nederland werd donderdag 31 oktober 2019 gehouden in Pathé te Ede. Net als vorig jaar een geweldige locatie en met meer dan 1500 bezoekers waren de zalen goed gevuld!

De eerste (early bird) ronde is al vroeg gepland, namelijk om 08:00 uur en nog voor de officiële opening van het event. Op tijd de auto in dus! 'n Uurtje rijden (met file) vanaf Den Bosch, parkeren, inchecken en om tien over acht kunnen we plaatsnemen bij de eerste sessie over de toepassing en het waarom van een Service Mesh.

What’s a Service Mesh and why do I need one?

Spreker: Jeroen Reijn

Het is je waarschijnlijk niet ontgaan dat organisaties massaal Monolieten aan het transformeren zijn naar gedistribueerde Microservices. Het (operationeel) beheersbaar houden van een netwerk aan microservices en de interactie tussen deze microservices is complex naarmate het aantal services toeneemt. Deze sessie gaat in op de concepten en het gebruik van een Service Mesh: een infrastructuur laag die (o.a.) verantwoordelijk is voor snelle, betrouwbare en veilige ‘service-to-service’ communicatie.

De voor -en nadelen van het gebruik van een Service Mesh worden goed in kaart gebracht en toegelicht met behulp van Istio. Een van de punten om rekening mee te houden is bijvoorbeeld dat de communicatie van service instanties verloopt via een sidecar proxy en dat hiervoor extra resources gereserveerd moeten worden. Afsluitend is er een goede live demo, waarin met behulp van Kiali een Istio Service Mesh inzichtelijk wordt gemaakt.

Opening & Keynotes

J-Fall 2019 wordt geopend met een spectaculaire dance act, waarna Bert-Jan Schrijver met voldoende humor het event aftrapt en de eerste keynotes inluidt.

In de eerste keynote wordt vooral duidelijk gemaakt hoe eenvoudig de Rabobank met behulp van het Pivotal Cloud Foundry platform applicaties naar productie kan deployen. De sprekers demonstreren dit ook live on-stage door een Flappy Bird game naar productie te deployen.

In de tweede keynote geeft ABN AMRO aan waarom API First ontwikkeling noodzakelijk is om Open Banking (o.a. PSD2) initiatieven te kunnen omarmen. Benieuwd hoe je ABN AMRO APIs kunt gebruiken in een applicatie? Verken dan de ABN AMRO developer portal.

How and why GraalVM is quickly becoming relevant for you

Sprekers: Lucas Jellema & Adnan Drina

Er is de laatste tijd veel te doen rondom GraalVM. In deze sessie wordt uitgelegd waarom GraalVM een belangrijke rol kan gaan spelen in de nabije toekomst van de ontwikkeling van (Java) applicaties.

In een demo tonen de sprekers aan dat een eenvoudige Java applicatie met GraalVM Native Image resulteert in een op zichzelf staand uitvoerbaar programma dat super snel opstart en een minimale hoeveelheid geheugen nodig heeft. GraalVM Native Image maakt dit mogelijk door gebruik te maken van Ahead Of Time (AOT) compilatie. In de sessie wordt besproken wat de beperkingen zijn voor Java wanneer gebruik gemaakt wordt van native images en er wordt ingegaan op de verschillen en eigenschappen van Ahead Of Time (AOT) versus Just In Time (JIT) compileren. GraalVM Native Image zorgt ervoor dat Java de concurrentie met lichtgewicht runtime omgevingen (zoals bijvoorbeeld Node.js) aan kan en dat Java een reële mogelijkheid wordt om in bijvoorbeeld Serverless toepassingen te draaien.

Een andere interessante mogelijkheid die GraalVM biedt is ‘polyglot interoperability’. Dit houdt in dat we vanuit de Java code gebruik kunnen maken van code die geschreven is in JavaScript, Python, C++ of andere programmeertalen die vervolgens in een gedeelde runtime uitgevoerd wordt. De onderliggende techniek die dit mogelijk maakt is het Truffle Language Implementation Framework. De toekomst zal leren hoe deze polyglot interoperability in de praktijk haar nut gaat bewijzen, maar interessant is het zeker!

Developing with Kubernetes

Spreker: Ray Tsang

In deze sessie vertelt Ray Tsang (werkzaam bij Google) over de keuzes die hij in een van zijn projecten heeft moeten maken met betrekking tot het ontwikkelen van een applicatie in een Cloud Native stack op een Kubernetes platform. De sessie begint met een introductie over de Twelve-Factor App methode (12factor.net) en de afwegingen die gemaakt moeten worden bij de keuze voor een mono-repo versus een multi-repo.

Een demo volgt waarin Ray in een sneltrein vaart laat zien hoe je een Spring Boot applicatie met Spring Cloud GCP (Google Cloud Platform) maakt en naar een Kubernetes cluster deployed en welke tools je kunt gebruiken voor de lokale ontwikkeling met Kubernetes. Onder andere K3S, Jib, Skaffold en Kustomize komen aan bod en hij demonstreert de IntelliJ Cloud Code plugin waarmee het lokale Kubernetes ontwikkel proces wordt vereenvoudigd. Een belangrijke boodschap in deze sessie is dat het verschil tussen lokale Kubernetes en productie Kubernetes enorm is en dat je services hoogst waarschijnlijk niet in één keer zullen werken op productie. Probeer lokaal dus geen Service Mesh (bijvoorbeeld Istio) op te tuigen, aangezien de inrichting hiervan nooit gelijk zal zijn aan productie in verband met het verschil in o.a. netwerk en beveiliging condities.

Een interessante en leerzame sessie. Hier wordt maar weer eens aangetoond dat een gedistribueerde service architectuur een stuk complexiteit met zich meebrengt en dat er ook op ontwikkel vlak veel zaken zijn waar je rekening mee moet houden. Gelukkig zijn er verscheidene tools beschikbaar waarmee de ontwikkelaar een deel van deze complexiteit te lijf kan gaan.

My Kotlin is better than your Java

Sprekers: Paulien van Alst & Brian Vermeer

In deze sessie gaan Paulien en Brian de Kotlin vs Java battle aan. De (grote) zaal zat goed gevuld, ondanks dat deze sessie al eerder dit jaar werd vertoond tijdens J-Spring 2019. In een aantal rondes worden verschillende aspecten van zowel Kotlin als Java tegen het licht gehouden en wordt geprobeerd te bepalen waarin Kotlin nu eigenlijk uitblinkt ten opzichte van Java, of misschien toch juist minder uitblinkt dan dat (Java) ontwikkelaars altijd denken…

In ronde 1 wordt de stelling gedeponeerd dat Kotlin ‘Yet Another Language’ is. We hebben eerder nieuwe JVM talen gezien zoals Scala en Groovy en zien we deze talen nog veel gebruikt worden in onze huidige projecten? In de top 20 ‘most used programming languages’ staan Java en JavaScript nog altijd op plaats 1 en 2, terwijl Kotlin ergens onderaan bungelt. Wat betreft de continuïteit in projecten, is het dan niet veel eenvoudiger om Java ontwikkelaars te vinden in plaats van Kotlin ontwikkelaars? Aan de andere kant is Kotlin een nieuwe taal die ‘het beste van alle andere werelden’ in zich heeft. Maar is Kotlin niet gewoon ‘syntactic sugar’ voor Java en moeten we met z’n allen niet eens zorgen dat we Java updaten binnen onze projecten...?

Ronde 2 heeft als onderwerp ‘Less is more’. Kotlin heeft data classes, iets waar je in Java veel boilerplate code voor nodig hebt, al valt dit met Lombok wel weer mee. Het is belangrijk dat code efficiënt geschreven, maar vooral gelezen kan worden. Is ‘verbosity’ dan zo slecht? En waarom zou je in een Data Transfer Object niet gewoon ‘public’ fields mogen gebruiken zonder alle getters en setters..? Tot slot heeft Java heeft inmiddels List.of en Map.of methodes, waarmee de code een stuk compacter wordt.

Don’t write code for machines, write code for people, daar gaat het over in ronde 3. Is operator overloading in Kotlin nu eigenlijk wel zo handig? Wat is het gedrag als ik twee ‘Foo’ classes bij elkaar optel? Extension functions in Kotlin, super handig, maar is het duidelijk waar ze gespecificeerd zijn?

Na ronde 3 is het tijd voor een voorlopige stem ronde. Het blijkt dat iets meer dan de helft van de aanwezigen in de zaal de handen omhoog steekt voor Java. Tijd voor Kotlin dus om in de volgende drie rondes meer zielen te winnen…

In ronde 4 komt aan bod dat Kotlin geen null kent. Kotlin is namelijk null safe en dat is écht lekker!

Ronde 5 bespreekt ‘laziness’. De Java Streams API gebruikt namelijk lazy evaluation, terwijl Kotlin standaard eager evaluation gebruikt. In Kotlin kun je lazy evaluation afdwingen met .asSequence methode.

De laatste en zesde ronde gaat over ‘behaviour’. Hierin wordt gesteld dat gedrag in Kotlin niet expliciet is onder andere door het gebruik van Extension Functions en Operator Overloading.

Deze hele sessie is uiteraard bedoeld om de ontwikkelaars op scherp te zetten en te laten inzien dat Kotlin niet de ‘heilige graal’ is. We moeten onze huidige projecten nu niet ineens allemaal in Kotlin willen gaan schrijven, maar zoals voor alle technologie geldt: weet wat je doet en gebruik het daar waar het goed voor is. En als je het nog niet gedaan hebt: upgrade naar Java 11 of hoger!

Multiplayer Pac-Man with RSocket

Spreker: Oleh Dokuka

Welk protocol is nu het meest geschikt om een real-time multiplayer pac-man spel te maken? Deze sessie introduceert RSocket: een binair, multiplexed, transport agnostisch, bi-directioneel, backpressure aware protocol dat 'reactive' principes omarmt.

De spreker laat verschillende manieren zien hoe een multiplayer pac-man game gemaakt kan worden en maakt daarmee duidelijk waar RSocket haar toegevoegde waarde ligt. De demo pac-man applicatie is gemaakt met Spring Framework 5, Project Reactor 3 en Protobuf aan de backend kant en Phaser 3, Reactor-JS, TypeScript en Protobuf aan de frontend kant.

De game wordt live door het publiek (in een browser) gespeeld in 4 verschillende versies: de eerste versie is gebaseerd op Http/1.x, de tweede versie maakt gebruik van WebSockets, de derde versie gebruikt gRPC (stevig gekoppeld aan Http/2) en afsluitend uiteraard een versie met RSocket. Zoals verwacht resulteert de Http/1.x versie in hoge latency, maar ook de gRPC versie laat dit zien en dit wordt voornamelijk veroorzaakt doordat de communicatie vanuit de browser nog steeds op basis van Http/1.x verloopt via gRPC-web.

De voordelen en nadelen van Http/1.x en Http/2, WebSockets, Socket.io en gRPC passeren de revue. Socket.io is een erg goede keuze aan de JavaScript kant en gRPC is een uitstekende keuze voor server naar server communicatie en biedt uitstekende integratie met Spring via @GRpcService. Helaas bieden deze opties geen antwoord op de eisen die gesteld worden aan resilience in high-performance reactive (stream) scenario's. RSocket dekt hier wel de volledige lading en wordt inmiddels actief onderhouden door grote namen zoals Facebook, Pivotal en Netflix. Volgens de spreker heeft Netflix inmiddels afstand gedaan van gRPC en wordt de overstap naar RSocket gemaakt.

Interessant om de ontwikkeling van RSocket in de gaten te houden!

Afsluiting

Na een lange, gezellige dag met interessante sessies is er afsluitend nog tijd om onder het genot van een hapje en drankje na te praten met een aantal (oud) collega's.

Wat opvalt is dat GraalVM sterk in opmars is en dat steeds meer (Microservice) frameworks zoals Quarkus, Micronaut en Spring dit (gaan) omarmen. Er is veel aandacht voor cloud-native ontwikkelingen op het gebied van Microservice architectuur, Kubernetes en Serverless. Java is 'all over the place' en nu nog sneller en meer 'lightweight' dan ooit!