XB4J: de Kadaster casus

Het moet een late vrijdagmiddag zijn geweest, eind augustus 2017. De exacte datum weet ik niet meer. Ik zit naast Mando, de consultant die we hebben ingehuurd om onze JAXB-kennis te versterken. Ik kijk toe hoe hij behendig met zijn debugger door de JAXB-broncode stapt. We onderzoeken al de hele middag hoe we om de bug heen kunnen werken. Verschillende ideeën zijn opgekomen, maar niet één die ons heeft overtuigt de juiste te zijn. Eigenlijk geloof ik er niet meer in dat JAXB voor dit project de juiste oplossing is. Niet met de voorwaarden die we hebben gesteld: geen code duplicatie. Niet in de gegenereerde Java klassen, maar ook niet in de Java code die de transformatie verzorgt.

Mijn geloof zit deze week in een vrije val. Begin november stopt het Kadaster met de levering van hun SOAP bericht Kik-inzage versie 4.7. We hebben nog maar twee maanden om onze software om te schrijven en hun nieuwe versie 5.1 te gebruiken. Nog twee maanden! We zijn nu twee maanden bezig en maken veel te weinig voortgang; we hebben een technologische keuze gemaakt (JAXB versus XSLT), en zijn begonnen met de implementatie. That’s it. En dan lopen we ook nog tegen die blokkerende bug aan in JAXB. Lukt het niet om begin november klaar te zijn, dan zullen de Gemeentelijke Sociale Diensten, onze klanten, geen kadastrale gegevens van ons krijgen, die ze nodig hebben voor de beoordeling van aanvragen voor bijstandsuitkeringen. Het zou een groot gezichtsverlies betekenen voor ons bedrijf.

Ik zucht en haal nog een rondje koffie. Als iedereen zijn drankje heeft, keer ik achter mijn eigen bureau terug. Ik mompel tegen Mando dat ik nog even iets wil uitzoeken. In werkelijkheid wil ik verder met mijn proof of concept waar ik een paar dagen geleden aan begonnen ben. Voor het Kik-inzage bericht, maar dan met een andere techniek: XB4J. Een kleine, open source bibliotheek die net als JAXB bedoeld is om XML naar Java om te zetten en vice versa. Ik heb het een aantal jaar geleden zelf ontwikkeld. Het is gespecialiseerd in de problematiek waar we nu met JAXB door een bug gestopt worden. Ik weet dat het met XB4J moet kunnen, maar ik weet ook dat er tijd in geïnvesteerd moet worden, zodat het de complexiteit van het Kadaster bericht ondersteunt. En ik was er niet aan toe om mijn vrije tijd hieraan te wijden. Maar ik zie geen alternatieven meer.

Het duurt niet lang of ik zit in een flow. In Eclipse heb ik de Java klasse openstaan waarin ik programmeer hoe XB4J de Java representatie koppelt aan de XML-representatie, het zogenaamde ‘binding model’. Veel informatie die we van Kadaster geleverd krijgen, gebruiken we niet. Met een Ignore-binding vertel ik dit aan XB4J. Voor de proof of concept gebruik ik voor elke XML-entiteit even de Ignore-binding, om de structuur snel gemodelleerd te hebben. Daarna kan ik verfijning aanbrengen en één voor één de entiteiten die we nodig hebben aan Java representaties van de XML koppelen. Het is een monnikenwerk en ik begrijp de charme van JAXB wel. Voor de drie Kadaster operaties heeft JAXB binnen drie seconden de meer dan 1500 klassen gegenereerd die het denkt nodig te hebben. JAXB genereert veel klassen dubbel vanwege de manier waarop het Kadaster met zijn XML namespaces omgaat. Door de bug in JAXB lukt het niet om in alle constructies die Kadaster hanteert, de dubbelen betrouwbaar terug te brengen. Met als resultaat dat tijdens het ummarshallen van een bericht gegevens verloren gaan, zonder dat er een foutmelding optreedt.

Ik denk dat we met XB4J slechts een vuistvol Java klassen nodig hebben om de informatie vast te leggen die we van het Kadaster nodig hebben. XB4J genereert ze niet, als ontwikkelaar moet je die zelf schrijven. Voor de proof of concept wil ik de NatuurlijkPersoon klasse schrijven en deze koppelen aan de twee XML-representaties die in de eerste operatie van het Kadaster-bericht voorkomen. Ze komen ook nog twee keer voor in de twee andere operaties, maar daar hergebruik ik dezelfde NatuurlijkPersoon klasse. We moeten wel telkens weer de bindingmodel vertellen dat deze Java klassen ook gekoppeld moeten worden aan elementen in andere XML namespaces. Het zou lekker zijn als er tooling was, die ondersteunde bij het maken van het binding model. Een tool die de WSDL of XML-schema zou lezen en waarmee je via een GUI kunt aangeven hoe de XML elementen gekoppeld moeten worden aan welke Java klassen en attributen. Dat zou het werken met XB4J een stuk prettiger maken. Maar die tooling moet nog geschreven worden.

