Oppgradering av avhengigheter
Vi valgte å starte med oppgradering av avhengigheter. Dermed var det mindre sannsynlig at selve avhengighetene ville skape problemer, og dette er uansett en jobb man burde gjøre regelmessig for å unngå kjente sikkerhetshull. Så kan man jo diskutere bruken av automatiserte verktøy for å gjøre dette automatisk, men det får vi ta i et annet innlegg.
Man kan fort se seg blind dersom man manuelt sjekker en og en avhengighet, men med Maven så var ikke dette en komplisert oppgave. Potensielle oppgraderinger kan listes med
mvn versions:display-dependency-update
Automatiske oppgraderinger kan gjøres med mvn versions:update-properties, og den vil til og med endre versjon selv om den er satt i en property i stedet for direkte på avhengigheten.
Valg av Java distribusjon
Videre kommer spørsmålet om hvilken Java-distribusjon man skal bruke siden Oracle endret lisensieringsmodellen sin etter Java 8u202[1]. Da vi begynte prosessen med å oppgradere til Java 11 fantes det flere forskjellige distribusjoner av Java. På grunn av Oracle sin betalte lisens og behov for oppdateringer valgte vi å benytte AdoptOpenJdk, nå Eclipse Temurin[2]. Fra og med Java 17 så har Oracle åpnet opp for gratis bruk av deres versjon igjen, men det er ikke under GPLv2+CPE lisensen[3] slik som i versjoner før Java 8u202.
Migrering til Java 11
Det tilsynelatende siste steget var å gjennomføre selve migreringen til Java 11 som var to-delt. Det ene steget var å faktisk bytte versjon, mens det andre steget var å kartlegge hvilke avhengigheter som måtte legges til da flere Java EE pakker, ofte i javax pakken, var fjernet fra Java distribusjonen. Grunnen til at disse pakkene ble fjernet fra Java distribusjonen var fordi koden var duplisert mellom Java SE og Java EE, noe som skapte problemer ved videreutvikling av Java[4]. Java EE fikk dermed sin siste oppdatering i Java 8 og ble deretter flyttet til Jakarta EE[5].
Mange av pakkene som er fjernet fra Java har blitt tilgjengelig som selvstendige maven artifakter, men det er like greit bytte direkte til Jakarta dersom man har mulighet til det. Her er det viktig å passe på å bruke de tidlige versjonene som er direkte kopier av Java EE implementasjonene dersom man har avhengigheter til Java EE pakker via Spring, Apache CXF eller andre avhengigheter som man ikke kan endre selv. Senere versjoner av Jakarta bibliotekene endrer pakkenavn og namespace fra javax til jakarta[6] og noen artifakter fjerner selve implementasjonen slik at de kun inneholder spesifikasjonene til en tjeneste. Det vil kreve at man bruker enda en avhengighet for selve implementasjonen.
Vårt produkt hadde avhengigheter til javax.mail, javax.transaction og diverse Java XML pakker som ble fjernet. Disse avhengighetene ble raskt avdekket ved å kompilere koden og se hvilke moduler som manglet definisjoner av tidligere Java EE klasser, for så å legge de til. Det største problemet vi støtte på var transformering av WSDL til Java klasser med Apache CXF. Dette skyldtes at cxf-codegen-plugin ikke støtter Jakarta EE 9 [7]. Løsningen var å eksplisitte konfigurere pluginets avhengigheter til jakarta.xml.bind:jakarta.xml.bind-api og javax.xml.bind:jaxb-api.
Selve migreringen ble gjennomført bunn-til-topp ved å begynne med å oppgradere modulene våre uten avhengigheter til andre moduler. Videre jobbet vi oppover til de øverste modulene, altså sluttproduktet. Det er viktig å presisere at dette gjaldt alle Maven moduler, også de som ikke var Java prosjekt.
Byggserver
Til slutt kommer jokeren i oppgraderingen, selve serveren for bygging av prosjektet. Med alt fokuset på at prosjektet skal oppgraderes til Java 11 så kan man fort glemme at eventuelle byggservere også må oppgraderes. I vårt tilfelle gjaldt dette Jenkins nodene våre som kjørte i Docker med Java 8. Her støtte vi heldigvis kun på et problem og det var at selve Jenkins programvaren ikke støttet Java 11. Dette ble løst ved å starte Jenkins nodene med Java 8, men utføre selve bygget med Java 11.
Les om consulting, kompetent seniormiljø