Uppgradera en kritisk Java 8-applikation i etapper: inventera varje beroende, gå först till Java 11 och sedan till varje senare version med långtidsstöd, och låt tester och lasttester avgöra när varje steg är säkert. Det mesta av arbetet ligger i bibliotek, byggverktyg och kod som rör JDK:ns interna delar, inte i din affärslogik.
Att stanna på Java 8 minskar dina valmöjligheter för varje år
En Java 8-applikation kan fortsätta att köras i åratal, och det är just det som är fällan. Säkerhetsuppdateringar kräver allt oftare ett betalt supportavtal eller en distribution som fortfarande bakåtporterar dem, och de stora biblioteken har gått vidare. Spring Boot 3 kräver till exempel minst Java 17, så att stanna på Java 8 fryser också versionerna av dina ramverk.
Nyare JVM:er kör dessutom samma kod bättre. G1 har varit standard för skräpsamling sedan Java 9, skräpsamlare med korta pauser som ZGC är redo för produktion, och kompakta strängar minskar minnesanvändningen för textintensiva arbetslaster. Utvecklare förväntar sig också moderna språkfunktioner som records, textblock och switch-uttryck, vilket gör det svårare att bemanna en kodbas i Java 8.
Börja med en inventering av allt som applikationen är beroende av
Själva JDK-uppgraderingen är sällan det svåra. Det svåra är den långa svansen av bibliotek, pluginer och agenter som skrevs för Java 8 och aldrig uppdaterades. Gör en fullständig lista innan du ändrar något, och anteckna versionen för varje post.
- JDK-leverantör och version i varje miljö, från utvecklarnas datorer till produktion.
- Direkta och transitiva beroenden, exporterade från Mavens beroendeträd eller Gradles rapport över beroenden.
- Byggpluginer, kodgeneratorer och annoteringsprocessorer som Lombok.
- Applikationsservern eller servletcontainern, om applikationen körs i en sådan.
- Java-agenter för övervakning, profilering eller säkerhet, som kopplar in sig djupt i JVM:en.
- Kod som använder JDK:ns interna API:er, som du hittar med verktyget jdeps och dess alternativ jdk-internals.
- JVM-flaggor, inställningar för skräpsamlaren och alla skript som tolkar utdata från java -version.
Gå steg för steg genom versionerna med långtidsstöd i stället för att hoppa
Gå från Java 8 till 11, sedan till 17 och sedan till 21 eller 25. Varje steg har sina egna borttagningar och beteendeändringar, och ett enda hopp blandar ihop dem alla till ett fel som inte går att diagnostisera. Genom att åtgärda ett lager i taget blir varje steg litet nog att granska och backa.
Uppgradera biblioteken medan du fortfarande är på Java 8 där det går, eftersom många nya versioner stöder både gamla och nya JDK:er. Kör sedan det befintliga bygget på den nya JVM:en innan du ändrar kompileringsmålet. Det skiljer problem i körmiljön från kompilatorproblem, och kompilatorflaggan release håller bytekodsmålet uttryckligt.
Låt testsviten vara grinden för varje steg
Tester är din enda objektiva signal om att den uppgraderade applikationen fortfarande beter sig likadant. Om de kritiska flödena har låg täckning: skriv först karaktäriseringstester, alltså tester som fångar vad systemet gör i dag, inklusive dess udda kantfall, utan att bedöma om beteendet är rätt.
Lägg till integrationstester som körs mot en riktig databas och riktiga meddelandemäklare, eftersom många uppgraderingsfel bara syns vid de gränssnitten. För beräkningstunga system: kör samma indata genom den gamla och den nya versionen och jämför utdata fält för fält. Var uppmärksam på datum, tal och text: Java 9 gick över till CLDR-språkdata som standard och Java 18 gjorde UTF-8 till standardteckenkodning, och båda kan i tysthet ändra formatering eller tolkning.
Känn till fallgroparna som får Java 8-kod att gå sönder
De flesta fel hör till några få kända kategorier. Sök efter var och en före uppgraderingen i stället för att upptäcka dem i produktion.
- Borttagna Java EE- och CORBA-moduler: Java 11 tog bort JAXB, JAX-WS, JavaBeans Activation och de gemensamma annoteringarna från JDK:n, så de måste läggas tillbaka som uttryckliga beroenden.
- Stark inkapsling av JDK:ns interna delar: otillåten reflektiv åtkomst gav varningar från Java 9, nekas som standard sedan Java 16 och kan inte slås på igen globalt sedan Java 17. Åtgärda det genom att uppgradera biblioteket; använd add-opens bara som ett dokumenterat, tillfälligt undantag.
- Föråldrade bytekodsverktyg: äldre versioner av Lombok, Mockito, Byte Buddy, ASM och byggpluginer fallerar på nyare versioner av klassfilsformatet.
- Borttagna funktioner: JavaScript-motorn Nashorn togs bort i Java 15, och Security Manager markerades som föråldrad i Java 17 och stängdes av permanent i Java 24.
- Borttagna JVM-flaggor: skräpsamlaren CMS togs bort i Java 14, och en JVM som startas med borttagna alternativ kan vägra starta.
Bevisa prestandan under realistisk last, inte på en bärbar dator
En ny JDK ändrar skräpsamlaren, JIT-kompilatorn och minneslayouten, så prestandan kan röra sig åt båda hållen. Kör ett lasttest som återskapar trafikprofilen i produktion, på samma hårdvara eller instanstyp, före och efter varje steg. Jämför latenspercentiler, genomströmning, minne och pauser för skräpsamling, och låt JIT-kompilatorn värmas upp innan du mäter.
Våra utvecklare ledde en migrering från Java 8 till 16 av en kritisk applikation för dagshandel med gas åt en nationell handelsdisk för gas, i uppdrag via Sopra Steria. I det systemet måste beräkningarna av kapacitet och energiflöden förbli korrekta och snabba under högfrekvent belastning, så uppgraderingen gick hand i hand med optimering av de beräkningarna och validerades under last i stället för att tas för given.
Rulla ut gradvis och behåll en väg tillbaka
Leverera den uppgraderade körmiljön till en instans eller en liten andel av trafiken först, och bevaka felfrekvens, latens och skräpsamlingens beteende jämfört med utgångsläget i Java 8. Håll det tidigare bygget driftsättningsbart tills den nya versionen har gått igenom verksamhetens normala cykler, inklusive månadsskiften och perioder med hög belastning.
Ta först därefter bort artefakterna för Java 8 och börja använda nya språkfunktioner. Om du vill ha hjälp att planera eller genomföra en sådan uppgradering bemannar SDK Enterprises den med egna utvecklare och utvalda specialister under ett och samma avtal, med ett tydligt ansvar.
Det viktigaste
- Arbetet i en uppgradering från Java 8 ligger mest i beroenden, byggverktyg och användning av JDK:ns interna delar, inte i affärslogiken.
- Gå igenom versionerna med långtidsstöd en i taget så att varje fel har en enda orsak som går att hitta.
- Karaktäriserings- och integrationstester är grinden för varje steg, särskilt när det gäller datum, tal och teckenkodning.
- Validera prestandan under en last som liknar produktionens, eftersom ändringar i skräpsamling och JIT kan påverka resultaten åt båda hållen.
- Rulla först ut till en liten andel av trafiken och håll bygget för Java 8 driftsättningsbart tills den nya körmiljön har visat sig hålla.
Vanliga frågor
Kan jag uppgradera direkt från Java 8 till Java 21?
Det kan du, men då ärver du varje ändring från Java 9 till 21 på en gång, vilket gör felen svåra att spåra. Att gå via 11 och 17 kostar lite mer byggtid och sparar mycket felsökning i ett kritiskt system.
Hur lång tid tar en uppgradering från Java 8?
Det beror på antalet beroenden, hur många av dem som använder JDK:ns interna delar, testtäckningen och hur mycket lasttester systemet behöver. En inventering och en testkörning på den nya JVM:en ger dig tidigt en realistisk uppskattning, innan du binder dig till en tidsplan.
Måste jag skriva om koden för att använda nya Java-funktioner?
Nej. Java har stark bakåtkompatibilitet för kod som håller sig till standard-API:er som inte är föråldrade. Inför records, textblock och andra funktioner gradvis, när den uppgraderade körmiljön är stabil i produktion.