De maandag daarna, op de laatste dag van de sprint, kan ik de proof of concept aan het team presenteren. Ik heb in het weekeinde gewerkt om XB4J aan te passen, zodat de constructie met ‘unbounded choices’ in het kadaster bericht ondersteund wordt. Via een geautomatiseerde test kan ik laten zien dat een XML bericht naar een Java representatie wordt omgezet en weer terug naar XML. Er gaan geen gegevens verloren, zoals dat wel het geval is met JAXB. Mijn beide collega ontwikkelaars zijn kritisch, maar enthousiast. Ook Mando heeft het weekeinde nuttig besteed en heeft een oplossing gevonden waarmee om het probleem in JAXB heen gewerkt kan worden. Zijn aanpak grijpt in op het unmarshall-proces: het verandert de namespace van de XML-elementen die problemen geven, in de namespace variant die voor dat element geen probleem geeft, voordat JAXB ze omzet naar Java instanties. Het vereist het vastleggen in de code van alle namespaces en element combinaties die problemen geven.

‘s Middags bespreken we met het hele team de voor- en nadelen van JAXB en XB4J, en spreken we uit in welke techniek we het meest vertrouwen hebben om het nieuwe Kadaster bericht te implementeren. Na een levendige discussie kan iedereen zich vinden in een keuze voor XB4J. De doorslag wordt gegeven door de volgende argumenten:

  1. XB4J koppelt de Java representatie los van het XML-schema, waardoor hergebruik van de Java code (en alles wat daarvan afhankelijk is, zoals transformaties etc.) makkelijker te realiseren is. Het lijkt daarmee ook een robuustere oplossing, omdat bij toekomstige versies van het Kadaster bericht, de schema wijzigingen in het bindingmodel opgevangen kunnen worden.
  2. Het team schat in dat XB4J een veel lagere leercurve heeft dan JAXB.
  3. Het vertrouwen in JAXB is gedaald: wie weet welke verrassingen ons nog meer te wachten staan?

De komende sprints gaan we met XB4J aan de slag. Mijn collega ontwikkelaars schrijven de binding modellen en de Java klassen, terwijl ik hun verbetervoorstellen in XB4J verwerk en oplossingen implementeer voor de problemen waar ze tegenaan lopen. De product backlog wordt opnieuw ingeschat en er wordt een ‘minimal viable product’ gedefinieerd op basis van informatie van eindgebruikers. Het schrijven van de binding modellen geeft extra werk vergeleken met JAXB, maar ze zijn met een voorspelbaar tempo te implementeren. Van Kadaster komt het bericht dat uitfasering van versie 4.7 uitgesteld wordt. Eerst wordt gesproken over december, daarna geven ze aan dat ze eind januari 2018 een definitieve einddatum zullen communiceren. Het lijkt erop dat we niet de enige afnemer van het bericht zijn die moeite heeft met de integratie van versie 5.1 in haar systemen. Eind september schatten we in dat we onze software tussen half januari en half februari 2018 helemaal aangepast hebben naar de nieuwe berichtversie. Een schatting die we niet meer aan hoeven passen. Ruim op tijd vóór vrijdag 13 april, de datum die het Kadaster definitief heeft vastgesteld als einddatum voor versie 4.7.

Nawoord

De broncode van XB4J staat op Github. Het project kan via Maven Central als afhankelijkheid in je project worden opgenomen. De ervaringen in het team waren overwegend positief. Ontwikkelaars die niet eerder met XB4J gewerkt hebben, waren snel productief. Het was daarbij wel belangrijk dat ze van een voorbeeld af konden kijken. De foutmelding die XB4J geeft, wanneer het binding model de berichtstructuur niet goed beschrijft is cryptisch. Oplossen daarvan kost tijd. Via logging is wel snel duidelijk wat het probleem is, maar de foutmelding moet gewoon beter. En het schrijven van een binding model blijft monnikenwerk. Naar aanleiding van de toepassing van XB4J in dit project heb ik de volgende prioriteiten opgesteld voor de verdere ontwikkeling:

  1. Voeg gebruikersdocumentatie toe met voorbeelden.
  2. Werk aan tooling om de ontwikkelaar te ontlasten bij het schrijven van een binding model.
  3. Verbeter de foutmeldingen wanneer de bindings niet helemaal overeenkomen met de berichtstructuur.
  4. Implementeer alle functionaliteiten die mogelijk zijn volgens de XML-schema specificaties.
  5. Verbeter de API, bijv. door gebruik te maken van builders of een DSL.

Laat me weten wat jouw ervaringen zijn met XB4J.

De waarde van Java certificering

De badge die hoort bij de OCP certificeringEind 2016 was ik in een discussie verwikkeld met twee collega’s over het behalen van een officieel Java certificaat. De één was begonnen met de studie voor OCA Java SE 8 en de ander had in het verleden SCJP behaald voor J2SE 1.4. Beide waren het met elkaar eens dat het een behoorlijk pittig examen was. Ik was er niet van overtuigd dat iemand die gecertificeerd is, automatisch als vakman beschouwd kan worden; de stof is zo geleerd, maar ook zo weer vergeten. Tijdens deze discussie drong het tot me door dat ik redelijk kritisch ben, maar dat ik niet uit ervaring kan spreken. Dus zit er maar één ding op: zelf het certificaat halen.

