--- title: "Een kritieke Java 8-applicatie upgraden naar modern Java" description: "Zo breng je een kritieke Java 8-app naar een actuele LTS-release: inventaris van dependencies, upgrades in stappen, tests, valkuilen en loadtests." canonical: https://sdk.enterprises/nl/insights/upgrading-legacy-java language: nl --- # Een kritieke Java 8-applicatie upgraden naar modern Java Bijgewerkt: 2026-09-25 > Upgrade een kritieke Java 8-applicatie in fasen: inventariseer elke dependency, ga eerst naar Java 11 en daarna naar elke volgende release met langetermijnondersteuning, en laat tests en loadtests bepalen wanneer elke stap veilig is. Het meeste werk zit in libraries, buildtooling en code die interne onderdelen van de JDK raakt, niet in je bedrijfslogica. ## Op Java 8 blijven beperkt je opties elk jaar verder Een Java 8-applicatie kan jarenlang blijven draaien, en precies daar zit de valkuil. Beveiligingsupdates hangen steeds vaker af van een betaald supportcontract of een distributie die ze nog terugzet, en belangrijke libraries zijn verder gegaan. Spring Boot 3 vereist bijvoorbeeld minimaal Java 17, dus wie op Java 8 blijft, bevriest ook zijn frameworkversies. Nieuwere JVM's draaien dezelfde code ook beter. G1 is sinds Java 9 de standaard garbage collector, collectors met korte pauzes zoals ZGC zijn klaar voor productie, en compact strings verlagen het geheugengebruik bij workloads met veel tekst. Engineers verwachten bovendien moderne taalfuncties zoals records, text blocks en switch expressions, waardoor het lastiger wordt om mensen te vinden voor een Java 8-codebase. ## Begin met een inventaris van alles waar de applicatie van afhangt De upgrade van de JDK zelf is zelden het moeilijke deel. Het moeilijke deel is de lange staart van libraries, plugins en agents die voor Java 8 zijn geschreven en nooit zijn bijgewerkt. Maak een volledige lijst voordat je iets verandert, en noteer van elk onderdeel de versie. - De leverancier en versie van de JDK in elke omgeving, van de laptops van developers tot productie. - Directe en transitieve dependencies, geëxporteerd uit de Maven-dependencyboom of het dependencies-rapport van Gradle. - Buildplugins, codegeneratoren en annotation processors zoals Lombok. - De applicatieserver of servletcontainer, als de applicatie daarin draait. - Java-agents voor monitoring, profiling of beveiliging, die diep in de JVM ingrijpen. - Code die interne API's van de JDK gebruikt, te vinden met de tool jdeps en de optie jdk-internals. - JVM-flags, instellingen van de garbage collector en scripts die de uitvoer van java -version parsen. ## Loop de LTS-releases stap voor stap door in plaats van te springen Ga van Java 8 naar 11, dan naar 17, dan naar 21 of 25. Elke stap heeft zijn eigen verwijderingen en gedragswijzigingen, en één grote sprong mengt ze allemaal tot één fout die je niet kunt diagnosticeren. Door laag voor laag te repareren, blijft elke stap klein genoeg om te reviewen en terug te draaien. Upgrade libraries waar mogelijk nog op Java 8, want veel recente versies ondersteunen zowel oude als nieuwe JDK's. Draai daarna de bestaande build op de nieuwe JVM voordat je het compilatiedoel verandert. Zo scheid je runtimeproblemen van compilerproblemen, en de compilerflag release houdt het bytecodedoel expliciet. ## Maak de testsuite de poort voor elke stap Tests zijn je enige objectieve signaal dat de geüpgradede applicatie zich nog hetzelfde gedraagt. Hebben kritieke routes weinig dekking, schrijf dan eerst karakteriseringstests: tests die vastleggen wat het systeem vandaag doet, inclusief de vreemde randgevallen, zonder te oordelen of dat gedrag juist is. Voeg integratietests toe die tegen een echte database en echte message brokers draaien, want veel fouten bij een upgrade verschijnen pas op die grenzen. Speel bij systemen met veel berekeningen dezelfde invoer af door de oude en de nieuwe versie en vergelijk de uitvoer veld voor veld. Let op datums, getallen en tekst: Java 9 stapte standaard over op CLDR-localedata en Java 18 maakte UTF-8 de standaardtekenset, en beide kunnen de opmaak of het parsen ongemerkt veranderen. ## Ken de valkuilen die Java 8-code breken De meeste breuken vallen in een paar bekende categorieën. Zoek vóór de upgrade naar elk ervan in plaats van ze in productie te ontdekken. - Verwijderde Java EE- en CORBA-modules: Java 11 haalde JAXB, JAX-WS, JavaBeans Activation en de common annotations uit de JDK, dus die moet je als expliciete dependencies terugzetten. - Sterke inkapseling van JDK-internals: illegale reflectieve toegang gaf vanaf Java 9 waarschuwingen, wordt sinds Java 16 standaard geweigerd en kan sinds Java 17 niet meer globaal worden aangezet. Los het op door de library te upgraden; gebruik add-opens alleen als gedocumenteerde, tijdelijke uitzondering. - Verouderde bytecodetools: oudere versies van Lombok, Mockito, Byte Buddy, ASM en buildplugins falen op nieuwere classfile-versies. - Verwijderde functies: de JavaScript-engine Nashorn werd in Java 15 verwijderd, en de Security Manager werd in Java 17 deprecated en in Java 24 definitief uitgeschakeld. - Verwijderde JVM-flags: de CMS-garbage collector werd in Java 14 verwijderd, en een JVM die met verwijderde opties wordt gestart, kan weigeren op te starten. ## Bewijs de performance onder realistische belasting, niet op een laptop Een nieuwe JDK verandert de garbage collector, de JIT-compiler en de geheugenindeling, dus de performance kan beide kanten op gaan. Draai vóór en na elke stap een loadtest die het verkeersprofiel van productie nabootst, op dezelfde hardware of hetzelfde instancetype. Vergelijk latencypercentielen, doorvoer, geheugen en pauzes van de garbage collection, en laat de JIT opwarmen voordat je meet. Onze engineers leidden, via Sopra Steria, een migratie van Java 8 naar 16 van een kritieke applicatie voor day-trading in gas voor een nationale gashandelsdesk. Op dat systeem moesten berekeningen van capaciteit en energiestromen correct en snel blijven onder hoogfrequente belasting, dus ging de upgrade samen met optimalisatiewerk aan die berekeningen en werd hij onder belasting gevalideerd in plaats van aangenomen. ## Rol geleidelijk uit en houd een weg terug Zet de geüpgradede runtime eerst op één instantie of op een klein deel van het verkeer, en vergelijk foutpercentages, latency en het gedrag van de garbage collection met het vertrekpunt op Java 8. Houd de vorige build deploybaar tot de nieuwe versie normale bedrijfscycli heeft doorlopen, inclusief maandafsluitingen of piekperiodes. Verwijder pas daarna de Java 8-artefacten en begin nieuwe taalfuncties te gebruiken. Wil je hulp bij het plannen of uitvoeren van zo'n upgrade, dan zet SDK Enterprises daar eigen engineers en gescreende specialisten op in, onder één contract met één verantwoordelijke partij. ## De kern - Het werk in een Java 8-upgrade zit vooral in dependencies, buildtooling en het gebruik van JDK-internals, niet in bedrijfslogica. - Loop de LTS-releases één voor één door, zodat elke fout één vindbare oorzaak heeft. - Karakteriserings- en integratietests zijn de poort voor elke stap, vooral rond datums, getallen en tekencodering. - Valideer de performance onder een belasting die op productie lijkt, want wijzigingen in garbage collection en JIT kunnen de resultaten beide kanten op bewegen. - Rol eerst uit naar een klein deel van het verkeer en houd de Java 8-build deploybaar tot de nieuwe runtime zich heeft bewezen. ## Veelgestelde vragen ### Kun je rechtstreeks van Java 8 naar Java 21 upgraden? Dat kan, maar dan krijg je alle wijzigingen van Java 9 tot 21 in één keer, waardoor fouten moeilijk te herleiden zijn. De tussenstappen via 11 en 17 kosten wat meer buildtijd en besparen veel debugwerk op een kritiek systeem. ### Hoe lang duurt een upgrade van Java 8? Dat hangt af van het aantal dependencies, hoeveel daarvan JDK-internals gebruiken, de testdekking en hoeveel loadtests het systeem nodig heeft. Een inventaris en een proefrun op de nieuwe JVM geven je al vroeg een realistische schatting, voordat je je aan een planning verbindt. ### Moet je code herschrijven om nieuwe Java-functies te gebruiken? Nee. Java is sterk achterwaarts compatibel voor code die zich houdt aan standaard-API's die niet deprecated zijn. Neem records, text blocks en andere functies geleidelijk in gebruik, nadat de geüpgradede runtime stabiel in productie draait. ## Gerelateerde diensten - [Software op maat](https://sdk.enterprises/nl/services/product-engineering) - [Applicatiebeveiliging](https://sdk.enterprises/nl/services/secure-systems)