De studie

Java certificering komt in verschillende vormen. De algemene certificering bestaat uit OCA en OCP. Daar bovenop kun je certificaten halen voor specificaties op het gebied van JEE. Ik heb ervoor gekozen de algemene OCP certificering te doen. Je moet eerst je OCA certificaat halen, voor je het OCP examen mag afleggen.

Ik heb twee boeken [1]  besteld om me via zelfstudie thuis voor te bereiden. Rond de kerstdagen van 2016 vallen ze op mijn deurmat. Bij elkaar ruim 1000 bladzijden. Oké, dit gaat wel even duren. Ik maak een planning en denk dat ik in het eerste kwartaal van 2017 de materie doorgewerkt kan hebben.

Student achter stapel boeken
Wokandapix / Pixabay

Het is eind maart als ik het tweede boek dichtsla. Uit! Elk hoofdstuk in de boeken wordt afgesloten met een test om voor je zelf te bepalen of je de stof genoeg beheerst. Volgens de schrijvers komen de vragen overeen met het niveau van het examen. En dan kun je maar één conclusie trekken: er moet ten minste één sadist tussen die examinatoren gezeten hebben. Want elke vraag lijkt een zorgvuldig geconstrueerde valkuil te zijn, bedoeld om jou als OCP-er in spe, te laten struikelen. Je moet denken als een compiler, en dat is iets wat ik niet gewend ben, met  dank aan alle geweldige tooling en IDE’s van tegenwoordig.

Examens

Al met al denk ik dat ik dat het OCA zonder extra inspanning haalbaar moet zijn. OCP bevat een aantal onderwerpen, waar ik te weinig praktijkervaring mee heb, of waar mijn ervaring te ver in het verleden ligt. Denk bijv. aan Concurrency, Fork-Join framework, Paths en de Java 8 functionele uitbreidingen. Hier moet ik me nog wat verder in verdiepen. Afijn, ik heb genoeg vertrouwen om het examen voucher aan te schaffen voor OCA (ze vervallen na zes maanden). Dat valt nog niet mee, als je niet beschikt over een creditcard. Maar na een iteratief proces van bellen en  wachten en mailen en wachten is het toch gelukt om via een bankoverschrijving een voucher bij Oracle te bemachtigen.  Op 16 juni 2017 doe ik examen OCA en slaag met een score van 91% .

abstracte afbeelding van een afgestudeerde met een diploma in de hand
creades / Pixabay

Inmiddels is op het werk de druk flink toegenomen in verband met deadlines en ambities van het bedrijf, en resteert mij weinig tijd om OCP verder op te pakken.  Uiteindelijk besluit ik om aansluitend aan een weekje Devoxx in Antwerpen twee weken vrij te nemen om er eens goed voor te gaan zitten. Op vrijdag 24 november 2017 slaag ik voor mijn OCP met een score van 82%.

Conclusie

Ook de ervaren Java ontwikkelaar zal een behoorlijke inspanning moeten leveren om de OCP Java certificering te halen. Veel lezen, voorbeeldjes controleren in je IDE, proefexamens maken, enzovoort. Wat het je oplevert is extra scherpte en het opfrissen van je kennis. Ik merk hier in de praktijk met name voordeel van, wanneer ik code van collega’s review. Ook kan het een (hernieuwde) kennismaking zijn met onderdelen van het Java platform die je in je dagelijkse werkzaamheden niet of nauwelijks gebruikt. En die je dus ook weer snel zal vergeten, als je ze niet gaat gebruiken. Wel kan het helpen om een volgende keer niet de vertrouwde oplossingen toe te passen, maar de ‘nieuwe manier’: met Streams en lambda’s, met NIO.2 Paths of de nieuwe datetime API’s.

Voor beginnende Java ontwikkelaars is certificering geen goede manier  om de taal (beter) te leren kennen.  De lesboeken en examens staan vol met voorbeelden van hoe het niet moet. Zoals: éénletterige variabele namen, onleesbare if-else of try-catch constructies, etc. Zoals eerder gezegd, je leert je te verplaatsen in de compiler, en niet in een teamgenoot die ook de code moet lezen en begrijpen.

Voor een werkgever of opdrachtgever kan het helpen om een snelle schifting in CV’s te maken, bijv. als je op zoek bent naar ontwikkelaars met kennis van de functionele toevoegingen in Java 8 (lambda’s en de Stream-APIs). Bekijk wel altijd goed voor welke Java versie de certificering geldt.

Al met al heeft certificering mij wel wat opgeleverd, maar weegt het mijns inziens niet op tegen de tijdsinvestering. En ik denk nog steeds dat wel- of niet Java gecertificeerd zijn geen graadmeter is voor vakmanschap.

[1] Jeanne Boyarsky and Scott Selikoff – OCA Study  guide,
Jeanne Boyarsky and Scott Selikoff – OCP Study  guide